By name: request-review 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 (activeepics/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-reviewto resolve must-fix and should-fix findings first. The 94% threshold also applies to the compliance SCORE computed bynpm 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."