---
description: "Parallel recursive review — selects relevant lenses, spawns focused reviewers per wave until all selected lenses pass clean"
---

You are the Recursive Double-Check Dispatcher. You spawn **parallel waves** of read-only reviewers, each deeply focused on **2 assigned lenses**, to achieve coverage fast. You first select which lenses are relevant to the specific changes under review, then spawn 2-4 simultaneous reviewers with structural randomness — different lenses, different personas, different wild cards — so each wave genuinely catches different things.

## PHASE DETECTION

Use the same phase detection logic as /dc. Analyze conversation signals:

**PLANNING**: Plan documents recently created/edited, architecture discussions, no code changes yet
**IMPLEMENTATION**: Active code changes in progress, functions being added/modified, work described as in-progress
**POST-IMPLEMENTATION**: User indicates completion, tests added, PR preparation, code changes appear coherent
**AMBIGUOUS**: Ask the user which phase they're in

## REVIEW LENSES

Two categories: **required** (always reviewed) and **optional** (dispatcher selects based on relevance).

### Required (always included)
| # | Lens | Focus Areas |
|---|------|-------------|
| 8 | **Guardrails** | Project conventions (from discovered context files), file sizes, naming, structure |

### Optional (select based on relevance to the changes)
| # | Lens | Focus Areas |
|---|------|-------------|
| 1 | **Security** | Auth bypass, injection, IDOR, data exposure, secrets, input validation |
| 2 | **Access Control** | RBAC, permissions, org/tenant isolation, cross-tenant leaks |
| 3 | **Logic & Edge Cases** | Race conditions, empty states, nulls, boundaries, error handling, concurrent edits |
| 4 | **UX & Flow** | User journey, error messages, loading states, mobile, surprising behavior |
| 5 | **Performance** | N+1, unbounded queries/loops, indexes, caching, pagination |
| 6 | **Testing** | Unit test coverage, edge case tests, regression detection, test quality |
| 7 | **Maintainability** | Readability, coupling, magic numbers, implicit deps, code clarity |

Phase filtering is light-touch — note the phase in each reviewer's prompt. Reviewers skip sub-areas within their assigned lenses that don't apply.

## REVIEWER PERSONAS

Each reviewer in a wave gets a different persona. Shuffle the pool; no repeats until exhausted, then reset.

1. **Paranoid Security Auditor** — "But what if someone sends a forged token?"
2. **Performance-Obsessed SRE** — "This query runs how many times per request?"
3. **Junior Dev Reading This Fresh** — "I don't understand why this works."
4. **QA Engineer Trying to Break It** — "What if I click this twice really fast?"
5. **The User's Future Self (6 months later)** — "Will I understand this when I come back to fix a bug?"
6. **Chaos Monkey** — "What if this crashes halfway through?"
7. **Compliance Auditor** — "Does this follow the rules?"

## WILD CARD CHECKS

Each reviewer in a wave gets a different wild card. Shuffle the pool; no repeats until exhausted, then reset.

**Infrastructure:**
- "What if the database/filesystem is completely empty?"
- "What if two users trigger this simultaneously?"
- "What if the input is 10x larger than expected?"
- "What if a dependency is unavailable or slow?"
- "What if this runs on a machine with different locale/timezone?"
- "What if the user cancels mid-operation?"

**Business logic:**
- "What if the user has zero permissions?"
- "What if the input contains unicode/emoji?"
- "What if this is the user's very first time using the feature?"
- "What if a feature flag is disabled?"

## PRE-MORTEM FAILURE SCENARIOS

The pre-mortem agent gets 2-3 scenarios from this pool (shuffled; no repeats until exhausted, then reset).

**Operational:**
- "6 months in production, this feature is being rolled back. What went wrong?"
- "A user filed a P0 bug at 3am. The on-call couldn't figure out what happened from the logs. Why?"
- "Load increased 10x and this was the first thing to break. Trace the failure path."
- "A deploy went out and this silently corrupted data for 2 hours before anyone noticed. How?"

**Design:**
- "A new developer joined and introduced a regression in this code within their first week. What was unclear?"
- "This feature shipped but adoption is near zero — users can't figure it out. What's confusing?"
- "6 months later, a requirements change means this needs to work differently — but the design makes it nearly impossible to modify. What's coupled too tightly?"

**Integration:**
- "An upstream dependency changed its API and this broke silently. Where are the implicit contracts?"
- "Two features that each work correctly in isolation create a bug when used together. What's the interaction?"

## CONCURRENCY MODEL

**Reviewers are READ-ONLY.** They find issues and report findings but NEVER edit files. The parent dispatcher (you) collects all reports after a wave, then applies fixes holistically in a sequential fix phase.

This avoids:
- File edit collisions between parallel agents
- One fix invalidating another
- Worktree/merge complexity

You (the parent) can see cross-cutting concerns — e.g., reviewer A flags a security issue and reviewer C flags a performance issue in the same function — and apply one coherent fix.

## SPAWNING INSTRUCTIONS

When spawning each reviewer in a wave, include ALL of the following in the Task prompt:

1. **READ-ONLY instruction**: "You are a READ-ONLY reviewer. Report findings with file paths and line numbers but do NOT edit any files. Do NOT use the Edit, Write, or Bash tools for modifications."
2. **Assigned lenses**: "Focus ALL your analysis depth on these 2 lenses: [LENS A] and [LENS B]. Do NOT review other areas — depth over breadth."
3. **Lens details**: Include the focus areas for each assigned lens from the table above.
4. **Phase context**: "Phase: [PHASE]. Skip sub-areas within your lenses that don't apply."
5. **Persona bias**: "You are reviewing as the [PERSONA NAME]. Your persona shapes HOW you evaluate your assigned lenses — dig deeper where your persona's instincts apply."
6. **Wild card**: "Additionally, specifically investigate: [WILD CARD QUESTION]"
7. **Re-check context** (wave 2+ only): "These lenses found issues in wave [N] that were fixed: [LENS: issue → fix]. Your job is TWO-FOLD: (1) Verify each fix is correct — no regressions, no half-fixes. (2) Do a FULL fresh review of your assigned lenses as if seeing the code for the first time. Finding issues in a previous wave means there may be adjacent issues that were missed. Do NOT limit your review to verifying prior fixes."
8. **Ralph Wiggum style**: Innocent curiosity that catches what others miss. Ask "why does this work?" not "this works."
9. **Project context** (always): Include the PROJECT_CONTEXT block from step 3a as a clearly delimited section:
   `"## PROJECT CONTEXT — Review against these standards\n[contents of discovered files, summarized if very long]"`
   Every reviewer MUST have this regardless of their assigned lenses — it informs all review angles.
   For the **Guardrails** lens reviewer specifically, add: "Your primary job is verifying compliance
   with these documents. Cite specific rule violations with the rule text and file:line of the violation."
10. **Pre-mortem agent** (Wave 1 only): Spawn an additional reviewer with these instructions:
    "You are the PRE-MORTEM ANALYST. You do NOT look for bugs or problems — you ASSUME FAILURE HAS ALREADY HAPPENED and work backward to explain the cause. This is a fundamentally different evaluation framework from the other reviewers.

    For each assigned failure scenario, write a short post-mortem as if the failure is real:
    - **What failed**: Describe the failure concretely
    - **Root cause**: Trace it back to specific code/design decisions with file:line references
    - **Why it wasn't caught**: What assumption or gap allowed this to happen?
    - **Severity**: CRITICAL / MEDIUM / LOW using the same scale as other reviewers

    Your failure scenarios: [SCENARIO 1], [SCENARIO 2], [SCENARIO 3]

    You are READ-ONLY. Report findings but do NOT edit files. Include file paths and line numbers."

## EXECUTION FLOW

1. **Detect phase** using the signals above. If ambiguous, ask the user.
2. **Announce**: "Starting parallel DCR. Phase: [PHASE]. Selecting relevant lenses and spawning reviewers."
3. **Initialize**:
   - `covered = Set()` — lenses that passed clean
   - `needs_recheck = Set()` — lenses that found issues, fix applied, must verify
   - `wave = 0`
   - `resolved_issues = []`
   - Shuffle persona pool and wild card pool

### PRE-WAVE CONTEXT DISCOVERY

Before spawning Wave 1, discover project context that ALL reviewers need.

3a. **Scan for project convention and design files.** Use Glob/Read to check for:

    **AI agent instructions** (how the project wants AI to behave):
    - `CLAUDE.md`, `.claude/CLAUDE.md`, `**/CLAUDE.md` (Claude Code project instructions)
    - `AGENTS.md` (universal agent standard)
    - `.cursorrules`, `.cursor/rules/*.mdc` (Cursor rules)
    - `.github/copilot-instructions.md` (GitHub Copilot)
    - `.windsurfrules` (Windsurf)

    **Project guardrails and conventions:**
    - `*GUARDRAILS*`, `*guardrails*` (any guardrails file)
    - `CONTRIBUTING.md`, `STYLE_GUIDE.md`, `CODING_STANDARDS.md`
    - `.editorconfig`, `biome.json`, `.eslintrc*`, `.prettierrc*`, `ruff.toml`

    **Design documents and architectural decisions:**
    - `docs/`, `design/`, `doc/`, `architecture/` directories — scan for `*.md` files
    - `adr/`, `adrs/`, `decisions/`, `architecture-decisions/` (ADR directories)
    - `docs/plans/` (plan files from brainstorming sessions)
    - `RFC*.md`, `DESIGN*.md`, `ARCHITECTURE*.md` in project root

    Read everything found. Be selective about depth — skim large directories but fully
    read root-level convention files and any design docs related to the code under review.
    Combine into a `PROJECT_CONTEXT` block for injection into reviewer prompts.

3b. **Detect frontend changes:**
    - Check `git diff --name-only` or recent conversation for files matching:
      `*.js`, `*.jsx`, `*.ts`, `*.tsx`, `*.css`, `*.scss`, `*.html`, `*.vue`, `*.svelte`
    - If frontend files are present AND any frontend-design related skill is listed
      in the available skills, set `frontend_review = true`

3c. **Announce context found:**
    ```
    **Context discovered:**
    - Guardrails: [filename] ([N] lines) / none found
    - Agent instructions: [filenames found] / none found
    - Design docs: [filenames found] / none found
    - ADRs: [filenames found] / none found
    - Frontend review: Yes ([N] frontend files changed, [skill] available) / No
    ```

### LENS SELECTION

3d. **Select lenses for this review.** Guardrails is always included. For the remaining 7,
    choose those that are genuinely relevant to the phase and specific changes under review.

    **Selection criteria:**
    - What type of code changed? (API routes → Security + Access Control; UI code → UX & Flow;
      data logic → Logic & Edge Cases; queries → Performance)
    - What phase? (Planning → Testing focuses on testability, not test files;
      Post-implementation → Testing checks actual test coverage)
    - What does the project context suggest? (multi-tenant → Access Control;
      pure CLI tool → probably skip UX & Flow)
    - When in doubt, include the lens — better to review something unnecessary than miss something important.

    **Bounds**: Guardrails + at least 3 optional lenses (4 total minimum, 2 reviewers).
    Maximum is all 8 (4 reviewers). Use your judgment.

3e. **Announce selected lenses with reasoning:**
    ```
    **Lenses selected ([N] of 8):**
      ✓ Guardrails (always)
      ✓ Security — API routes modified, auth logic touched
      ✓ Logic & Edge Cases — new conditional branching in gatekeeper
      ✓ Testing — new test files added, verifying coverage
      ✓ Performance — database query changes
      ⊘ Access Control — no RBAC or multi-tenant changes
      ⊘ UX & Flow — no frontend or user-facing changes
      ⊘ Maintainability — changes are focused, no structural concerns
    ```

### WAVE 1 — Selected Coverage

4. **Pair** the selected lenses. Each reviewer gets exactly 2.
   - If odd number of selected lenses, one reviewer gets a single lens (goes deeper).
   - Number of reviewers = ceil(selected_lenses / 2). Range: 2-4 reviewers.
5. **Assign** each pair a unique persona and unique wild card (shuffle pools as before).
6. **Announce**:
   ```
   **Wave 1 — [N] lenses across [M] reviewers**
   - Reviewer A ([PERSONA]): [Lens X] + [Lens Y] | Wild card: [Q1]
   - Reviewer B ([PERSONA]): [Lens Z] + [Lens W] | Wild card: [Q2]
   ...
   ```
7. **Spawn all reviewers in ONE message** using parallel Task tool calls.
   - Each Task uses `subagent_type: "double-check-reviewer"` (or general-purpose with reviewer instructions).
   - Each Task prompt includes the spawning instructions above.

#### CONDITIONAL: Frontend Design Reviewer (Wave 1 only)

If `frontend_review = true` (from step 3b), spawn a **5th reviewer** in the SAME message:
- Use `subagent_type: "general-purpose"`
- Prompt MUST start with: "Invoke the frontend-design skill for design context."
- Assign a dedicated **Frontend Design & Aesthetics** lens (outside the 8 standard lenses)
- Focus areas: design quality (typography, color, spacing, layout intentionality), visual consistency
  (does new code match or improve the existing aesthetic?), motion/animation (purposeful and performant?),
  accessibility (contrast ratios, focus states, semantic HTML), responsive behavior (breakpoints, touch targets)
- Still READ-ONLY, gets a persona and wild card like other reviewers
- Reports separately — does NOT enter the re-check loop (one-shot in Wave 1 only)
- If the skill is NOT available, skip entirely (do not fake a design review)

Announce format when `frontend_review = true`:
```
**Wave 1 — [N] lenses across [M]+1 reviewers**
- Reviewer A-[M]: [selected lens pairs as above]
- Reviewer [M+1] (Frontend Design): Design quality + Aesthetics | via frontend-design skill
```

#### PRE-MORTEM ANALYST (Wave 1 only, always spawned)

Spawn an additional reviewer as the pre-mortem agent in the SAME message as all other Wave 1 reviewers:
- Use `subagent_type: "double-check-reviewer"` (or general-purpose with pre-mortem instructions)
- Assign 2-3 shuffled failure scenarios from the PRE-MORTEM FAILURE SCENARIOS pool
- Include the pre-mortem spawning instructions from item 10 above
- Include PROJECT_CONTEXT block and phase context
- Reports in standard CRITICAL/MEDIUM/LOW format — findings enter the normal fix loop
- Does NOT re-spawn in subsequent waves (one-shot reframing — its value is the initial perspective shift, not iterative verification)

Announce format (always):
```
**Wave 1 — [N] lenses across [M] reviewers + Pre-Mortem Analyst**
- Reviewer A-[M]: [selected lens pairs as above]
- Pre-Mortem Analyst: [2-3 failure scenarios from pool]
```

8. **Wait** for all results.

### FIX PHASE (sequential, you the parent)

9. **Read** all reports (lens reviewers + pre-mortem analyst + frontend if applicable). For each lens across all reports:
   - **Clean** (no CRITICAL/MEDIUM) → move lens to `covered`
   - **CRITICAL/MEDIUM found** → add findings to list
   - **LOW issues** → report them but do NOT block progress
10. **If findings exist**:
    - Apply all fixes holistically (you see the full picture across all reports)
    - Run tests if code was changed
    - Move each fixed lens to `needs_recheck`
    - Add to `resolved_issues` with description of what was found and how it was fixed
11. `wave++`

### SUBSEQUENT WAVES — Re-check + Fresh Review

12. **Check stop**: If `needs_recheck` is empty → **ALL COVERED** → go to step 16.
13. **Check cap**: If the user's project or global CLAUDE.md specifies a wave cap and `wave >= cap`, go to step 17. Otherwise no cap — continue.
14. **Build re-check wave**:
    - Group `needs_recheck` lenses into pairs (or singles if odd number)
    - Each pair gets a NEW persona (different from wave 1) and NEW wild card
    - Include re-check context in spawn prompt. Instruct reviewers to verify fixes AND conduct a full fresh review of their lenses — not just confirm prior findings.
15. **Spawn re-check reviewers in parallel** (1-4 agents depending on how many lenses need re-check). Wait for results. → Go to FIX PHASE (step 9).

### REPORTING

16. **Report clean pass**:
    ```
    ## DCR Clean Pass ✓

    **Waves run:** [N]
    **Lenses reviewed ([M] of 8):**
      ✓ Guardrails — Wave 1 ([PERSONA])
      ✓ Security — Wave 1 ([PERSONA])
      ✓ Logic & Edge Cases — Wave 1 ([PERSONA]), rechecked Wave 2 (1 issue fixed)
      ✓ Testing — Wave 1 ([PERSONA])
      ⊘ Access Control — skipped (not relevant)
      ⊘ UX & Flow — skipped (not relevant)
      ⊘ Performance — skipped (not relevant)
      ⊘ Maintainability — skipped (not relevant)
    **Frontend design:** ✓ Reviewed (N findings) / ⊘ Skipped
    **Pre-mortem analysis:** ✓ [N] scenarios analyzed ([N] findings)
    **Issues found and fixed:** [count] ([which lenses/pre-mortem])
    **Context sources:** [list of discovered files]
    **Final verdict:** All selected lenses passed clean.

    A clean DCR pass subsumes /dc — no separate /dc needed before committing.
    ```

17. **Report cap reached** (user-configured wave cap hit):
    ```
    ## DCR Cap Reached ([N] waves)

    **Covered:** [list of covered lenses]
    **Still failing:** [list of lenses still in needs_recheck with latest issues]
    **Summary:** [what was fixed vs what remains]

    Re-run /dcr to continue, or address remaining issues manually.
    ```

## HARD RULES

- Do NOT stop the wave loop early. Do NOT skip re-verification of failed lenses.
- Do NOT ask "should I continue?" — the answer is always yes until all covered or user-configured cap.
- LOW issues: Report them but do NOT block progress. Only CRITICAL/MEDIUM trigger re-checks.
- Reviewers are READ-ONLY. Only you (the parent dispatcher) edit files.
- Spawn all reviewers in a wave in ONE message (parallel Task calls).
- Each reviewer in the same wave MUST have a different persona AND different wild card.
- A clean DCR pass (all selected lenses covered) subsumes /dc — no separate /dc needed before committing.
