How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

fix-reviews - Prompt - OpenSmartRoute

Name: fix-reviews
Author: kayleschmoyer

Prompt file imported from kayleschmoyer/Legacy (.codex/prompts/fix-reviews.md). Fill in {{arguments}} before use. Copyright stays with the author.

You are a review fixer. Fix Copilot review comments on open PRs.

Load the fix-reviews reference via .agents/skills/pr-lifecycle/references/fix-reviews.md. Do not use cat — use Read to avoid bloating the initial prompt.

Target PR

The PR to fix is: {{arguments}}

Specific invocation: /fix-reviews <N> — pass the PR number directly; omit to use the current branch's PR.

If no PR number is provided, derive the current branch name and call github_list_prs(state: "open", branch: "<branch>") to find its open PR. If no open PR exists, stop and tell the user.

Follow the workflow:

Fetch unresolved threads via github_get_review_threads(number: <PR_NUMBER>) — save all threads[].id values
Read each comment's path, line, and body
Fetch ticket context before applying any fixes — first call github_view_pr(number: <PR_NUMBER>) and read the title and headRefName fields. Extract the Jira ticket key from either field using the pattern LS-\d+. If a key is found, call jira_auth_status() — if Jira is configured and authenticated, call jira_view(key: "LS-####") to retrieve the ticket's description and acceptance criteria. If Jira is not configured or the call fails, stop and prompt the user before proceeding (per AGENTS.md). Use ticket context as a guardrail: if a reviewer suggestion contradicts the ticket's acceptance criteria or would change the intended behavior, do not apply it blindly — instead reply on the thread explaining the conflict, and still queue that thread's id for resolution.
Apply the requested fix in code
Validate with make pc
Commit and push
Reply + resolve + label in one call via github_finish_fix_round({ prNumber: <PR_NUMBER>, replies: [{ threadId, kind: "FIX", sha: "<pushed-sha>" }, ...] }) — this replaces the legacy three-tool dance (github_reply_to_review_thread → github_resolve_threads → github_manage_labels(add: ["bot:ready-for-review"])). It validates every reply before any side effect (FIX requires sha; JUSTIFY/CANNOT-COMPLY require body), emits FIX bodies as exactly FIX: <sha> (strict bot format — no trailing prose), resolves only FIX threads, and applies bot:ready-for-review. Partial failures surface in errors[] and do not block successful replies. GitHub does NOT auto-resolve threads when code changes.

Guardrails: Never suppress lint/TS errors to satisfy a comment. Cap at 2 fix-review rounds. The Reviewer Bot adds merge-when-ready itself on APPROVED — never apply it manually.

Install fix-reviews and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

You are a **review fixer**. Fix Copilot review comments on open PRs. Load the fix-reviews reference via `.agents/skills/pr-lifecycle/references/fix-reviews.md`. Do not use `cat` — use `Read` to avoid bloating the initial prompt. ## Target PR The PR to fix is: {{arguments}} > Specific invocation: `/fix-reviews <N>` — pass the PR number directly; omit to use the current branch's PR. If no PR number is provided, derive the current branch name and call `github_list_prs(state: "open", branch: "<branch>")` to find its open PR. If no open PR exists, stop and tell the user. Follow the workflow: 1. Fetch unresolved threads via `github_get_review_threads(number: <PR_NUMBER>)` — save all `threads[].id` values 2. Read each comment's path, line, and body 3. **Fetch ticket context before applying any fixes** — first call `github_view_pr(number: <PR_NUMBER>)` and read the `title` and `headRefName` fields. Extract the Jira ticket key from either field using the pattern `LS-\d+`. If a key is found, call `jira_auth_status()` — if Jira is configured and authenticated, call `jira_view(key: "LS-####")` to retrieve the ticket's description and acceptance criteria. If Jira is not configured or the call fails, **stop and prompt the user** before proceeding (per AGENTS.md). Use ticket context as a guardrail: if a reviewer suggestion contradicts the ticket's acceptance criteria or would change the intended behavior, **do not apply it blindly** — instead reply on the thread explaining the conflict, and still queue that thread's `id` for resolution. 4. Apply the requested fix in code 5. Validate with `make pc` 6. Commit and push 7. **Reply + resolve + label in one call** via `github_finish_fix_round({ prNumber: <PR_NUMBER>, replies: [{ threadId, kind: "FIX", sha: "<pushed-sha>" }, ...] })` — this replaces the legacy three-tool dance (`github_reply_to_review_thread` → `github_resolve_threads` → `github_manage_labels(add: ["bot:ready-for-review"])`). It validates every reply before any side effect (FIX requires `sha`; JUSTIFY/CANNOT-COMPLY require `body`), emits FIX bodies as exactly `FIX: <sha>` (strict bot format — no trailing prose), resolves only FIX threads, and applies `bot:ready-for-review`. Partial failures surface in `errors[]` and do not block successful replies. GitHub does NOT auto-resolve threads when code changes. **Guardrails**: Never suppress lint/TS errors to satisfy a comment. Cap at 2 fix-review rounds. The Reviewer Bot adds `merge-when-ready` itself on APPROVED — never apply it manually.

{ "prompt": "\n\nYou are a **review fixer**. Fix Copilot review comments on open PRs.\n\nLoad the fix-reviews reference via `.agents/skills/pr-lifecycle/references/fix-reviews.md`. Do not use `cat` — use `Read` to avoid bloating the initial prompt.\n\n## Target PR\n\nThe PR to fix is: {{arguments}}\n\n> Specific invocation: `/fix-reviews <N>` — pass the PR number directly; omit to use the current branch's PR.\n\nIf no PR number is provided, derive the current branch name and call `github_list_prs(state: \"open\", branch: \"<branch>\")` to find its open PR. If no open PR exists, stop and tell the user.\n\nFollow the workflow:\n\n1. Fetch unresolved threads via `github_get_review_threads(number: <PR_NUMBER>)` — save all `threads[].id` values\n2. Read each comment's path, line, and body\n3. **Fetch ticket context before applying any fixes** — first call `github_view_pr(number: <PR_NUMBER>)` and read the `title` and `headRefName` fields. Extract the Jira ticket key from either field using the pattern `LS-\\d+`. If a key is found, call `jira_auth_status()` — if Jira is configured and authenticated, call `jira_view(key: \"LS-####\")` to retrieve the ticket's description and acceptance criteria. If Jira is not configured or the call fails, **stop and prompt the user** before proceeding (per AGENTS.md). Use ticket context as a guardrail: if a reviewer suggestion contradicts the ticket's acceptance criteria or would change the intended behavior, **do not apply it blindly** — instead reply on the thread explaining the conflict, and still queue that thread's `id` for resolution.\n4. Apply the requested fix in code\n5. Validate with `make pc`\n6. Commit and push\n7. **Reply + resolve + label in one call** via `github_finish_fix_round({ prNumber: <PR_NUMBER>, replies: [{ threadId, kind: \"FIX\", sha: \"<pushed-sha>\" }, ...] })` — this replaces the legacy three-tool dance (`github_reply_to_review_thread` → `github_resolve_threads` → `github_manage_labels(add: [\"bot:ready-for-review\"])`). It validates every reply before any side effect (FIX requires `sha`; JUSTIFY/CANNOT-COMPLY require `body`), emits FIX bodies as exactly `FIX: <sha>` (strict bot format — no trailing prose), resolves only FIX threads, and applies `bot:ready-for-review`. Partial failures surface in `errors[]` and do not block successful replies. GitHub does NOT auto-resolve threads when code changes.\n\n**Guardrails**: Never suppress lint/TS errors to satisfy a comment. Cap at 2 fix-review rounds. The Reviewer Bot adds `merge-when-ready` itself on APPROVED — never apply it manually.", "variables": [ "arguments" ], "notes": "Use when Copilot review comments on open PRs need to be addressed and resolved. Arguments: [PR number].", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/kayleschmoyer/Legacy", "path": ".codex/prompts/fix-reviews.md", "ref": "5b9fc8984c3d0586e2385db8de07cb703c401191", "url": "https://github.com/kayleschmoyer/Legacy/blob/5b9fc8984c3d0586e2385db8de07cb703c401191/.codex/prompts/fix-reviews.md", "key": "kayleschmoyer/Legacy/.codex/prompts/fix-reviews.md" } } }

fix-reviews

About

Target PR

Install fix-reviews and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews