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.

review-pr - Prompt - OpenSmartRoute

Name: review-pr
Author: Epistemic-Me

Prompt file imported from Epistemic-Me/ai-dlc-workshop (.claude/commands/review-pr.md). Fill in {{arguments}} before use. Copyright stays with the author.

/review-pr

Arguments given: {{arguments}}

Review one PR against its own test strategy, then run the docs gate. Do not merge and do not post comments.

Argument: the ticket ID, for example BUG-01.

Who reviews

The reviewer must be fresh: no history from the session that wrote the code. It must also be from a second model family, different from the one that wrote the code. This is required in this course.

If this tool can run a model from a different family, start a fresh session or subagent on that model.
If it cannot, run this command in a second tool that can (for example Codex, Cursor, or Copilot with a different model).
If neither is possible, use a fresh subagent and write "same model family" in the Reviewer line of REVIEW.md.

Steps for the reviewer

Find docs/prs/implementing/*-PR-<TICKET>-* (or planning/). Read RESEARCH.md, TEST-STRATEGY.md, IMPLEMENTATION-PLAN.md, and IMPLEMENTATION.md.
Read AGENTS.md and docs/.context/ARCHITECTURE.md.
Get the diff: git diff main...HEAD.
Run npm run lint && npm run typecheck && npm test && npm run build.
For each acceptance criterion: is it tested, does it pass, and what is the evidence (a test output line, a response body, or stored rows)? Do not accept the description in IMPLEMENTATION.md as evidence.
Look for: changes the plan did not ask for, files outside the owner's paths, missing edge cases, and the blast radius if the change is wrong.
Write or append REVIEW.md from the template: verdict, the AC table, issues, and risk. If a review exists, add ## Review v<N+1>; the last verdict counts.

Then

Run the docs gate: node scripts/pr-docs-check.mjs --ticket <TICKET>. If the script does not exist, check by hand that RESEARCH.md, TEST-STRATEGY.md, and IMPLEMENTATION-PLAN.md exist and are filled.
If the PR made a decision about architecture or data, propose a record in docs/decisions/ from _TEMPLATE.md. Do not write it until I agree.
Report the verdict, the gate result, and the issues to fix.
Stop. A person decides what goes on the PR and merges it. After the merge, move the folder to docs/prs/_archive/.

No commands set up?

Paste this instead:

Review the diff against TEST-STRATEGY.md. For each acceptance criterion:
tested or not, passing or not, with evidence. Write REVIEW.md with a verdict,
the AC table and the risks. Don't post comments; I'll decide what goes on the PR.

Install review-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.

# /review-pr <TICKET> Arguments given: {{arguments}} Review one PR against its own test strategy, then run the docs gate. Do not merge and do not post comments. Argument: the ticket ID, for example `BUG-01`. ## Who reviews The reviewer must be fresh: no history from the session that wrote the code. It must also be from a second model family, different from the one that wrote the code. This is required in this course. - If this tool can run a model from a different family, start a fresh session or subagent on that model. - If it cannot, run this command in a second tool that can (for example Codex, Cursor, or Copilot with a different model). - If neither is possible, use a fresh subagent and write "same model family" in the Reviewer line of `REVIEW.md`. ## Steps for the reviewer 1. Find `docs/prs/implementing/*-PR-<TICKET>-*` (or `planning/`). Read `RESEARCH.md`, `TEST-STRATEGY.md`, `IMPLEMENTATION-PLAN.md`, and `IMPLEMENTATION.md`. 2. Read `AGENTS.md` and `docs/.context/ARCHITECTURE.md`. 3. Get the diff: `git diff main...HEAD`. 4. Run `npm run lint && npm run typecheck && npm test && npm run build`. 5. For each acceptance criterion: is it tested, does it pass, and what is the evidence (a test output line, a response body, or stored rows)? Do not accept the description in `IMPLEMENTATION.md` as evidence. 6. Look for: changes the plan did not ask for, files outside the owner's paths, missing edge cases, and the blast radius if the change is wrong. 7. Write or append `REVIEW.md` from the template: verdict, the AC table, issues, and risk. If a review exists, add `## Review v<N+1>`; the last verdict counts. ## Then 1. Run the docs gate: `node scripts/pr-docs-check.mjs --ticket <TICKET>`. If the script does not exist, check by hand that `RESEARCH.md`, `TEST-STRATEGY.md`, and `IMPLEMENTATION-PLAN.md` exist and are filled. 2. If the PR made a decision about architecture or data, propose a record in `docs/decisions/` from `_TEMPLATE.md`. Do not write it until I agree. 3. Report the verdict, the gate result, and the issues to fix. 4. Stop. A person decides what goes on the PR and merges it. After the merge, move the folder to `docs/prs/_archive/`. ## No commands set up? Paste this instead: ``` Review the diff against TEST-STRATEGY.md. For each acceptance criterion: tested or not, passing or not, with evidence. Write REVIEW.md with a verdict, the AC table and the risks. Don't post comments; I'll decide what goes on the PR. ```

{ "prompt": "# /review-pr <TICKET>\n\nArguments given: {{arguments}}\n\nReview one PR against its own test strategy, then run the docs gate. Do not merge and do not post comments.\n\nArgument: the ticket ID, for example `BUG-01`.\n\n## Who reviews\n\nThe reviewer must be fresh: no history from the session that wrote the code. It must also be from a second model family, different from the one that wrote the code. This is required in this course.\n\n- If this tool can run a model from a different family, start a fresh session or subagent on that model.\n- If it cannot, run this command in a second tool that can (for example Codex, Cursor, or Copilot with a different model).\n- If neither is possible, use a fresh subagent and write \"same model family\" in the Reviewer line of `REVIEW.md`.\n\n## Steps for the reviewer\n\n1. Find `docs/prs/implementing/*-PR-<TICKET>-*` (or `planning/`). Read `RESEARCH.md`, `TEST-STRATEGY.md`, `IMPLEMENTATION-PLAN.md`, and `IMPLEMENTATION.md`.\n2. Read `AGENTS.md` and `docs/.context/ARCHITECTURE.md`.\n3. Get the diff: `git diff main...HEAD`.\n4. Run `npm run lint && npm run typecheck && npm test && npm run build`.\n5. For each acceptance criterion: is it tested, does it pass, and what is the evidence (a test output line, a response body, or stored rows)? Do not accept the description in `IMPLEMENTATION.md` as evidence.\n6. Look for: changes the plan did not ask for, files outside the owner's paths, missing edge cases, and the blast radius if the change is wrong.\n7. Write or append `REVIEW.md` from the template: verdict, the AC table, issues, and risk. If a review exists, add `## Review v<N+1>`; the last verdict counts.\n\n## Then\n\n1. Run the docs gate: `node scripts/pr-docs-check.mjs --ticket <TICKET>`. If the script does not exist, check by hand that `RESEARCH.md`, `TEST-STRATEGY.md`, and `IMPLEMENTATION-PLAN.md` exist and are filled.\n2. If the PR made a decision about architecture or data, propose a record in `docs/decisions/` from `_TEMPLATE.md`. Do not write it until I agree.\n3. Report the verdict, the gate result, and the issues to fix.\n4. Stop. A person decides what goes on the PR and merges it. After the merge, move the folder to `docs/prs/_archive/`.\n\n## No commands set up?\n\nPaste this instead:\n\n```\nReview the diff against TEST-STRATEGY.md. For each acceptance criterion:\ntested or not, passing or not, with evidence. Write REVIEW.md with a verdict,\nthe AC table and the risks. Don't post comments; I'll decide what goes on the PR.\n```", "variables": [ "arguments" ], "notes": "Review a PR against its test strategy with evidence, then run the docs gate Arguments: <TICKET>.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/Epistemic-Me/ai-dlc-workshop", "path": ".claude/commands/review-pr.md", "ref": "7f99e53acbde60f908fa2eb07531cdf96f63db75", "url": "https://github.com/Epistemic-Me/ai-dlc-workshop/blob/7f99e53acbde60f908fa2eb07531cdf96f63db75/.claude/commands/review-pr.md", "key": "Epistemic-Me/ai-dlc-workshop/.claude/commands/review-pr.md" } } }

review-pr

About

/review-pr

Who reviews

Steps for the reviewer

Then

No commands set up?

Install review-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