request-review

name: request-review model: opus description: Dispatch a fresh reviewer agent with a clean context to critique the code after audit-code passes. The reviewer has no shared state with the coding agent and gives a genuine second opinion. Use after audit-code passes, before committing, or when user wants an independent code review.

Request Review

Dispatch a fresh reviewer agent with a clean context. The reviewer has no shared state — it can give a genuine second opinion because it hasn't been involved in writing the code.

Distinct from audit-code: audit-code is the coding agent checking its own work (internal). This skill dispatches an external agent whose job is to find what the coding agent missed.

Solo developer note: This replaces the human reviewer. The reviewer agent IS the reviewer.

Run audit-code first. This skill assumes audit-code has already passed. Don't waste a reviewer's attention on hygiene issues you could have caught yourself.

Process

1. Prepare the review brief

Write a self-contained brief for the reviewer agent. Include:

• What was built (feature description, not implementation)
• Which files changed (the diff context)
• What specs/ artifacts are relevant (active epics/eNN-*.yaml, requirements/SCOPE_LATEST.yaml, bugs/BUG-*.md)
• What CONVENTIONS.md requires
• What the verify command is
• What you're most uncertain about (where you want fresh eyes)

2. Dispatch the reviewer agent

Use the Agent tool with a completely fresh context. The agent prompt must be self-contained — no references to "our conversation" or "what we discussed."

You are a code reviewer. Review the following code changes.

Context: [feature description]
CONVENTIONS.md rules: [paste relevant sections]
Active epic shard: [paste or summarize from specs/epics/]

Diff: [paste git diff or describe changed files]

Verify command: [runnable command]

Review for:
1. Correctness — does the code do what was intended?
2. CONVENTIONS.md compliance — are all rules followed?
3. Test quality — do tests verify behavior (not implementation)?
4. Design — are there simpler or more robust approaches?
5. Edge cases — what inputs or states could cause failures?
6. Security — any injection, auth, or data exposure risks?

For each finding, categorize as: must-fix / should-fix / consider.
Run the verify command and report the result.

3. Collect the report

When the reviewer returns:

• Read every finding before acting on any
• Note the verify command result
• Compute the quality score: 100 × (total_items − must_fix − should_fix) / total_items
• Report the score to the user

HARD GATE — If score < 94%, do NOT merge. Run respond-review to resolve must-fix and should-fix findings first. The 94% threshold also applies to the compliance SCORE computed by npm run compliance (scripts/audit-compliance.sh): SCORE = passing Gherkin scenarios / total × 100.

4. Hand off to respond-review

Pass the reviewer's report to respond-review to categorize findings and apply fixes.

Report to user: "Review complete. [N] findings: [X] must-fix, [Y] should-fix, [Z] consider. Running respond-review."