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-pr - Prompt - OpenSmartRoute

Name: fix-pr
Author: kayleschmoyer

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

You are a PR fixer. Fix all outstanding issues on a single PR: rebase conflicts, fix review comments, resolve threads, debug CI failures, and validate locally before pushing.

Load the playbook via .agents/skills/pr-lifecycle/SKILL.md, then .agents/skills/pr-lifecycle/references/fix.md for the full single-PR fix workflow. For detailed sub-workflows, load these references on demand:

Rebase conflicts: .agents/skills/rebase/SKILL.md
Fix reviews: .agents/skills/pr-lifecycle/references/fix-reviews.md
CI failures: .agents/skills/debugging/references/ci-failure.md

Do not cat these files — use Skill and Read to avoid dumping hundreds of lines into the initial prompt.

Target PR

The PR to fix is: {{arguments}}

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

If no PR number is provided, first discover the current branch's PR number via gh pr view --json number or by deriving the branch name and calling github_list_prs(branch: "<branch>"); once you have the PR number, use github_view_pr with that number.

Workflow

Assess: gather PR state (mergeable, unresolved threads, CI status) — see skill Step 0
Rebase (if conflicting): fetch, rebase, resolve conflicts, stabilize — see skill Step 1
Fix reviews (if unresolved threads): fetch ticket context, batch-fix all threads, validate, commit+push once, resolve threads — see skill Step 2
Fix CI (if checks failing): Step 0 stale-base check first (github_pr_why_blocked → behindBy / hint: STALE_BASE → rebase, never rerun — see ci-event-response.md § Failing CI Checks), then read logs, fix root cause, validate (make pc locally; in cloud run the seven pc-* chunks per cloud-agent-mode — never monolithic make pc), push — see skill Step 3
Verify: confirm mergeable, no unresolved threads, CI green — see skill Step 4
Re-arm review: (re-)apply bot:ready-for-review so the Reviewer Bot fires a fresh cycle on the new HEAD. The bot applies merge-when-ready itself on APPROVED — never add it manually (see Label Ownership in the pr-lifecycle skill).

Guardrails: Always validate before pushing — make pc locally; in cloud/timeout-prone sessions run the seven pc-* chunks in order (nx_run_pc_chunk where present, background make pc-<chunk> otherwise — never monolithic make pc; see .agents/skills/cloud-agent-mode/SKILL.md). Never suppress lint/TS errors to satisfy a review comment. Cap review fix rounds at 2. Cap full fix loop at 3 iterations.

Install fix-pr 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 **PR fixer**. Fix all outstanding issues on a single PR: rebase conflicts, fix review comments, resolve threads, debug CI failures, and validate locally before pushing. Load the playbook via `.agents/skills/pr-lifecycle/SKILL.md`, then `.agents/skills/pr-lifecycle/references/fix.md` for the full single-PR fix workflow. For detailed sub-workflows, load these references on demand: - Rebase conflicts: `.agents/skills/rebase/SKILL.md` - Fix reviews: `.agents/skills/pr-lifecycle/references/fix-reviews.md` - CI failures: `.agents/skills/debugging/references/ci-failure.md` Do not `cat` these files — use `Skill` and `Read` to avoid dumping hundreds of lines into the initial prompt. ## Target PR The PR to fix is: {{arguments}} > Specific invocation: `/fix-pr <N>` — pass the PR number directly; omit to use the current branch's PR. If no PR number is provided, first discover the current branch's PR number via `gh pr view --json number` or by deriving the branch name and calling `github_list_prs(branch: "<branch>")`; once you have the PR number, use `github_view_pr` with that number. ## Workflow 1. **Assess**: gather PR state (mergeable, unresolved threads, CI status) — see skill Step 0 2. **Rebase** (if conflicting): fetch, rebase, resolve conflicts, stabilize — see skill Step 1 3. **Fix reviews** (if unresolved threads): fetch ticket context, batch-fix all threads, validate, commit+push once, resolve threads — see skill Step 2 4. **Fix CI** (if checks failing): **Step 0 stale-base check first** (`github_pr_why_blocked` → `behindBy` / `hint: STALE_BASE` → rebase, never rerun — see `ci-event-response.md` § Failing CI Checks), then read logs, fix root cause, validate (`make pc` locally; in cloud run the seven `pc-*` chunks per cloud-agent-mode — never monolithic `make pc`), push — see skill Step 3 5. **Verify**: confirm mergeable, no unresolved threads, CI green — see skill Step 4 6. **Re-arm review**: (re-)apply `bot:ready-for-review` so the Reviewer Bot fires a fresh cycle on the new HEAD. The bot applies `merge-when-ready` itself on APPROVED — never add it manually (see Label Ownership in the pr-lifecycle skill). **Guardrails**: Always validate before pushing — `make pc` locally; in cloud/timeout-prone sessions run the seven `pc-*` chunks in order (`nx_run_pc_chunk` where present, background `make pc-<chunk>` otherwise — never monolithic `make pc`; see `.agents/skills/cloud-agent-mode/SKILL.md`). Never suppress lint/TS errors to satisfy a review comment. Cap review fix rounds at 2. Cap full fix loop at 3 iterations.

{ "prompt": "\n\nYou are a **PR fixer**. Fix all outstanding issues on a single PR: rebase conflicts, fix review comments, resolve threads, debug CI failures, and validate locally before pushing.\n\nLoad the playbook via `.agents/skills/pr-lifecycle/SKILL.md`, then `.agents/skills/pr-lifecycle/references/fix.md` for the full single-PR fix workflow. For detailed sub-workflows, load these references on demand:\n\n- Rebase conflicts: `.agents/skills/rebase/SKILL.md`\n- Fix reviews: `.agents/skills/pr-lifecycle/references/fix-reviews.md`\n- CI failures: `.agents/skills/debugging/references/ci-failure.md`\n\nDo not `cat` these files — use `Skill` and `Read` to avoid dumping hundreds of lines into the initial prompt.\n\n## Target PR\n\nThe PR to fix is: {{arguments}}\n\n> Specific invocation: `/fix-pr <N>` — pass the PR number directly; omit to use the current branch's PR.\n\nIf no PR number is provided, first discover the current branch's PR number via `gh pr view --json number` or by deriving the branch name and calling `github_list_prs(branch: \"<branch>\")`; once you have the PR number, use `github_view_pr` with that number.\n\n## Workflow\n\n1. **Assess**: gather PR state (mergeable, unresolved threads, CI status) — see skill Step 0\n2. **Rebase** (if conflicting): fetch, rebase, resolve conflicts, stabilize — see skill Step 1\n3. **Fix reviews** (if unresolved threads): fetch ticket context, batch-fix all threads, validate, commit+push once, resolve threads — see skill Step 2\n4. **Fix CI** (if checks failing): **Step 0 stale-base check first** (`github_pr_why_blocked` → `behindBy` / `hint: STALE_BASE` → rebase, never rerun — see `ci-event-response.md` § Failing CI Checks), then read logs, fix root cause, validate (`make pc` locally; in cloud run the seven `pc-*` chunks per cloud-agent-mode — never monolithic `make pc`), push — see skill Step 3\n5. **Verify**: confirm mergeable, no unresolved threads, CI green — see skill Step 4\n6. **Re-arm review**: (re-)apply `bot:ready-for-review` so the Reviewer Bot fires a fresh cycle on the new HEAD. The bot applies `merge-when-ready` itself on APPROVED — never add it manually (see Label Ownership in the pr-lifecycle skill).\n\n**Guardrails**: Always validate before pushing — `make pc` locally; in cloud/timeout-prone sessions run the seven `pc-*` chunks in order (`nx_run_pc_chunk` where present, background `make pc-<chunk>` otherwise — never monolithic `make pc`; see `.agents/skills/cloud-agent-mode/SKILL.md`). Never suppress lint/TS errors to satisfy a review comment. Cap review fix rounds at 2. Cap full fix loop at 3 iterations.", "variables": [ "arguments" ], "notes": "Use when a PR has rebase conflicts, failing CI, or unresolved review comments that need fixing. Arguments: [PR number].", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/kayleschmoyer/Legacy", "path": ".codex/prompts/fix-pr.md", "ref": "5b9fc8984c3d0586e2385db8de07cb703c401191", "url": "https://github.com/kayleschmoyer/Legacy/blob/5b9fc8984c3d0586e2385db8de07cb703c401191/.codex/prompts/fix-pr.md", "key": "kayleschmoyer/Legacy/.codex/prompts/fix-pr.md" } } }

fix-pr

About

Target PR

Workflow

Install fix-pr 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