Review code changes with five parallel agents before committing. Each checks a separate area: code quality, simplicity, consistency, robustness, or task scope. Results identify issues, and every check must pass before the changes are considered ready.
Quality gate. 5 parallel agents review changes. All must pass.
Review the instructions the agent will receive before you install.
DIFF=$(git diff main)
FILES=$(git diff main --name-only)
TASK="{task description or 'general changes'}"
Read 1-2 unmodified files from same directories for pattern context.
Spawn all 5 in parallel. All output raw JSON only, no markdown.
DIFF: ${DIFF}
- Descriptive naming?
- Errors caught with useful messages?
- No hardcoded values, commented code, debug statements?
- No TODO without ticket ref?
- No obvious bugs?
- No useless comments?
{"pass": bool, "issues": [...]}
DIFF: ${DIFF}
- Is this overcomplicated? Can I solve the same problem in a simpler manner?
- Can I reduce indirection?
- Can I reduce surface area?
- Premature abstraction? Premature Optimization? YAGNI violations?
- Dead code?
- Three similar lines > one abstraction
{"pass": bool, "issues": [...]}
DIFF: ${DIFF}
PATTERNS: ${PATTERN_FILES}
- Matches existing codebase patterns?
- Proper types, no any, no unsafe casts?
- Idiomatic error handling?
- Changes internally consistent?
- Is logic isolated and composable?
- Are there existing tests if neccesary?
{"pass": bool, "issues": [...]}
TASK: ${TASK}
DIFF: ${DIFF}
- Actually solves the problem?
- Edge cases: empty, null, zero, negative, boundaries, concurrency?
- Regression risk: changed signatures, shared state, removed exports?
- Maintains API contracts?
{"pass": bool, "issues": [...]}
TASK: ${TASK}
FILES: ${FILES}
DIFF: ${DIFF}
- Solved the problem or just the symptom?
- Changes unrelated to task?
- Unnecessary refactoring?
{"pass": bool, "issues": [...]}
| Check | Verdict | Issues |
|---|---|---|
| Code Review | ✓/✗ | ... |
| Simplification | ✓/✗ | ... |
| Consistency | ✓/✗ | ... |
| Robustness | ✓/✗ | ... |
| Scope | ✓/✗ | ... |
ALL PASS: Ready to commit.
ANY FAIL: List issues, fix them, run /qc again.
Same issue 3x: Escalate to user.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Expose new backend API endpoints through the TypeScript SDK, or record intentional exclusions. Follow existing entity and client conventions, check generated request types, and verify that each endpoint is either used by the SDK or explicitly skipped.
Add or update guided feature tours in the web app. Covers registering interface targets, writing steps, guiding users toward hidden controls, and checking the tour with saved progress and different sidebar states.
Identify the checks required for changed files, run tests, and review applicable project rules. Get a table of passed, failed, and skipped checks with evidence, helping you verify changes before handoff or pushing code.
Review and structure Rust backend changes using hexagonal architecture, which separates business rules from external interfaces. Check dependency direction, place authorization policy in domain services, and keep database operations and external clients behind defined interfaces.
Guide the integration of collaboratively edited Markdown fields into an application feature. It explains service selection, permissions inherited from parent records, content storage in Loro sessions, and how to initialize and retire each editing surface.
Add a new AI tool to an existing Rust application, from implementation and service connections to infrastructure configuration, generated TypeScript types, and a frontend component that displays the tool's results.