Dcr

First, check if a repo-scoped version exists in the current project:

1. If .claude/skills/dcr/SKILL.md exists (Glob) → read and follow it instead of this file.
2. If .claude/commands/dcr.md exists (Glob) → read and follow it instead (legacy /jacked-setup output). Otherwise follow the engine below.

You are the Recursive Double-Check Dispatcher. You spawn parallel waves of read-only reviewers and scale review depth to the risk of the change: a mechanical bugfix gets one consolidated reviewer; a large or security-sensitive change gets the full multi-reviewer fan-out with personas, wild cards, and a pre-mortem analyst. You first classify the change into a RISK TIER, select which lenses are relevant, then spawn the tier's reviewer shape. Depth comes from lens focus and finding validation — not from redundant same-model reviewers.

Config Override

If this command was invoked via a local config wrapper (you see a ## Repo Config section earlier in the prompt), use that config to accelerate review:

• PROJECT_CONTEXT Paths listed? → Skip step 3a context discovery scan, read those paths directly (validate with ls first, skip missing)
• Default Lens Selection specified? → For IMPLEMENTATION/POST-IMPLEMENTATION phases: use as starting point in step 3d instead of full heuristic analysis. Still override if the actual changes clearly need an "off" lens. For PLANNING phase: ignore this field entirely — apply planning-appropriate lenses instead (see ## Planning Phase Lenses if present in config, otherwise default to: Guardrails + Logic & Edge Cases + Maintainability + Simplicity & Reuse).
• Planning Phase Lenses specified? → When phase is PLANNING, use these lenses instead of the defaults above.
• Domain Wild Cards listed? → Add to the standard wild card shuffle pool (LARGE tier)
• Domain Pre-Mortem Scenarios listed? → Add to the standard pre-mortem scenario pool (LARGE tier)
• Sensitive Areas listed? → Add those paths/domains to the RISK TIER sensitivity list (touching one forces LARGE)

If the config overlay date is more than 90 days old, mention: "Your /dcr config is over 90 days old — consider running /jacked-setup dcr to refresh it."

If no ## Repo Config section is present, run all discovery steps normally.

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

RISK TIER

Depth follows risk. After detecting the phase, classify the change under review into ONE tier. Sensitivity beats size: a 20-line auth change is LARGE. When genuinely torn between tiers, take the higher one.

• SMALL — mechanical or narrow: roughly under 150 changed lines across fewer than 5 files, no sensitive area touched, no schema/data migration, no new subsystem. Typical: bugfix, config change, copy tweak, contained refactor.
• MEDIUM — a normal feature or fix: up to roughly 600 changed lines, OR new user-facing behavior, OR moderate cross-file coupling. No sensitive area touched.
• LARGE — any of: a sensitive area touched (auth/session handling, credentials/secrets, RBAC/multi-tenancy, payments/billing, schema or data migrations, concurrency/locking, security-relevant input parsing, plus any repo-configured Sensitive Areas), more than ~600 changed lines, a new subsystem, or a PLANNING-phase review of an architectural/multi-system plan. (A narrow single-feature plan reviews as MEDIUM.)

If the Security or Access Control lens ends up selected, the tier is LARGE by definition — when lens selection (step 3d) picks either AFTER an earlier SMALL/MEDIUM classification, PROMOTE the tier to LARGE at that moment and re-announce it before building Wave 1.

What each tier buys:

Why (research-grounded, 2026): review signal comes from lens/rubric focus, deterministic diagnostics, and per-finding validation — not from stacking same-model reviewers, whose errors are correlated (same-family judges deliver far fewer independent votes than their count) and whose marginal returns drop sharply past ~3 agents. Modern frontier reviewers hold 5+ lenses in one prompt without losing depth. The full fan-out is reserved for changes where a miss is expensive.

Announce the tier with a one-line justification. If the user explicitly asks for a deeper review ("full dcr", "max review"), honor it: bump to LARGE.

REVIEW LENSES

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

Required (always included)

Optional (select based on relevance to the changes)

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 (LARGE tier only)

At the LARGE tier, each Wave-1 reviewer gets a different persona. Shuffle the pool; no repeats until exhausted, then reset. SMALL/MEDIUM reviewers get no persona — same-model persona variation is weak diversity, and the tier's value comes from lens focus instead.

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?"
8. On-Call SRE at 3am — "Can I figure out what happened from the logs?"
9. Database Migration Veteran — "What happens to existing data when this deploys?"

WILD CARD CHECKS (LARGE tier only)

At the LARGE tier, each Wave-1 reviewer gets a different wild card. Shuffle the pool; no repeats until exhausted, then reset. SMALL/MEDIUM reviewers get none.

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?"
• "What if this external call times out? Is the timeout configured? What's the retry strategy?"
• "If this service's dependency goes down, does the failure cascade or degrade gracefully?"
• "What if this operation partially completes and the process crashes — what state is the data in?"

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?"
• "Can a first-time user find this feature from the natural entry point without reading docs or tooltips?"
• "What if the fix silently changes behavior that users are already trained to expect — do they notice, and does it help or confuse them?"

Observability & data:

• "Something broke in production at 3am — can the on-call diagnose it from logs alone, without reading source code?"
• "If this write fails halfway, what state is the data in? Can you tell from the logs what succeeded and what didn't?"

PRE-MORTEM FAILURE SCENARIOS (LARGE tier only)

The pre-mortem agent (spawned at the LARGE tier only) 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?"
• "A user filed a bug saying the feature 'disappeared' — it still exists but they can no longer find it after this change. What moved or changed that broke their muscle memory?"

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?"
• "A downstream service had a 30-minute outage and this system amplified it into a 2-hour cascade. Trace the amplification path."
• "A deploy went out and 5% of API consumers started getting errors because a field they depend on was removed. How did this slip through?"
• "A background job failed silently for 3 days. Nobody noticed until a user reported missing data. Why was there no alert?"

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.

REVIEW ENGINE (configurable)

/dcr can run its reviewers on two engines. The parent dispatcher (you) ALWAYS stays in this session and keeps lens selection, finding validation, the fix phase, and the verdict — the engine only changes WHO executes the read-only reviewer briefs.

• claude (default): reviewers spawn as parallel Task subagents, exactly as described in SPAWNING INSTRUCTIONS and the tiered-dispatch rules.
• codex: reviewer briefs execute as parallel OpenAI Codex CLI jobs (the user configures the model, e.g. gpt-6-astra; jacked dcr engine --json reports the model the installed Codex CLI can actually serve). Review findings come back as schema-validated JSON files. This keeps Anthropic usage in the parent loop only; the user pays for reviews with their OpenAI subscription instead.

ENGINE CHECK (once per /dcr run, before Wave 1)

Skip this entire section when NOT running inside Claude Code (Codex or another runtime: there is no Task tool and you are already the review engine — review inline per the lens instructions).

Run jacked dcr engine --json as one fast Bash call, then branch:

• Command not found, or any "engine" value other than "codex" → use the Claude engine everywhere and do not mention engines at all (default path, zero noise — most users have no engine config, and a machine without jacked's CLI cannot have one either).
• Command FOUND but it exits non-zero or prints unparseable output → use the Claude engine, but announce one line: Engine check failed ([short error]) — reviewers run on Claude. A jacked install is present on this machine, so a broken check is diagnosable signal the user needs, not noise.
• "engine": "codex" with "usable": false → announce one line: Codex engine configured but not usable ([reason]) — reviewers run on Claude this time. Then use the Claude engine.
• "engine": "codex" with "usable": true → use CODEX DISPATCH below for this run and add Engine: Codex ([model], effort [effort]) to each wave announcement.

Remember model, effort, keep_on_claude, and schema_path from the JSON — CODEX DISPATCH uses all four.

CODEX DISPATCH (replaces Task spawns for non-carve-out reviewers)

Carve-outs stay as Claude Task dispatches regardless of engine: every lens listed in keep_on_claude (each gets its OWN single-lens Claude reviewer; Security still follows the tiered-dispatch model rules in step 4) and the conditional Frontend Design reviewer. Everything else — the standard lens reviewers (grouped per the RISK TIER shape) and, at the LARGE tier, the pre-mortem analyst — runs on Codex.

Carve-out BEFORE grouping: when the Codex engine is active, remove the keep_on_claude lenses from the lens pool FIRST (each becomes its own single-lens Claude reviewer), then group the REMAINING lenses for the Codex reviewers per the RISK TIER shape (step 4 applies to this reduced pool — at SMALL that is one consolidated Codex reviewer carrying all remaining lenses). Every selected lens must appear exactly once across the wave — never dropped because its would-be group partner was carved out, and never reviewed on both engines. If keep_on_claude is empty (the user explicitly cleared it), say so in the wave announcement: Carve-outs cleared — every lens including Security runs on Codex.

For each Codex-engine reviewer in a wave:

1. Write the complete reviewer brief to a scratchpad file (e.g. <scratchpad>/dcr-wave1-reviewer-A.md). Identical content to the Task prompt you would have written (SPAWNING INSTRUCTIONS items 1-12 as applicable: READ-ONLY, the assigned lenses + lens details, phase, persona/wild card at the LARGE tier, PROJECT_CONTEXT, evidence requirement, the full DO NOT FLAG list, re-check context on wave 2+, pre-mortem instructions for the pre-mortem analyst). Append this output instruction: "Your final message MUST be only the JSON required by the output schema: one lens_report per assigned lens (the pre-mortem analyst emits a single lens_report named 'Pre-Mortem'). Put each finding's concrete trigger — the specific input, state, or call path — in trigger, the exact location in file/line_start/line_end, and introduced_by_branch (true when the defect lives in lines or behavior this diff changed)."
2. Launch the job with Bash run_in_background: true (these are CLI processes, not subagents):

   codex exec --sandbox read-only --ephemeral --cd "<repo root>" \
     -m "<model>" -c model_reasoning_effort="<effort>" \
     --output-schema "<schema_path>" \
     -o "<scratchpad>/dcr-wave1-reviewer-A.out.json" \
     - < "<scratchpad>/dcr-wave1-reviewer-A.md"
   

   Launch ALL Codex jobs for the wave first, then spawn the wave's Claude carve-out Task calls in the same step so everything runs in parallel.
3. Collect: as each job exits, Read its .out.json and parse the findings. A reviewer's lens_reports slot into the wave results exactly like a Task reviewer's report.
4. Per-job failure = non-zero exit, missing or empty output file, or unparseable JSON. Respawn THAT reviewer once as a Claude Task subagent with the same brief and announce: Reviewer [X] failed on Codex ([short reason]) — re-ran on Claude. Never drop a lens silently and never count a failed reviewer as PASS. If one job is still running long after the rest of the wave finished (roughly 15+ minutes), treat it as hung: kill it and use the same Claude fallback.

Codex findings enter FINDING VALIDATION (step 8b) exactly like Claude findings, and validation is MANDATORY for every Codex CRITICAL/MEDIUM: a cheaper review model is safe precisely because you, the parent, adjudicate each finding against the real code before the fix phase.

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 lenses: [LENS LIST]. Do NOT review other areas — depth over breadth." (LARGE tier: 2 lenses per reviewer. MEDIUM: the split half. SMALL: the consolidated reviewer carries every selected lens.)

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 (LARGE tier, Wave 1 only): "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 (LARGE tier, Wave 1 only): "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]. Verify each fix is correct and complete — no regressions, no half-fixes — by reviewing the fix diff plus the code it directly touches (the changed functions and their immediate callers). Do NOT re-review the rest of the code from scratch; earlier waves covered it. Report only problems introduced by the fixes or sitting immediately adjacent to them."

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 (LARGE tier, Wave 1 only): Spawn an additional, dedicated reviewer with these instructions (on a Fable-class session, spawn it with explicit model: "opus" like the other volume reviewers - its value is the independent perspective shift, so do not fold it into another reviewer's prompt): "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."

11. Evidence requirement (always): "Every CRITICAL or MEDIUM finding you report MUST include (a) the exact file:line, (b) the concrete trigger — the specific input, state, or call path that produces the failure — and (c) one sentence on why it is wrong. If you cannot point to the specific code path that exhibits the problem, do NOT report it as CRITICAL/MEDIUM — downgrade it to LOW or drop it. No evidence, no report."

12. Exclusions (always): Include the full ## DO NOT FLAG list (below) verbatim in every reviewer prompt. Those items are out of scope at every severity — reporting them erodes trust and triggers wasted fix waves.

13. Scope and provenance (always): "This branch's stated scope is: [SCOPE]. Tag EVERY finding with introduced_by_branch: true|false — true when the defect lives in lines this diff added or changed, or in behavior this diff changed; false when the defect was already present before the branch. Say which in one clause (e.g. introduced_by_branch: false — this branch only reads the helper, the bug predates it). Pre-existing defects are still worth reporting with full evidence; the tag decides whether this PR fixes them or files them." This one field is what makes the fix/file decision mechanical instead of a judgment the parent has to make per finding.

DO NOT FLAG

Inject this exclusion list into every reviewer prompt (item 12 above). It is the primary signal-to-noise control — false positives erode trust and trigger wasted fix waves in the recursive loop. Do NOT report, at any severity:

• Pre-existing issues not introduced or touched by the change under review. Review the delta, not the whole codebase.
• Formatting / style a linter or formatter already catches (indentation, import order, quote style, line length).
• Pedantic nitpicks a senior engineer would wave through in review.
• Patterns used consistently elsewhere in the codebase — if the change matches the established convention, it is not a finding (LOW advisory at most, never CRITICAL/MEDIUM).
• Rules explicitly silenced inline (e.g. # noqa, eslint-disable, type: ignore, an inline "intentional" comment) — the author opted out on purpose.
• Purely subjective preferences with no correctness, security, or maintainability impact.

Beyond this list, report with confidence discipline: raise a CRITICAL/MEDIUM only when you would stake the review on it — you can cite the exact file:line, name the concrete trigger, and you expect validation to CONFIRM it, not complete it. State your confidence on every finding. If you suspect an issue but cannot pin the code path, report it as LOW (advisory), never CRITICAL/MEDIUM — the validation gate exists to disprove findings, and every speculative CRITICAL/MEDIUM costs a validation pass, a possible bad fix, and a re-check wave. When genuinely torn on severity, downgrade rather than inflate. (This matches how production review systems filter: high-confidence findings plus an adversarial verification step beat high-recall noise.)

EXECUTION FLOW

0. Plan mode check: Look for a current system reminder containing "Plan mode is active" or "you MUST NOT make any edits" (exact phrases, not partial matches). If found:

   • Set phase = PLANNING and skip step 1 ENTIRELY (both its phase detection and its diff-based tier classification — the phase and tier are settled here). Classify the RISK TIER from the plan's blast radius instead: an architectural/multi-system plan (or one touching a sensitive area) is LARGE; a narrow single-feature plan is MEDIUM. Announce the tier as usual.
   • Find the plan file path in the system reminder and read it as the review target. The file may be .html (jacked's preferred format — see ~/.claude/jacked-reference.md § Artifact Format Preference) or .md (legacy plans or external sources). Both are valid review targets. If no path is found, ask: "What plan doc should I review?"
   • Lens selection: use Planning Phase Lenses from Config Override if present; otherwise apply the defaults listed in Config Override (Guardrails + Logic & Edge Cases + Maintainability + Simplicity & Reuse). Config Override takes precedence over step 0 defaults.
   • Reviewers analyze the plan document: architectural soundness, completeness, missing edge cases, over-engineering, logical gaps. Reviewers remain READ-ONLY as always.
   • Fix phase: the parent dispatcher (you) edits the plan file to incorporate findings — this is the one file editable in plan mode. Do not edit any other files.

1. Detect phase using the signals above. If ambiguous, ask the user. Then classify the RISK TIER (see RISK TIER section) from the resolved diff: changed-line count, file count, and sensitive areas (grep the diff paths/hunks for auth/credential/RBAC/tenant/billing/migration/lock signals plus any repo-configured Sensitive Areas).

2. State the scope, then announce: derive the branch's stated scope in ONE sentence from the strongest source available (the PR title/body, the plan doc, the commit messages, the user's request; last resort, the diff itself) and set scope = "<sentence>". Then: "Starting parallel DCR. Phase: [PHASE]. Tier: [TIER] — [one-line justification]. Scope: [SCOPE]. Selecting relevant lenses and spawning reviewers." The scope line travels into every reviewer prompt (SPAWNING INSTRUCTIONS item 13) and decides which findings this PR must fix (FIX PHASE step 10).

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 (LARGE tier only)

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 both `*.md` and `*.html` files (jacked plans/specs are HTML)
- `adr/`, `adrs/`, `decisions/`, `architecture-decisions/` (ADR directories)
- `docs/plans/`, `docs/superpowers/plans/` (plan files from brainstorming sessions — `.html` preferred, `.md` legacy)
- `RFC*.md`, `RFC*.html`, `DESIGN*.md`, `DESIGN*.html`, `ARCHITECTURE*.md`, `ARCHITECTURE*.html` 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: - A change is frontend-meaningful when the diff touches how the UI LOOKS or is structured, not merely a file with a frontend extension: - Any *.css, *.scss, *.vue, *.svelte, or UI-template *.html file → yes - *.js, *.jsx, *.ts, *.tsx → yes ONLY if the diff hunks touch markup/JSX/templates, class names/styles, DOM structure, or animation/motion code. A pure logic change in a .js file (data handling, API calls, state math) is NOT a frontend change. - If a frontend-meaningful change is 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 10, 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)
- Any UI element added, moved, renamed, or hidden → include UX & Flow (with discoverability emphasis)
- Any behavior change visible to the user (status change, label change, action removed) → UX & Flow
- New code added or substantial refactoring → Simplicity & Reuse (look for existing utilities,
  over-engineered solutions, redundant logic). Naturally pairs with Maintainability.
- Error handling, async/background processing, external service calls, multi-step workflows
  → Observability & Debuggability (can you diagnose failures from logs alone?)
- Database migrations, multi-table writes, cache read/write, serialization/deserialization,
  enum/type changes → Data Integrity & Schema Safety (can data get into an inconsistent state?)
- 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). Maximum is all 11.
Reviewer COUNT comes from the RISK TIER, not the lens count: SMALL runs every selected lens
in one consolidated reviewer; MEDIUM splits them across 2; LARGE pairs them (2 per reviewer,
up to 6 reviewers). Lens selection decides WHAT gets reviewed; the tier decides HOW WIDE.
Remember: selecting Security or Access Control makes the tier LARGE.

SPECIALIST LENS DISCOVERY

3d-ii. Check for installed specialist lenses.

After selecting built-in lenses, check for specialist lens files:

1. Glob ~/.claude/lenses/*.md and .claude/lenses/*.md. If neither directory exists, skip (lenses are optional).
2. Parse frontmatter of each file (name, description, triggers).
3. If both global and project-local have the same filename, project-local wins. Note: "Project lens {name}.md overrides global lens."
4. Match each lens's triggers against the domains identified from changed files (the same heuristic used to select built-in lenses above).
5. If an active checkpoint exists in .claude/checkpoints/ with active_lenses in frontmatter, include those lenses regardless of trigger matching.
6. Cap: include at most the RISK TIER's specialist cap (SMALL: 2, MEDIUM: 3, LARGE: 4). If more match, take the top ones by trigger specificity (most tags matched). Tiebreaker: alphabetical by filename. List remaining as "also relevant" in the announcement.

Each matched specialist lens is added to the selected lens pool alongside the built-in lenses. When pairing lenses for reviewers, specialist lenses can be paired with built-in lenses or with each other.

Each specialist lens becomes a reviewer instruction: "Additionally review through the {lens.name} lens. Use the following checklist and anti-patterns as your guide:\n{full lens file content}"

3d-iii. Engine check. Run the ENGINE CHECK from the REVIEW ENGINE section (one jacked dcr engine --json Bash call; skip when not running inside Claude Code). Its result decides whether this run's non-carve-out reviewers spawn as Task subagents or as Codex CLI jobs. The check runs once and applies to EVERY wave in this run, re-check waves included.

3e. Announce selected lenses with reasoning: **Lenses selected ([N] of 11):** ✓ Guardrails (always) ✓ Security — API routes modified, auth logic touched ✓ Logic & Edge Cases — new conditional branching in auth flow ✓ 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 ⊘ Simplicity & Reuse — no new logic added, pure config change ⊘ Observability & Debuggability — no error handling or async changes ⊘ Data Integrity & Schema Safety — no database or schema changes **Specialist lenses:** ✓ Accessibility (specialist) — frontend files changed ⊘ API Ergonomics — no API routes in diff

DIAGNOSTIC PRE-GATE (POST-IMPLEMENTATION only — runs BEFORE Wave 1)

3f. Gather deterministic ground truth BEFORE spawning any reviewer — cheap, deterministic signal that catches type/import/test breakage no LLM should burn tokens rediscovering:

• Detect the toolchain from the repo (e.g. ruff/flake8/mypy/pyright for Python; eslint/tsc/biome for JS/TS — honor the config files found in step 3a) and the test runner. Honor project CLAUDE.md rules for HOW to invoke them (e.g. uv run python -m pytest, never bare python -m pytest).
• Run the linter + type-checker on the CHANGED files and run the relevant/affected tests (targeted, seconds). Capture pass/fail and the concrete error output. The FULL suite runs once, on a frozen tree, as the final gate after the last fix wave, not after every micro-fix: one full run per micro-fix is what turned a 10-round review loop into nine hours (2026-09-05).
• Gate: if anything fails, FIX the mechanical failures yourself NOW (you, the parent) and re-run until green — do not spawn reviewers onto a tree that lint or tests already condemn. A failure you cannot fix mechanically (genuine design question) goes to the user before any wave spawns.
• Inject the (now green) results as a ## DETERMINISTIC DIAGNOSTICS — ground truth block into every reviewer's prompt (alongside PROJECT_CONTEXT).
• Skip gracefully if no toolchain/test runner is detected, or the project can't be built/run in this environment: note "Diagnostics: no toolchain detected — skipped" and proceed with the LLM lenses only. Do NOT fabricate diagnostics.

This runs once, before Wave 1 — it does NOT re-run per wave (the FIX PHASE re-runs the relevant tools after applying fixes).

WAVE 1 — Selected Coverage

4. Group the selected lenses per the RISK TIER:
   • SMALL: ONE consolidated reviewer carries every selected lens. No persona, no wild card.
   • MEDIUM: TWO reviewers, lenses split evenly by affinity (e.g. correctness-ish lenses together, structure-ish lenses together). No personas, no wild cards.
   • LARGE: pair the lenses — each reviewer gets exactly 2 (odd count: one reviewer gets a single lens and goes deeper). Number of reviewers = ceil(selected_lenses / 2), range 2-6.
   • Tiered dispatch (Fable-class session: any session model above Opus): reviewers are volume work. Spawn every reviewer with explicit model: "opus" — the reviewer SHAPE comes from the RISK TIER above, and the session's Fable budget stays in the parent loop, which is where the judgment already happens: tier classification, lens selection, finding validation (step 8b), the fix phase, and the verdict. TWO exceptions dispatch on model: "fable" (explicit): the Security lens, which gets its OWN single-lens reviewer (Fable is materially better at spotting real, exploitable issues in code we own - do not pair Security with another lens on a Fable-class session; Security selected means the tier is LARGE), and the conditional Frontend Design reviewer below (visual-design judgment). On an Opus-or-below session, spawn reviewers with the session's model (never below Opus) and the same tier shape.
5. Assign (LARGE tier only) each reviewer a unique persona and unique wild card (shuffle pools as before). SMALL/MEDIUM reviewers get neither.
6. Announce (persona/wild-card columns appear at the LARGE tier only):

   **Wave 1 [TIER] — [N] lenses across [M] reviewer(s)**
   - Reviewer A ([PERSONA]): [Lens X] + [Lens Y] | Wild card: [Q1]
   - Reviewer B ([PERSONA]): [Lens Z] + [Lens W] | Wild card: [Q2]
   ...
   

   (SMALL example: **Wave 1 SMALL — 4 lenses, 1 consolidated reviewer** - Reviewer A: Guardrails + Logic & Edge Cases + Testing + Simplicity & Reuse)
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.
   • Pass the model explicitly on every spawn per the tiered-dispatch rule in step 4: model: "opus" for standard reviewers and the pre-mortem analyst on a Fable-class session; model: "fable" for the Security lens reviewer and the Frontend Design reviewer. Never rely on inheritance - an agent definition's frontmatter model: pin silently beats parent inheritance.
   • Codex engine active (step 3d-iii): non-carve-out reviewers launch as background Codex CLI jobs per CODEX DISPATCH instead of Task calls; the carve-out reviewers (keep_on_claude lenses, Frontend Design) still spawn as Task calls in this same step so the whole wave runs in parallel.

CONDITIONAL: Frontend Design Reviewer (Wave 1 only)

If frontend_review = true (from step 3b), spawn an additional dedicated reviewer in the SAME message (any tier — a SMALL UI change still gets its design pass):

• Use subagent_type: "general-purpose"
• On a Fable-class session, pass model: "fable" explicitly - visual-design judgment (do these elements line up, is the spacing right, does it look designed) is one of the two lanes that stays on the top model
• Prompt MUST start with: "Invoke the frontend-design skill for design context."
• If the diff also touches motion/animation code (CSS transition:/animation:/`@keyfr

…(truncated)