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.

qk-review - Prompt - OpenSmartRoute

Name: qk-review
Author: hmcts

Prompt file imported from hmcts/cath-service (.claude/commands/qk-review.md). Copyright stays with the author.

Quick Review: $ARGUMENT

Initialize Progress Tracking

Use TodoWrite to create this checklist:

- [ ] Perform code review
- [ ] Generate review report

PHASE 1: Code Review

Mark "Perform code review" as in_progress

Step 1.1: Execute Review [ISOLATED AGENT]

AGENT: code-reviewer
TASK: Review the implementation changes and provide comprehensive feedback
INPUT:
  - docs/tickets/$ARGUMENT/ticket.md
  - docs/tickets/$ARGUMENT/plan.md
  - docs/tickets/$ARGUMENT/tasks.md
  - All changed files (via git diff)

PROMPT FOR AGENT:
"Review the implementation for issue #$ARGUMENT and provide detailed feedback.

**STEP 1: Analyze Changes**
1. Run: git diff --name-only to see all changed files
2. Run: git diff to see the actual changes
3. Read docs/tickets/$ARGUMENT/ticket.md to understand the requirements, and extract the
   acceptance criteria verbatim (the 'Acceptance Criteria'/'AC' section or checklist items in
   the Description) so each one can be checked individually in the report
4. Read docs/tickets/$ARGUMENT/plan.md to understand the intended approach
5. Read docs/tickets/$ARGUMENT/tasks.md to verify all tasks were completed

**STEP 2: Review Categories**
Perform a comprehensive review covering:

**Security Review:**
- Input validation and sanitization
- Authentication and authorization
- Data protection (no sensitive data in logs)
- SQL injection prevention (Prisma usage)
- XSS prevention (proper escaping)

**Accessibility Review:**
- WCAG 2.2 AA compliance
- Proper GOV.UK component usage
- Semantic HTML and ARIA labels
- Keyboard navigation support
- Screen reader compatibility

**Code Quality Review:**
- TypeScript type safety (no 'any' types)
- Proper error handling
- Following @CLAUDE.md guidelines (libs/ structure)
- Code organization and maintainability
- Naming conventions and clarity

**Testing Review:**
- Unit test coverage (>80% on business logic)
- E2E tests for user journeys
- Accessibility tests included
- Test quality and realistic scenarios

**Performance Review:**
- Database query efficiency (N+1 queries, indexes)
- Mobile-first responsive design
- Asset optimization
- No blocking operations

**GOV.UK Standards Review:**
- Design System component usage
- One thing per page pattern
- Progressive enhancement (works without JS)
- Plain English content

**STEP 2b: Measure Test Coverage**
1. Run: git diff --name-only to identify which workspaces (libs/* and apps/*) changed
2. Run: yarn test:coverage
3. For each changed workspace, read its 'Coverage summary' block in the output and take the
   percentage from the 'Statements :' line (e.g. "Statements : 87% (…)")
4. Record each changed workspace's statement coverage % for use in the report

**STEP 3: Generate Review Report**
Create a review report at docs/tickets/$ARGUMENT/review.md with the following structure:

# Code Review: Issue #$ARGUMENT

## Summary
[Brief overview of the changes and overall assessment]

## 🚨 CRITICAL Issues
[List any critical issues that MUST be fixed before deployment]
- Each issue with file:line reference
- Impact description
- Specific solution required

## ⚠️ HIGH PRIORITY Issues
[List high priority issues that SHOULD be fixed]
- Impact on user experience or performance
- Recommended improvements

## 💡 SUGGESTIONS
[List suggestions for improvement]
- Potential enhancements
- Refactoring opportunities
- Documentation improvements

## ✅ Positive Feedback
[List things done well]
- Good practices followed
- Quality implementations
- Effective solutions

## Test Coverage Assessment
- Unit tests: [assessment]
- E2E tests: [assessment]
- Accessibility tests: [assessment]
- Statement coverage per changed workspace (from STEP 2b):
  - <workspace>: <NN>%  (flag ⚠️ if below 80%)

## Acceptance Criteria Verification
[List EVERY acceptance criterion extracted from ticket.md — do not summarise or omit any.
Mark each using exactly three states:
  - '- [x]' fully met
  - '- [~]' partially met (state what is done and what is missing)
  - '- [ ]' not met
Every met or partially met criterion MUST cite at least one file:line reference to the code or
test that satisfies it. If a criterion is met but no such reference exists, mark it '- [ ]' and
record 'no evidence'.]
- [ ] Criterion 1: [Status and notes — file:line]
- [ ] Criterion 2: [Status and notes — file:line]
...

## Next Steps
- [ ] Address critical issues
- [ ] Fix high priority items
- [ ] Consider suggestions
- [ ] Re-run tests after fixes

## Overall Assessment
[APPROVED / NEEDS CHANGES / MAJOR REVISIONS REQUIRED]

Coverage rule: if any changed workspace is below 80% statement coverage (per STEP 2b), the
Overall Assessment MUST be at least NEEDS CHANGES, and each such workspace MUST be listed under
HIGH PRIORITY Issues (or CRITICAL if coverage is far below). This verdict is advisory — it does
not block the developer from committing.

Acceptance Criteria rule: if any acceptance criterion is not fully met (any '- [ ]' or '- [~]'
in the Acceptance Criteria Verification section), the Overall Assessment MUST be at least NEEDS
CHANGES. Each not-met ('- [ ]') criterion MUST be listed under CRITICAL Issues — an unmet
criterion is an unimplemented requirement. Each partially met ('- [~]') criterion MUST be listed
under HIGH PRIORITY Issues with the missing part described. This verdict is advisory — it does
not block the developer from committing.

---

**IMPORTANT:**
- Be specific with file and line references
- Provide constructive, actionable feedback
- Acknowledge good work alongside issues
- Focus on user impact, not just code style
- Verify all acceptance criteria are met"

WAIT FOR AGENT TO COMPLETE

Mark "Perform code review" as completed

PHASE 2: Present Review to User

Mark "Generate review report" as in_progress

Step 2.1: Display Review Summary

ACTION: Read the review report and present key findings to the user

1. Read docs/tickets/$ARGUMENT/review.md
2. Display a summary of:
   - Overall assessment
   - Number of critical issues
   - Number of high priority issues
   - Number of suggestions
   - Acceptance criteria status (N met / P partial / U unmet of M, with any partial or unmet
     criteria named)

3. Show the full review report location

Mark "Generate review report" as completed

Output to User

Display the following message:

Code review complete for issue #$ARGUMENT!

📊 Review Summary:
[Display counts of critical/high priority/suggestions]

Acceptance Criteria: [N met / P partial / U unmet of M — name any partial or unmet criteria]

Overall Assessment: [APPROVED/NEEDS CHANGES/MAJOR REVISIONS REQUIRED]

Full review report: docs/tickets/$ARGUMENT/review.md

---

[If APPROVED]
✅ Ready to commit and create PR!
- Commit: git add . && git commit -m "Implement issue #$ARGUMENT"
- Create PR: gh pr create

[If NEEDS CHANGES or MAJOR REVISIONS REQUIRED]
⚠️  Please address the issues identified in the review report, then re-run /qk-review $ARGUMENT

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

# Quick Review: $ARGUMENT ## Initialize Progress Tracking Use TodoWrite to create this checklist: ``` - [ ] Perform code review - [ ] Generate review report ``` ## PHASE 1: Code Review *Mark "Perform code review" as in_progress* ### Step 1.1: Execute Review [ISOLATED AGENT] ``` AGENT: code-reviewer TASK: Review the implementation changes and provide comprehensive feedback INPUT: - docs/tickets/$ARGUMENT/ticket.md - docs/tickets/$ARGUMENT/plan.md - docs/tickets/$ARGUMENT/tasks.md - All changed files (via git diff) PROMPT FOR AGENT: "Review the implementation for issue #$ARGUMENT and provide detailed feedback. **STEP 1: Analyze Changes** 1. Run: git diff --name-only to see all changed files 2. Run: git diff to see the actual changes 3. Read docs/tickets/$ARGUMENT/ticket.md to understand the requirements, and extract the acceptance criteria verbatim (the 'Acceptance Criteria'/'AC' section or checklist items in the Description) so each one can be checked individually in the report 4. Read docs/tickets/$ARGUMENT/plan.md to understand the intended approach 5. Read docs/tickets/$ARGUMENT/tasks.md to verify all tasks were completed **STEP 2: Review Categories** Perform a comprehensive review covering: **Security Review:** - Input validation and sanitization - Authentication and authorization - Data protection (no sensitive data in logs) - SQL injection prevention (Prisma usage) - XSS prevention (proper escaping) **Accessibility Review:** - WCAG 2.2 AA compliance - Proper GOV.UK component usage - Semantic HTML and ARIA labels - Keyboard navigation support - Screen reader compatibility **Code Quality Review:** - TypeScript type safety (no 'any' types) - Proper error handling - Following @CLAUDE.md guidelines (libs/ structure) - Code organization and maintainability - Naming conventions and clarity **Testing Review:** - Unit test coverage (>80% on business logic) - E2E tests for user journeys - Accessibility tests included - Test quality and realistic scenarios **Performance Review:** - Database query efficiency (N+1 queries, indexes) - Mobile-first responsive design - Asset optimization - No blocking operations **GOV.UK Standards Review:** - Design System component usage - One thing per page pattern - Progressive enhancement (works without JS) - Plain English content **STEP 2b: Measure Test Coverage** 1. Run: git diff --name-only to identify which workspaces (libs/* and apps/*) changed 2. Run: yarn test:coverage 3. For each changed workspace, read its 'Coverage summary' block in the output and take the percentage from the 'Statements :' line (e.g. "Statements : 87% (…)") 4. Record each changed workspace's statement coverage % for use in the report **STEP 3: Generate Review Report** Create a review report at docs/tickets/$ARGUMENT/review.md with the following structure: # Code Review: Issue #$ARGUMENT ## Summary [Brief overview of the changes and overall assessment] ## 🚨 CRITICAL Issues [List any critical issues that MUST be fixed before deployment] - Each issue with file:line reference - Impact description - Specific solution required ## ⚠️ HIGH PRIORITY Issues [List high priority issues that SHOULD be fixed] - Impact on user experience or performance - Recommended improvements ## 💡 SUGGESTIONS [List suggestions for improvement] - Potential enhancements - Refactoring opportunities - Documentation improvements ## ✅ Positive Feedback [List things done well] - Good practices followed - Quality implementations - Effective solutions ## Test Coverage Assessment - Unit tests: [assessment] - E2E tests: [assessment] - Accessibility tests: [assessment] - Statement coverage per changed workspace (from STEP 2b): - <workspace>: <NN>% (flag ⚠️ if below 80%) ## Acceptance Criteria Verification [List EVERY acceptance criterion extracted from ticket.md — do not summarise or omit any. Mark each using exactly three states: - '- [x]' fully met - '- [~]' partially met (state what is done and what is missing) - '- [ ]' not met Every met or partially met criterion MUST cite at least one file:line reference to the code or test that satisfies it. If a criterion is met but no such reference exists, mark it '- [ ]' and record 'no evidence'.] - [ ] Criterion 1: [Status and notes — file:line] - [ ] Criterion 2: [Status and notes — file:line] ... ## Next Steps - [ ] Address critical issues - [ ] Fix high priority items - [ ] Consider suggestions - [ ] Re-run tests after fixes ## Overall Assessment [APPROVED / NEEDS CHANGES / MAJOR REVISIONS REQUIRED] Coverage rule: if any changed workspace is below 80% statement coverage (per STEP 2b), the Overall Assessment MUST be at least NEEDS CHANGES, and each such workspace MUST be listed under HIGH PRIORITY Issues (or CRITICAL if coverage is far below). This verdict is advisory — it does not block the developer from committing. Acceptance Criteria rule: if any acceptance criterion is not fully met (any '- [ ]' or '- [~]' in the Acceptance Criteria Verification section), the Overall Assessment MUST be at least NEEDS CHANGES. Each not-met ('- [ ]') criterion MUST be listed under CRITICAL Issues — an unmet criterion is an unimplemented requirement. Each partially met ('- [~]') criterion MUST be listed under HIGH PRIORITY Issues with the missing part described. This verdict is advisory — it does not block the developer from committing. --- **IMPORTANT:** - Be specific with file and line references - Provide constructive, actionable feedback - Acknowledge good work alongside issues - Focus on user impact, not just code style - Verify all acceptance criteria are met" WAIT FOR AGENT TO COMPLETE ``` *Mark "Perform code review" as completed* ## PHASE 2: Present Review to User *Mark "Generate review report" as in_progress* ### Step 2.1: Display Review Summary ``` ACTION: Read the review report and present key findings to the user 1. Read docs/tickets/$ARGUMENT/review.md 2. Display a summary of: - Overall assessment - Number of critical issues - Number of high priority issues - Number of suggestions - Acceptance criteria status (N met / P partial / U unmet of M, with any partial or unmet criteria named) 3. Show the full review report location ``` *Mark "Generate review report" as completed* ## Output to User Display the following message: ``` Code review complete for issue #$ARGUMENT! 📊 Review Summary: [Display counts of critical/high priority/suggestions] Acceptance Criteria: [N met / P partial / U unmet of M — name any partial or unmet criteria] Overall Assessment: [APPROVED/NEEDS CHANGES/MAJOR REVISIONS REQUIRED] Full review report: docs/tickets/$ARGUMENT/review.md --- [If APPROVED] ✅ Ready to commit and create PR! - Commit: git add . && git commit -m "Implement issue #$ARGUMENT" - Create PR: gh pr create [If NEEDS CHANGES or MAJOR REVISIONS REQUIRED] ⚠️ Please address the issues identified in the review report, then re-run /qk-review $ARGUMENT ```

{ "prompt": "# Quick Review: $ARGUMENT\n\n## Initialize Progress Tracking\nUse TodoWrite to create this checklist:\n```\n- [ ] Perform code review\n- [ ] Generate review report\n```\n\n## PHASE 1: Code Review\n*Mark \"Perform code review\" as in_progress*\n\n### Step 1.1: Execute Review [ISOLATED AGENT]\n\n```\nAGENT: code-reviewer\nTASK: Review the implementation changes and provide comprehensive feedback\nINPUT:\n - docs/tickets/$ARGUMENT/ticket.md\n - docs/tickets/$ARGUMENT/plan.md\n - docs/tickets/$ARGUMENT/tasks.md\n - All changed files (via git diff)\n\nPROMPT FOR AGENT:\n\"Review the implementation for issue #$ARGUMENT and provide detailed feedback.\n\n**STEP 1: Analyze Changes**\n1. Run: git diff --name-only to see all changed files\n2. Run: git diff to see the actual changes\n3. Read docs/tickets/$ARGUMENT/ticket.md to understand the requirements, and extract the\n acceptance criteria verbatim (the 'Acceptance Criteria'/'AC' section or checklist items in\n the Description) so each one can be checked individually in the report\n4. Read docs/tickets/$ARGUMENT/plan.md to understand the intended approach\n5. Read docs/tickets/$ARGUMENT/tasks.md to verify all tasks were completed\n\n**STEP 2: Review Categories**\nPerform a comprehensive review covering:\n\n**Security Review:**\n- Input validation and sanitization\n- Authentication and authorization\n- Data protection (no sensitive data in logs)\n- SQL injection prevention (Prisma usage)\n- XSS prevention (proper escaping)\n\n**Accessibility Review:**\n- WCAG 2.2 AA compliance\n- Proper GOV.UK component usage\n- Semantic HTML and ARIA labels\n- Keyboard navigation support\n- Screen reader compatibility\n\n**Code Quality Review:**\n- TypeScript type safety (no 'any' types)\n- Proper error handling\n- Following @CLAUDE.md guidelines (libs/ structure)\n- Code organization and maintainability\n- Naming conventions and clarity\n\n**Testing Review:**\n- Unit test coverage (>80% on business logic)\n- E2E tests for user journeys\n- Accessibility tests included\n- Test quality and realistic scenarios\n\n**Performance Review:**\n- Database query efficiency (N+1 queries, indexes)\n- Mobile-first responsive design\n- Asset optimization\n- No blocking operations\n\n**GOV.UK Standards Review:**\n- Design System component usage\n- One thing per page pattern\n- Progressive enhancement (works without JS)\n- Plain English content\n\n**STEP 2b: Measure Test Coverage**\n1. Run: git diff --name-only to identify which workspaces (libs/* and apps/*) changed\n2. Run: yarn test:coverage\n3. For each changed workspace, read its 'Coverage summary' block in the output and take the\n percentage from the 'Statements :' line (e.g. \"Statements : 87% (…)\")\n4. Record each changed workspace's statement coverage % for use in the report\n\n**STEP 3: Generate Review Report**\nCreate a review report at docs/tickets/$ARGUMENT/review.md with the following structure:\n\n# Code Review: Issue #$ARGUMENT\n\n## Summary\n[Brief overview of the changes and overall assessment]\n\n## 🚨 CRITICAL Issues\n[List any critical issues that MUST be fixed before deployment]\n- Each issue with file:line reference\n- Impact description\n- Specific solution required\n\n## ⚠️ HIGH PRIORITY Issues\n[List high priority issues that SHOULD be fixed]\n- Impact on user experience or performance\n- Recommended improvements\n\n## 💡 SUGGESTIONS\n[List suggestions for improvement]\n- Potential enhancements\n- Refactoring opportunities\n- Documentation improvements\n\n## ✅ Positive Feedback\n[List things done well]\n- Good practices followed\n- Quality implementations\n- Effective solutions\n\n## Test Coverage Assessment\n- Unit tests: [assessment]\n- E2E tests: [assessment]\n- Accessibility tests: [assessment]\n- Statement coverage per changed workspace (from STEP 2b):\n - <workspace>: <NN>% (flag ⚠️ if below 80%)\n\n## Acceptance Criteria Verification\n[List EVERY acceptance criterion extracted from ticket.md — do not summarise or omit any.\nMark each using exactly three states:\n - '- [x]' fully met\n - '- [~]' partially met (state what is done and what is missing)\n - '- [ ]' not met\nEvery met or partially met criterion MUST cite at least one file:line reference to the code or\ntest that satisfies it. If a criterion is met but no such reference exists, mark it '- [ ]' and\nrecord 'no evidence'.]\n- [ ] Criterion 1: [Status and notes — file:line]\n- [ ] Criterion 2: [Status and notes — file:line]\n...\n\n## Next Steps\n- [ ] Address critical issues\n- [ ] Fix high priority items\n- [ ] Consider suggestions\n- [ ] Re-run tests after fixes\n\n## Overall Assessment\n[APPROVED / NEEDS CHANGES / MAJOR REVISIONS REQUIRED]\n\nCoverage rule: if any changed workspace is below 80% statement coverage (per STEP 2b), the\nOverall Assessment MUST be at least NEEDS CHANGES, and each such workspace MUST be listed under\nHIGH PRIORITY Issues (or CRITICAL if coverage is far below). This verdict is advisory — it does\nnot block the developer from committing.\n\nAcceptance Criteria rule: if any acceptance criterion is not fully met (any '- [ ]' or '- [~]'\nin the Acceptance Criteria Verification section), the Overall Assessment MUST be at least NEEDS\nCHANGES. Each not-met ('- [ ]') criterion MUST be listed under CRITICAL Issues — an unmet\ncriterion is an unimplemented requirement. Each partially met ('- [~]') criterion MUST be listed\nunder HIGH PRIORITY Issues with the missing part described. This verdict is advisory — it does\nnot block the developer from committing.\n\n---\n\n**IMPORTANT:**\n- Be specific with file and line references\n- Provide constructive, actionable feedback\n- Acknowledge good work alongside issues\n- Focus on user impact, not just code style\n- Verify all acceptance criteria are met\"\n\nWAIT FOR AGENT TO COMPLETE\n```\n*Mark \"Perform code review\" as completed*\n\n## PHASE 2: Present Review to User\n*Mark \"Generate review report\" as in_progress*\n\n### Step 2.1: Display Review Summary\n\n```\nACTION: Read the review report and present key findings to the user\n\n1. Read docs/tickets/$ARGUMENT/review.md\n2. Display a summary of:\n - Overall assessment\n - Number of critical issues\n - Number of high priority issues\n - Number of suggestions\n - Acceptance criteria status (N met / P partial / U unmet of M, with any partial or unmet\n criteria named)\n\n3. Show the full review report location\n```\n*Mark \"Generate review report\" as completed*\n\n## Output to User\n\nDisplay the following message:\n\n```\nCode review complete for issue #$ARGUMENT!\n\n📊 Review Summary:\n[Display counts of critical/high priority/suggestions]\n\nAcceptance Criteria: [N met / P partial / U unmet of M — name any partial or unmet criteria]\n\nOverall Assessment: [APPROVED/NEEDS CHANGES/MAJOR REVISIONS REQUIRED]\n\nFull review report: docs/tickets/$ARGUMENT/review.md\n\n---\n\n[If APPROVED]\n✅ Ready to commit and create PR!\n- Commit: git add . && git commit -m \"Implement issue #$ARGUMENT\"\n- Create PR: gh pr create\n\n[If NEEDS CHANGES or MAJOR REVISIONS REQUIRED]\n⚠️ Please address the issues identified in the review report, then re-run /qk-review $ARGUMENT\n```", "variables": [], "notes": "Review implementation and provide feedback Tools: Task, TodoWrite, Bash, Read, Write, Glob, Grep. Arguments: <issue-number>.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/hmcts/cath-service", "path": ".claude/commands/qk-review.md", "ref": "6b05658b127b18068771d482542403000a87b447", "url": "https://github.com/hmcts/cath-service/blob/6b05658b127b18068771d482542403000a87b447/.claude/commands/qk-review.md", "key": "hmcts/cath-service/.claude/commands/qk-review.md" } } }

qk-review

About

Quick Review: $ARGUMENT

Initialize Progress Tracking

PHASE 1: Code Review

Step 1.1: Execute Review [ISOLATED AGENT]

PHASE 2: Present Review to User

Step 2.1: Display Review Summary

Output to User

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