Windsurf rules

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