claude-raid 0.1.0

package/template/.claude/skills/raid-implementation-plan/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: raid-implementation-plan
+description: "Phase 2 of Raid protocol. Wizard opens the Dungeon, agents decompose the design into tasks through direct debate, test each other for compliance, and pin agreed tasks. Wizard closes when plan is battle-tested."
+---
+
+# Raid Implementation Plan — Phase 2
+
+Break the design into bite-sized, battle-tested tasks through agent-driven adversarial decomposition.
+
+<HARD-GATE>
+Do NOT start implementation until the plan is approved by the Wizard and committed to git. All assigned agents participate in plan creation AND review. No subagents.
+</HARD-GATE>
+
+## Mode Behavior
+
+- **Full Raid**: All 3 agents decompose independently, then fight over the plan directly. Full plan doc.
+- **Skirmish**: 2 agents. Plan is combined with the design doc into one lightweight document.
+- **Scout**: Skip this skill. Wizard creates inline tasks directly.
+
+## Process Flow
+
+```dot
+digraph plan {
+  "Wizard reads design doc + Phase 1 Dungeon" -> "Wizard opens Dungeon + dispatches";
+  "Wizard opens Dungeon + dispatches" -> "Agents decompose independently";
+  "Agents decompose independently" -> "Agents compare and fight directly";
+  "Agents compare and fight directly" -> "Agents test compliance collaboratively";
+  "Agents test compliance collaboratively" -> "Agents pin agreed tasks to Dungeon";
+  "Agents pin agreed tasks to Dungeon" -> "All requirements covered?" [shape=diamond];
+  "All requirements covered?" -> "Agents identify and fix gaps" [label="no"];
+  "Agents identify and fix gaps" -> "Agents test compliance collaboratively";
+  "All requirements covered?" -> "Wizard closes: synthesizes plan from Dungeon" [label="yes"];
+  "Wizard closes: synthesizes plan from Dungeon" -> "Write plan doc";
+  "Write plan doc" -> "Adversarial plan review (agents attack directly)";
+  "Adversarial plan review (agents attack directly)" -> "Self-review (6-point checklist)";
+  "Self-review (6-point checklist)" -> "Wizard ruling + commit";
+  "Wizard ruling + commit" -> "Archive Dungeon + invoke raid-implementation" [shape=doublecircle];
+}
+```
+
+## Wizard Checklist
+
+1. **Read the approved design doc** — every requirement, every constraint
+2. **Read the Phase 1 archived Dungeon** — carry forward verified knowledge
+3. **Open the Dungeon** — create `.claude/raid-dungeon.md` with Phase 2 header
+4. **Dispatch decomposition** — all agents decompose independently with different angles, then interact directly
+5. **Observe the fight** — agents test each other's plans, argue ordering, coverage, naming. Intervene only on triggers.
+6. **Close the phase** — when Dungeon has complete, verified task list
+7. **Synthesize** — write plan doc from Dungeon evidence
+8. **Adversarial plan review** — agents attack the written plan directly
+9. **Self-review** — 6-point checklist (see below)
+10. **Wizard ruling** — final plan approval
+11. **Commit** — `docs(plan): <feature> implementation plan`
+12. **Archive Dungeon** — rename to `.claude/raid-dungeon-phase-2.md`
+13. **Transition** — invoke `raid-implementation`
+
+## Opening the Dungeon
+
+Create `.claude/raid-dungeon.md`:
+
+```markdown
+# Dungeon — Phase 2: Plan
+## Quest: Decompose <design topic> into implementation tasks
+## Mode: <Full Raid | Skirmish>
+
+### Discoveries
+
+### Active Battles
+
+### Resolved
+
+### Shared Knowledge
+
+### Escalations
+```
+
+## Dispatch for Decomposition
+
+**📡 DISPATCH:**
+
+> **@Warrior**: Decompose into tasks. Focus on structural ordering — what MUST be built first? Hard dependencies? Critical path? Include tests for every task. Challenge @Archer and @Rogue's decompositions directly. Pin agreed tasks to Dungeon.
+>
+> **@Archer**: Decompose into tasks. Focus on completeness and consistency — does every requirement have a task? Are interfaces well-defined across tasks? Are naming patterns and file structure consistent with the codebase? Challenge @Warrior and @Rogue directly. Pin agreed tasks to Dungeon.
+>
+> **@Rogue**: Decompose into tasks. Focus on hidden complexity — which tasks are deceptively hard? Where will the implementer guess wrong? Which tests miss the failure path? Challenge @Warrior and @Archer directly. Pin agreed tasks to Dungeon.
+>
+> **All**: Read the Phase 1 archived Dungeon for design knowledge. Interact directly. Build on each other's decompositions. Pin agreed tasks with `📌 DUNGEON:`. Escalate to me with `🆘 WIZARD:` only when genuinely stuck.
+
+## Collaborative Compliance Testing (Agent-Driven)
+
+After independent decomposition, agents fight directly over the plan:
+
+1. **Compare decompositions** — address each other by name, argue where they agree (high confidence) and disagree (needs resolution)
+2. **Test compliance with design** — every requirement verified against the plan. Line by line. No gaps. Agents cross-check each other.
+3. **Test naming consistency** — agents challenge each other's naming choices against codebase patterns
+4. **Test file system consistency** — file paths follow project structure, module organization clean
+5. **Test coverage** — agents challenge whether tests cover failure paths, not just happy paths
+6. **Test ordering** — agents argue dependency order, build-won't-break guarantees
+7. **Learn from disagreements** — resolutions often reveal a better approach. Pin lessons to Dungeon.
+
+**Agents do this DIRECTLY with each other. The Wizard observes and intervenes only on triggers.**
+
+## Task Granularity
+
+**Each step is one action (2-5 minutes):**
+- "Write the failing test" — step
+- "Run it to verify it fails" — step
+- "Implement minimal code to pass" — step
+- "Run tests to verify pass" — step
+- "Commit" — step
+
+## Task Structure
+
+````markdown
+### Task N: [Component Name]
+
+**Files:**
+- Create: `exact/path/to/file.ext`
+- Modify: `exact/path/to/existing.ext`
+- Test: `tests/exact/path/to/test.ext`
+
+**Acceptance Criteria:**
+- [ ] [Specific, verifiable criterion]
+- [ ] All tests pass
+- [ ] No regressions
+- [ ] Naming follows established patterns
+
+**Steps:**
+- [ ] Step 1: Write the failing test
+- [ ] Step 2: Run test, verify it fails for the right reason
+- [ ] Step 3: Write minimal implementation
+- [ ] Step 4: Run test, verify it passes + full suite passes
+- [ ] Step 5: Commit with descriptive message
+````
+
+## No Placeholders — Ever
+
+These are plan failures. Never write:
+- "TBD", "TODO", "implement later", "fill in details"
+- "Add appropriate error handling" (specify WHAT error handling)
+- "Write tests for the above" (without actual test code)
+- "Similar to Task N" (repeat the code — the implementer may read tasks out of order)
+- "Handle edge cases" (specify WHICH edge cases)
+- Steps that describe what to do without showing how
+- References to undefined types, functions, or methods
+
+**Violating the letter of the "no placeholders" rule is violating its spirit.**
+
+## Self-Review (6-Point Checklist)
+
+After writing the complete plan:
+
+1. **Spec coverage:** Skim each requirement in the design doc. Point to the task that implements it. List any gaps.
+2. **Placeholder scan:** Search for TBD, TODO, vague descriptions, missing code. Fix them.
+3. **Type/name consistency:** Do types, method signatures, property names match across ALL tasks?
+4. **File structure consistency:** Do all file paths follow the project's conventions?
+5. **Test quality:** Does every task have tests? Do tests cover failure paths?
+6. **Ordering:** Can each task be built and committed independently without breaking the build?
+
+Fix issues inline. If a spec requirement has no task, add the task.
+
+## Red Flags
+
+| Thought | Reality |
+|---------|---------|
+| "The plan is obvious from the design" | Plans expose complexity that specs hide. Decompose anyway. |
+| "We can figure out the details during implementation" | Details in implementation = placeholders in the plan. |
+| "I'll wait for the Wizard to synthesize" | You own the phase. Debate with teammates directly. |
+| "These tasks are similar enough to batch" | Each task must be independently buildable and testable. |
+| "Tests can be added later" | TDD means tests are in the plan. No test = no task. |
+| "The naming will be consistent enough" | Check it explicitly. Naming drift is the #1 source of bugs. |
+
+**Terminal state:** ⚡ WIZARD RULING: Plan approved. Commit. Archive Dungeon. Invoke `raid-implementation`.

package/template/.claude/skills/raid-protocol/SKILL.md

@@ -0,0 +1,288 @@
+---
+name: raid-protocol
+description: "MUST use at the start of any Raid session. Establishes the 4-phase adversarial workflow, Dungeon lifecycle, team rules, modes, direct interaction protocols, and reference tables. Agents self-organize within phases. Wizard opens and closes."
+---
+
+# Raid Protocol — Adversarial Multi-Agent Development
+
+The canonical workflow for all Raid operations. Every feature, bugfix, refactor follows this sequence.
+
+<HARD-GATE>
+Do NOT skip phases. Do NOT let a single agent work unchallenged (except in Scout mode). Do NOT proceed without a Wizard ruling. No subagents — agent teams only.
+</HARD-GATE>
+
+## Session Lifecycle
+
+```dot
+digraph session {
+  "Wizard starts" -> "Read raid-rules.md + raid.json";
+  "Read raid-rules.md + raid.json" -> "Create .claude/raid-session";
+  "Create .claude/raid-session" -> "Assess task complexity";
+  "Assess task complexity" -> "Recommend mode";
+  "Recommend mode" -> "Human confirms mode?";
+  "Human confirms mode?" -> "Begin Phase 1" [label="yes"];
+  "Human confirms mode?" -> "Recommend mode" [label="override"];
+  "Begin Phase 1" -> "Phase 1: Design (raid-design)";
+  "Phase 1: Design (raid-design)" -> "Phase 2: Plan (raid-implementation-plan)";
+  "Phase 2: Plan (raid-implementation-plan)" -> "Phase 3: Implementation (raid-implementation)";
+  "Phase 3: Implementation (raid-implementation)" -> "Phase 4: Review (raid-review)";
+  "Phase 4: Review (raid-review)" -> "Finishing (raid-finishing)";
+  "Finishing (raid-finishing)" -> "Clean up Dungeon files";
+  "Clean up Dungeon files" -> "Remove .claude/raid-session";
+  "Remove .claude/raid-session" -> "Session complete" [shape=doublecircle];
+}
+```
+
+**On session start:** Create `.claude/raid-session` to activate workflow hooks.
+**On session end:** Remove `.claude/raid-session`, remove `.claude/raid-dungeon.md` and all `.claude/raid-dungeon-phase-*.md` files.
+
+Hooks that enforce workflow discipline (phase-gate, test-pass, verification) only fire when `.claude/raid-session` exists.
+
+## Team
+
+| Agent | Role | Color |
+|-------|------|-------|
+| **Wizard** (Dungeon Master) | Opens phases, observes, intervenes when necessary, closes with ruling | Purple |
+| **Warrior** | Aggressive explorer, stress-tests to destruction, builds on team findings | Red |
+| **Archer** | Precise pattern-seeker, finds hidden connections and drift, traces ripple effects | Green |
+| **Rogue** | Adversarial assumption-destroyer, constructs attack scenarios, weaponizes findings | Orange |
+
+## Team Rules
+
+Read and follow `.claude/raid-rules.md`. Non-negotiable. 17 rules including Dungeon discipline, direct engagement, wise escalation, and evidence-backed roasts.
+
+## Configuration
+
+Read `.claude/raid.json` for project-specific settings. If absent, use sensible defaults:
+
+| Key | Default | Purpose |
+|-----|---------|---------|
+| `project.testCommand` | (none) | Command to run tests |
+| `project.lintCommand` | (none) | Command to run linting |
+| `project.buildCommand` | (none) | Command to build |
+| `paths.specs` | `docs/raid/specs` | Where design docs go |
+| `paths.plans` | `docs/raid/plans` | Where plans go |
+| `paths.worktrees` | `.worktrees` | Where worktrees go |
+| `conventions.fileNaming` | `none` | Naming convention |
+| `conventions.commits` | `conventional` | Commit format |
+| `raid.defaultMode` | `full` | Default mode |
+
+## Modes
+
+Three modes that scale effort to task complexity.
+
+| Aspect | Full Raid | Skirmish | Scout |
+|--------|-----------|----------|-------|
+| Agents active | 3 | 2 | 1 |
+| Design phase | Full adversarial | Lightweight | Skip (inline) |
+| Plan phase | Full adversarial | Merged with design | Skip (inline) |
+| Implementation | 1 builds, 2 attack | 1 builds, 1 attacks | 1 builds, Wizard reviews |
+| Review phase | 3 independent reviews | 1 review + Wizard | Wizard review only |
+| TDD | **Enforced** | **Enforced** | **Enforced** |
+| Verification | Triple | Double | Single + Wizard |
+| Design doc | Required | Optional (brief) | Not required |
+| Plan doc | Required | Combined with design | Not required |
+| Dungeon | Full (all sections) | Lightweight | Wizard notes only |
+
+**Mode selection:** User specifies, or Wizard recommends based on task complexity.
+**Escalation:** Wizard may escalate (Scout->Skirmish->Full) with human approval.
+**De-escalation:** Only with human approval.
+
+**TDD is non-negotiable in ALL modes.** This is an Iron Law, not a preference.
+
+## The Dungeon — Shared Knowledge Artifact
+
+The Dungeon (`.claude/raid-dungeon.md`) is the team's shared knowledge board. It persists within a phase and gets archived when the phase closes.
+
+### Dungeon Structure
+
+```markdown
+# Dungeon — Phase N: <Phase Name>
+## Quest: <task description>
+## Mode: <Full Raid | Skirmish | Scout>
+
+### Discoveries
+<!-- Verified findings that survived challenge, tagged with agent name -->
+
+### Active Battles
+<!-- Ongoing unresolved challenges between agents -->
+
+### Resolved
+<!-- Challenges that reached conclusion — conceded, proven, or Wizard-ruled -->
+
+### Shared Knowledge
+<!-- Facts established as true by 2+ agents agreeing or surviving challenge -->
+
+### Escalations
+<!-- Points where agents pulled the Wizard in -->
+```
+
+### Dungeon Lifecycle
+
+| Event | Action | Who |
+|-------|--------|-----|
+| Phase opens | Create `.claude/raid-dungeon.md` with header | Wizard |
+| During phase | Read and write via `📌 DUNGEON:` signal | Agents |
+| Phase closes | Rename to `.claude/raid-dungeon-phase-N.md` | Wizard |
+| Next phase opens | Create fresh `.claude/raid-dungeon.md` | Wizard |
+| Session ends | Remove all Dungeon files | Wizard |
+
+### Dungeon Curation Rules
+
+**What goes IN the Dungeon (via `📌 DUNGEON:` only):**
+- Findings that survived a challenge (verified truths)
+- Active unresolved battles (prevents re-litigation)
+- Shared knowledge promoted by 2+ agents agreeing
+- Key decisions and their reasoning
+- Escalation points and Wizard responses
+
+**What stays in conversation only:**
+- Back-and-forth of challenges and roasts
+- Exploratory thinking and hypotheses
+- Concessions and rebuttals
+- Anything that didn't produce a durable insight
+
+**The conversation is the sparring ring. The Dungeon is the scoreboard.**
+
+### Referencing Prior Phases
+
+Agents can read archived Dungeons from prior phases. Design knowledge carries into Plan. Plan knowledge carries into Implementation. This is how context survives phase transitions.
+
+## The Phase Pattern
+
+Every phase follows the open/close bookend model:
+
+```dot
+digraph phase_pattern {
+  "Wizard opens (quest + angles + Dungeon)" -> "Agents self-organize";
+  "Agents self-organize" -> "Agents explore, challenge, roast, build";
+  "Agents explore, challenge, roast, build" -> "Agents pin findings to Dungeon";
+  "Agents pin findings to Dungeon" -> "Intervention needed?" [shape=diamond];
+  "Intervention needed?" -> "Wizard intervenes (minimum force)" [label="yes"];
+  "Wizard intervenes (minimum force)" -> "Agents resume";
+  "Agents resume" -> "Agents explore, challenge, roast, build";
+  "Intervention needed?" -> "Phase objective met?" [label="no"];
+  "Phase objective met?" -> "Agents explore, challenge, roast, build" [label="no, continue"];
+  "Phase objective met?" -> "Wizard closes (ruling + archive Dungeon)" [label="yes"];
+  "Wizard closes (ruling + archive Dungeon)" -> "Next phase" [shape=doublecircle];
+}
+```
+
+### Phase Transition Gates
+
+| From | To | Gate |
+|------|-----|------|
+| Design | Plan | Design doc approved by Wizard ruling, committed |
+| Plan | Implementation | Plan approved by Wizard ruling, committed |
+| Implementation | Review | All tasks complete, all tests passing, committed |
+| Review | Finishing | Wizard ruling: approved for merge |
+
+**Violating the letter of these gates is violating the spirit of the process.**
+
+## Interaction Protocols
+
+### Communication Signals Reference
+
+| Signal | Who | Meaning | Goes to Dungeon? |
+|--------|-----|---------|------------------|
+| `📡 DISPATCH:` | Wizard | Opening a phase, assigning angles | No (phase opening) |
+| `⚡ WIZARD OBSERVES:` | Wizard | Brief course correction, hint, nudge | No |
+| `⚡ WIZARD INTERVENES:` | Wizard | Stops action, something wrong | No |
+| `⚡ WIZARD RULING:` | Wizard | Phase over, binding decision | Ruling archived with Dungeon |
+| `@Name, ...` | Any agent | Direct address to specific agent | No |
+| `🔍 FINDING:` | Warrior | Discovery with evidence | Only after surviving challenge |
+| `🎯 FINDING:` | Archer | Discovery with evidence | Only after surviving challenge |
+| `💀 FINDING:` | Rogue | Discovery with attack scenario | Only after surviving challenge |
+| `⚔️ CHALLENGE:` | Warrior | Direct challenge | No |
+| `🏹 CHALLENGE:` | Archer | Direct challenge | No |
+| `🗡️ CHALLENGE:` | Rogue | Direct challenge | No |
+| `🔥 ROAST:` | Any agent | Pointed critique with evidence | No |
+| `🔗 BUILDING ON @Name:` | Any agent | Extending another's work | Result goes to Dungeon if verified |
+| `📌 DUNGEON:` | Any agent | Pinning verified finding | Yes — this is the write gate |
+| `🆘 WIZARD:` | Any agent | Escalation — needs Wizard input | Yes (as escalation point) |
+| `✅ CONCEDE:` | Any agent | Admitting wrong, moving on | No |
+
+### Direct Interaction Rules
+
+- **Evidence required.** All challenges, roasts, and findings must carry proof — file paths, line numbers, concrete scenarios. "This is wrong" without evidence is laziness.
+- **Build explicitly.** `🔗 BUILDING ON @Name:` forces credit and continuity. Don't restart from scratch when someone found something useful.
+- **Concede instantly.** When proven wrong, concede. Then find a new angle. No ego.
+- **Pin deliberately.** `📌 DUNGEON:` is the quality gate. Only verified, challenged findings get pinned. Other agents can challenge whether a pin belongs.
+- **Escalate wisely.** `🆘 WIZARD:` when genuinely stuck, split on fundamentals, or need project-level context. Not when lazy.
+
+### When to Escalate to Wizard
+
+**Do escalate:**
+- 2+ agents stuck on same disagreement for 3+ exchanges with no new evidence
+- Uncertain about project-level context (user requirements, constraints, priorities)
+- Team needs a direction-setting decision that affects the quest
+- Found something that may require human input
+
+**Don't escalate:**
+- You can resolve it by reading the code
+- Another agent already answered your question
+- It's a matter of opinion that doesn't affect the outcome
+- You're stuck but haven't tried talking to the other agents first
+
+## When the Wizard Intervenes
+
+The Wizard observes 90%, acts 10%. Intervention triggers:
+
+| Signal | Action |
+|--------|--------|
+| Same arguments 3+ rounds, no new evidence | `⚡ WIZARD INTERVENES:` Break the loop. Rule or redirect. |
+| Agents drifting from objective | `⚡ WIZARD OBSERVES:` Redirect with clarity. |
+| Agents stuck, no progress (deadlock) | `⚡ WIZARD INTERVENES:` Rule with rationale. Binding. |
+| Shallow work, rubber-stamping (laziness) | `⚡ WIZARD INTERVENES:` Call out and demand genuine challenge. |
+| Defending past evidence (ego) | `⚡ WIZARD OBSERVES:` Evidence or concede. |
+| Wrong finding in Dungeon (misinformation) | `⚡ WIZARD INTERVENES:` Remove and correct. |
+| Agent escalation (`🆘 WIZARD:`) | Answer or redirect as appropriate. |
+| All agents converged | `⚡ WIZARD RULING:` Synthesize and close. |
+
+## Red Flags — Thoughts That Signal Violations
+
+| Thought | Reality |
+|---------|---------|
+| "This phase is obvious, let's skip it" | Obvious phases are where assumptions hide. |
+| "The agents agree, no need for cross-testing" | Agreement without challenge is groupthink. |
+| "Let's just fix this quickly, no need for design" | Quick fixes without design become tech debt. |
+| "TDD would slow us down on this one" | TDD is an Iron Law. No exceptions. |
+| "One agent can handle this alone" | Scout mode exists. Use it. Don't bypass modes. |
+| "We already know what to build" | Knowing and verifying are different things. |
+| "The Wizard should mediate this" | Agents resolve directly. Wizard observes. |
+| "Let me just post everything to the Dungeon" | Dungeon is a scoreboard, not a log. Pin only verified findings. |
+| "I'll wait for the Wizard to tell me what to do next" | You own the phase. Self-organize. |
+
+## Skills Reference
+
+| Skill | Phase | Purpose |
+|-------|-------|---------|
+| `raid-protocol` | Start | Session lifecycle, Dungeon lifecycle, modes, rules, reference |
+| `raid-design` | 1 | Adversarial design with agent-driven exploration |
+| `raid-implementation-plan` | 2 | Collaborative plan with direct cross-testing |
+| `raid-implementation` | 3 | Agent-driven implementation with rotation |
+| `raid-review` | 4 | Adversarial full review with Dungeon-tracked issues |
+| `raid-finishing` | End | Completeness debate + merge options |
+| `raid-tdd` | 3 | TDD with collaborative test quality review |
+| `raid-debugging` | Any | Competing hypothesis with direct debate |
+| `raid-verification` | Any | Evidence before completion claims |
+| `raid-git-worktrees` | 3 | Isolated workspace setup |
+
+## Hooks Reference
+
+| Hook | Event | Active | Purpose |
+|------|-------|--------|---------|
+| `validate-file-naming.sh` | PostToolUse (Write/Edit) | Always | Enforce naming conventions |
+| `validate-commit-message.sh` | PreToolUse (Bash) | Always | Conventional commits |
+| `validate-tests-pass.sh` | PreToolUse (Bash) | Raid session only | Tests before commits |
+| `validate-phase-gate.sh` | PreToolUse (Write) | Raid session only | Design doc before code |
+| `validate-no-placeholders.sh` | PostToolUse (Write/Edit) | Always | No TBD/TODO in specs/plans |
+| `validate-verification.sh` | PreToolUse (Bash) | Raid session only | Test evidence before completion |
+
+## Commit Convention
+
+All commits follow: `type(scope): description`
+
+Types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`
+
+Phase transitions: `docs(design): <topic>`, `docs(plan): <topic>`, `feat(scope): <what>`, `fix(scope): <what>`

package/template/.claude/skills/raid-review/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: raid-review
+description: "Phase 4 of Raid protocol. Wizard opens the Dungeon, agents review independently then fight directly over findings and missing findings. Issues pinned by severity. Wizard closes when all Critical/Important fixed."
+---
+
+# Raid Review — Phase 4
+
+Three reviewers, three angles, zero mercy. They fight each other, not just the code.
+
+<HARD-GATE>
+Do NOT declare work complete without Phase 4 (except Scout mode). All assigned agents review the ENTIRE implementation independently, then attack each other's findings. Use `raid-verification` before any completion claims. No subagents.
+</HARD-GATE>
+
+## Mode Behavior
+
+- **Full Raid**: 3 independent reviews, then agents fight directly over findings. All severity levels enforced.
+- **Skirmish**: 1 agent reviews + Wizard. Cross-testing between reviewer and Wizard.
+- **Scout**: Wizard reviews alone. Checks against requirements and runs tests.
+
+## Process Flow
+
+```dot
+digraph review {
+  "Wizard reads design doc, plan, Phase 3 Dungeon" -> "Wizard opens Dungeon + dispatches";
+  "Wizard opens Dungeon + dispatches" -> "Agents review independently";
+  "Agents review independently" -> "Agents fight over findings directly";
+  "Agents fight over findings directly" -> "Agents challenge missing findings";
+  "Agents challenge missing findings" -> "Agents pin severity-classified issues to Dungeon";
+  "Agents pin severity-classified issues to Dungeon" -> "Wizard closes: categorizes surviving issues";
+  "Wizard closes: categorizes surviving issues" -> "Critical or Important?" [shape=diamond];
+  "Critical or Important?" -> "Assign fixes" [label="yes"];
+  "Assign fixes" -> "Fix + verify + challengers re-attack";
+  "Fix + verify + challengers re-attack" -> "Wizard closes: categorizes surviving issues";
+  "Critical or Important?" -> "Wizard final ruling" [label="no"];
+  "Wizard final ruling" -> "Archive Dungeon + invoke raid-finishing" [shape=doublecircle];
+}
+```
+
+## Wizard Checklist
+
+1. **Prepare** — gather git range, design doc, plan doc, read Phase 3 Dungeon
+2. **Open the Dungeon** — create `.claude/raid-dungeon.md` with Phase 4 header
+3. **Dispatch** — all agents review independently, then interact directly
+4. **Observe the fight** — agents challenge findings and missing findings directly
+5. **Close** — categorize surviving issues by severity from Dungeon
+6. **Rule on fixes** — Critical and Important must be fixed
+7. **Verify fixes** — targeted re-attack after fixes (use `raid-verification`)
+8. **Final ruling** — approved or rejected
+9. **Archive Dungeon** — rename to `.claude/raid-dungeon-phase-4.md`
+10. **Transition** — invoke `raid-finishing`
+
+## Opening the Dungeon
+
+Create `.claude/raid-dungeon.md`:
+
+```markdown
+# Dungeon — Phase 4: Review
+## Quest: Full adversarial review of <feature> implementation
+## Mode: <Full Raid | Skirmish>
+
+### Discoveries
+
+### Active Battles
+
+### Resolved
+
+### Shared Knowledge
+
+### Escalations
+```
+
+## Dispatch
+
+**📡 DISPATCH:**
+
+> **@Warrior**: Review full implementation. Run every test. Check error handling at every boundary. Verify all requirements from design doc. Find the bugs that crash in production. Then fight @Archer and @Rogue over their findings.
+>
+> **@Archer**: Review full implementation. Does it match the design doc exactly? Patterns consistent? Interfaces correct? Types sound? Naming conventions followed? File structure clean? Find the bugs that silently produce wrong results. Then fight @Warrior and @Rogue.
+>
+> **@Rogue**: Review full implementation. Think like an attacker. What inputs break it? What timing causes races? What happens when dependencies fail? Find the bugs nobody else will find. Then fight @Warrior and @Archer.
+>
+> **All**: Review independently first, then fight directly. Challenge each other's findings AND each other's blind spots. Pin severity-classified issues to Dungeon with `📌 DUNGEON:`. Reference the Phase 3 Dungeon for context.
+
+## Review Checklist — Each Agent
+
+**Requirements:** Every design doc requirement implemented? No extras (YAGNI)? Nothing misinterpreted?
+
+**Code Quality:** Clean separation? Error handling at every boundary? DRY? Clear names?
+
+**Testing:** Every function tested? Edge cases? Failure paths? All passing?
+
+**Architecture:** Design decisions implemented correctly? Interfaces match spec? No drift?
+
+**Naming & Structure:** Consistent naming? File system follows conventions? Modules clean?
+
+**Production:** Performance OK? External calls have timeouts? No secrets in code?
+
+## The Fight — Agents Challenge Each Other
+
+After independent reviews, agents fight DIRECTLY over findings AND missing findings:
+
+- `⚔️ CHALLENGE: @Archer, you gave the auth module a pass but didn't check the session rotation path — review it now.`
+- `🔗 BUILDING ON @Warrior: Your finding about the missing error handler — the impact is worse than you stated because...`
+- `🔥 ROAST: @Rogue, your "Critical" severity on the naming inconsistency is overblown — here's why it's actually Minor...`
+- `📌 DUNGEON: [Critical] handler.js:23 — missing input validation allows injection. Verified by @Warrior and @Rogue.`
+
+**Agents classify severity when pinning to Dungeon:**
+
+| Severity | Definition | Action |
+|----------|------------|--------|
+| **Critical** | Bugs, security holes, data loss, crashes | Must fix. No exceptions. |
+| **Important** | Missing features, poor error handling, test gaps, naming inconsistencies | Must fix. |
+| **Minor** | Style, docs, optimization | Note for future. |
+
+## Closing the Phase
+
+The Wizard closes when agents have exhausted their findings and the Dungeon has all issues classified:
+
+**⚡ WIZARD RULING: APPROVED FOR MERGE** — all Critical/Important fixed, tests pass, requirements met.
+
+**⚡ WIZARD RULING: REJECTED** — specify what must change and which phase to return to.
+
+## Red Flags
+
+| Thought | Reality |
+|---------|---------|
+| "The implementation looks fine, no issues" | Every review finds at least one issue. Look harder. |
+| "I'll report my findings to the Wizard" | Report to the other agents directly. Fight over them. |
+| "This is a Minor issue" (when it causes wrong behavior) | Wrong results = Important or Critical. |
+| "The tests pass, so it works" | Tests prove what they test. What DON'T they test? |
+| "Let's skip re-review of the fixes" | Fixes introduce new bugs. Always re-attack. |
+
+**Terminal state:** Archive Dungeon. Invoke `raid-finishing`.