Cursor rule

1---
2description: "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."
3alwaysApply: false
4---
5 
6# story: e45s28
7 
8# Request Review
9 
10Dispatch fresh reviewer agents with clean contexts. Reviewers have no shared state — they find what the coding agent missed.
11 
12**Distinct from `audit-code`:** `audit-code` is self-review (internal). This skill dispatches external agents.
13 
14**Solo developer note:** Reviewer agents replace the human reviewer.
15 
16**Run `audit-code` first.** Don't waste reviewer attention on hygiene issues you could have caught yourself.
17 
18## Santa Method — Dual-Blind AND Gate (e45s07)
19 
20Use **two independent reviewers** (Reviewer A and Reviewer B) with **no shared context** between them or the coding agent.
21 
22| Parameter | Value |
23|-----------|-------|
24| Reviewers | 2 (mandatory) |
25| `MAX_REVIEW_ITERATIONS` | **5** (hard cap — e45s28; iteration 6 forbidden) |
26| Pass rule | **AND-gate** — both reviewers must pass independently |
27| Blindness | Neither reviewer sees the other's report until both complete |
28 
29**Iteration loop (max `MAX_REVIEW_ITERATIONS`):**
30 
311. Dispatch Reviewer A and Reviewer B in parallel with identical briefs but separate contexts.
322. Collect both reports. Each categorizes findings: must-fix / should-fix / consider.
333. **AND-gate:** If **either** reviewer has must-fix findings → FAIL round. Run `respond-review`, fix, re-dispatch both reviewers.
344. If both pass (zero must-fix, score ≥ 94% each) → review complete.
355. After **5** iterations without dual pass → **stop**; report "Review cap exhausted (5/5). Human decision required." Do not merge.
36 
37> **HARD GATE** — Single-reviewer pass is insufficient. Partial agreement does not satisfy the AND-gate.
38 
39## Process
40 
41### 1. Prepare the review brief
42 
43Write a self-contained brief for each reviewer. Include:
44 
45- What was built (feature description, not implementation)
46- Which files changed (the diff context)
47- What `specs/` artifacts are relevant (active `epics/eNN-*.yaml`, `requirements/SCOPE_LATEST.yaml`, `bugs/BUG-*.md`)
48- What CONVENTIONS.md requires
49- What the verify command is
50- What you're most uncertain about (where you want fresh eyes)
51- **Security focus** — If the epic has a `specs/security/epics/<id>/THREAT_MODEL.md`, include the relevant vulnerability categories as reviewer focal points. Also include the false-positive exclusion rules so the reviewer avoids known-safe patterns. Tag the review as `security-sensitive: true` if THREAT_MODEL risk is HIGH+.
52 
53### 2. Fan-out parallel reviewers (e45s17)
54 
55Beyond the mandatory dual-blind pair (e45s07), optionally dispatch **N dimension-specific subagents in one message** — one check per agent for broader coverage (OpenAI Codex `code-review-*` pattern):
56 
57| Agent | Focus |
58|-------|-------|
59| R-correctness | Logic, edge cases, verify command result |
60| R-conventions | CONVENTIONS.md, test quality (F.I.R.S.T) |
61| R-security | Injection, auth, secrets (when `security-sensitive`) |
62| R-design | Simpler alternatives, API shape |
63 
64Santa Method still applies: each agent is blind; AND-gate uses Reviewer A + B scores. Fan-out agents feed findings into `respond-review` but do not replace the dual-blind pair.
65 
66### 2b. Dispatch both reviewer agents (parallel)
67 
68Use the Agent tool twice with completely fresh contexts. Each prompt must be self-contained — no references to "our conversation" or "what we discussed."
69 
70```
71You are code reviewer [A|B]. Review the following code changes independently.
72 
73Context: [feature description]
74CONVENTIONS.md rules: [paste relevant sections]
75Active epic shard: [paste or summarize from specs/epics/]
76 
77Diff: [paste git diff or describe changed files]
78 
79Verify command: [runnable command]
80 
81Review for:
821. Correctness — does the code do what was intended?
832. CONVENTIONS.md compliance — are all rules followed?
843. Test quality — do tests verify behavior (not implementation)?
854. Design — are there simpler or more robust approaches?
865. Edge cases — what inputs or states could cause failures?
876. Security — any injection, auth, or data exposure risks?
887. Refactoring smells — explicitly name any detected Fowler smells: Mysterious Name, Duplicated Code, Feature Envy, Data Clumps, Primitive Obsession, Message Chains, Middle Man
89 
90For each finding, categorize as: must-fix / should-fix / consider.
91Run the verify command and report the result.
92```
93 
94### 3. Collect both reports
95 
96When reviewers return:
97- Read every finding from **both** reports before acting on any
98- Note each verify command result
99- Compute quality score per reviewer: `100 × (total_items − must_fix − should_fix) / total_items`
100- **AND-gate check:** both scores ≥ 94% and zero must-fix from **both**?
101 
102> **HARD GATE** — If either score < 94% or either has must-fix → FAIL round. Run `respond-review` first. The 94% threshold also applies to `npm run compliance` (scripts/audit-compliance.sh).
103 
104### 4. Hand off to respond-review
105 
106Pass combined findings to `respond-review` to categorize and apply fixes. Increment iteration counter. Re-dispatch both reviewers until AND-gate passes or iteration 3 exhausted.
107 
108Report to user: "Review round [N/3]. Reviewer A: [score], Reviewer B: [score]. AND-gate: [PASS|FAIL]."
109 
110## Verify
111 
112→ verify: `test -f scripts/lib/parallel-review-worktrees.sh && test -f skills/request-review/SKILL.md`
113