claude-raid 0.1.7 → 0.2.1

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

@@ -0,0 +1,211 @@
+---
+name: raid-canonical-protocol
+description: "Canonical Quest protocol. Establishes the 6-phase workflow (PRD, Design, Plan, Implementation, Review, Wrap Up), round-based interaction, Dungeon lifecycle, quest types, communication signals, and phase transition gates."
+---
+
+# Canonical Quest Protocol
+
+The canonical workflow for full-cycle development. Every feature, refactor, or system built through the Raid follows this sequence.
+
+<HARD-GATE>
+Do NOT skip phases. Do NOT let a single agent work unchallenged (except Scout mode). Do NOT proceed without a Wizard ruling. Agents communicate via SendMessage — do not spawn subagents.
+</HARD-GATE>
+
+## Session Lifecycle
+
+```dot
+digraph session {
+  "Wizard starts" -> "Load raid-init";
+  "Load raid-init" -> "Greet human + quest selection";
+  "Greet human + quest selection" -> "Canonical Quest selected";
+  "Canonical Quest selected" -> "PRD needed?";
+  "PRD needed?" -> "Phase 1: PRD (raid-canonical-prd)" [label="yes"];
+  "PRD needed?" -> "Phase 2: Design (raid-canonical-design)" [label="no"];
+  "Phase 1: PRD (raid-canonical-prd)" -> "Phase 2: Design (raid-canonical-design)";
+  "Phase 2: Design (raid-canonical-design)" -> "Phase 3: Plan (raid-canonical-implementation-plan)";
+  "Phase 3: Plan (raid-canonical-implementation-plan)" -> "Phase 4: Implementation (raid-canonical-implementation)";
+  "Phase 4: Implementation (raid-canonical-implementation)" -> "Review wanted?";
+  "Review wanted?" -> "Phase 5: Review (raid-canonical-review)" [label="yes"];
+  "Review wanted?" -> "Phase 6: Wrap Up (raid-wrap-up)" [label="no"];
+  "Phase 5: Review (raid-canonical-review)" -> "Phase 6: Wrap Up (raid-wrap-up)";
+  "Phase 6: Wrap Up (raid-wrap-up)" -> "Archive to vault + session end";
+}
+```
+
+## Team
+
+| Agent | Role | Color |
+|-------|------|-------|
+| **Wizard** (Dungeon Master) | Opens phases, observes, digests, rules. NEVER implements. | Purple |
+| **Warrior** | Stress-tests to destruction, edge cases, load testing | Red |
+| **Archer** | Pattern-seeker, traces ripple effects, naming drift | Green |
+| **Rogue** | Adversarial assumption-destroyer, attack scenarios | Orange |
+
+## Modes
+
+| Aspect | Full Raid | Skirmish | Scout |
+|--------|-----------|----------|-------|
+| Agents | 3 | 2 | 1 |
+| PRD phase | Full | Lightweight | Skip |
+| Design | Full adversarial | Lightweight | Inline |
+| Plan | Full adversarial | Combined with design | Inline |
+| Implementation | 1 builds, 2 cross-test | 1 builds, 1 cross-tests | 1 builds, Wizard reviews |
+| Review | 3 independent + fighting | 1 review + Wizard | Wizard only |
+| TDD | **Enforced** | **Enforced** | **Enforced** |
+
+## Round-Based Interaction
+
+Think turn-based RPG, not real-time:
+
+```
+ROUND START → Wizard dispatches tasks/angles
+    ↓
+PARALLEL WORK → Each agent works independently
+    ↓
+FLAG COMPLETION → Agent signals ROUND_COMPLETE: to Wizard
+    ↓
+CROSS-TESTING → Wizard assigns completed work for review
+    ↓
+REACTIONS → Agents test, challenge, build
+    ↓
+RESOLUTION → Findings pinned to dungeon or conceded
+    ↓
+ROUND END → Wizard assesses: next round or phase close
+```
+
+**Rules:**
+- No mid-thinking interruptions between agents (only Wizard can interrupt)
+- Each message must carry evidence + conclusion (no shallow exchanges)
+- Converge in 2-3 exchanges per finding; escalate to Wizard after 3
+- Party is silent during phase transitions
+
+## Question Chain
+
+Agents → Wizard → Human. Agents NEVER ask the human directly.
+
+1. Agent discovers gap → sends `WIZARD:` with question
+2. Wizard reasons: can I answer from PRD, codebase, context?
+3. If confident → answers agent directly
+4. If unsure → digests question, asks human one clear question
+5. Wizard passes answer back with interpretation
+
+## Phase Transition Gates
+
+| From | To | Gate | Commit Format |
+|------|----|------|---------------|
+| PRD | Design | PRD approved by Wizard | `docs(quest-{slug}): phase 1 PRD` |
+| Design | Plan | Design doc approved, committed | `docs(quest-{slug}): phase 2 design` |
+| Plan | Implementation | Plan approved, committed | `docs(quest-{slug}): phase 3 plan` |
+| Implementation | Review | All tasks done, tests pass | `feat(quest-{slug}): phase 4 implementation` |
+| Review | Wrap Up | Wizard ruling: approved | `fix(quest-{slug}): phase 5 review` |
+
+**Wizard commits at EVERY phase transition.** No exceptions.
+
+## Phase Spoils
+
+Every phase MUST produce at least one detailed markdown artifact:
+
+| Phase | Output File |
+|-------|-------------|
+| PRD | `{questDir}/phase-1-prd.md` |
+| Design | `{questDir}/phase-2-design.md` |
+| Plan | `{questDir}/phase-3-plan.md` + task files |
+| Implementation | `{questDir}/phase-4-implementation.md` |
+| Review | `{questDir}/phase-5-review.md` |
+| Wrap Up | `{questDir}/phase-6-wrap-up.md` |
+
+## Communication Signals
+
+| Signal | Who | Meaning | Goes to Dungeon? |
+|--------|-----|---------|-----------------|
+| `DISPATCH:` | Wizard | Opening a phase, assigning angles | No |
+| `ROUND_COMPLETE:` | Any agent | Finished assigned task | No |
+| `FINDING:` | Any agent | Discovery with own evidence | No |
+| `CHALLENGE:` | Any agent | Independently verified, found problem | No |
+| `BUILDING:` | Any agent | Independently verified, goes deeper | No |
+| `DUNGEON:` | Any agent | Pinning finding verified by 2+ agents | **Yes** |
+| `BLACKCARD:` | Any agent | High-concern finding blocking progress | **Yes** |
+| `WIZARD:` | Any agent | Escalation — needs Wizard input | Yes (escalation) |
+| `CONCEDE:` | Any agent | Proven wrong, moving on | No |
+| `RULING:` | Wizard | Binding decision, phase close | Archived |
+| `REDIRECT:` | Wizard | Course correction, one sentence | No |
+
+## Black Card System
+
+A `BLACKCARD:` is a finding that fundamentally breaks the architecture — unfixable within current design.
+
+**Flow:** Agent plays → 2+ agents verify → Wizard escalates to human → Options: (a) rollback to earlier phase, (b) accept limitation.
+
+Black cards are RARE. Most issues are Critical or Important, not black cards.
+
+## The Dungeon
+
+Quest directory at `.claude/dungeon/{quest-slug}/`. Each phase produces a file.
+
+| Event | Action | Who |
+|-------|--------|-----|
+| Quest starts | Create quest directory | Hook |
+| Phase opens | Create `{questDir}/phase-N-{name}.md` with boilerplate | Wizard |
+| During phase | Pin findings via `DUNGEON:` | Agents |
+| Phase closes | Wrap up doc, commit | Wizard |
+| Quest ends | Move to `.claude/vault/{quest-slug}/` | Wizard |
+
+**The Dungeon is a scoreboard, not a chat log.** Only verified findings, resolved battles, shared knowledge.
+
+## Wizard Behavior
+
+- **90% thinking / 10% talking** — thinks 5x before speaking
+- **NEVER implements** — dispatches, observes, digests, rules
+- **Opens and closes every phase** — creates phase file, dispatches, then goes silent
+- **Phase reports** — at every close, summarizes for human: what was done, what's next
+- **Question gatekeeper** — digests before passing in either direction
+- **Commits at every transition** — with quest name + phase + summary
+
+## Configuration
+
+Read `.claude/raid.json` for project settings:
+
+| Key | Default | Purpose |
+|-----|---------|---------|
+| `project.testCommand` | (none) | Command to run tests |
+| `project.packageManager` | (auto) | Package manager |
+| `raid.defaultMode` | `full` | Default mode |
+| `raid.agentEffort` | `medium` | Agent effort level (Wizard always max) |
+| `raid.vault.path` | `.claude/vault` | Vault location |
+| `browser.enabled` | `false` | Browser testing active |
+
+## Browser Testing
+
+When `browser.enabled` is `true`:
+- **Phase 4 (Implementation):** Browser-facing code uses TDD with Playwright via `raid-tdd`. Challengers verify on isolated ports.
+- **Phase 5 (Review):** Live adversarial Chrome inspection via `raid-browser-chrome`. Each agent on separate port.
+- Invoke `raid-browser` for startup discovery and pre-flight.
+
+## Skills Reference
+
+| Skill | Phase | Purpose |
+|-------|-------|---------|
+| `raid-init` | Pre-phase | Quest selection, greeting, session setup |
+| `raid-canonical-protocol` | Start | This doc — session lifecycle, rules, reference |
+| `raid-canonical-prd` | 1 | PRD creation (optional) |
+| `raid-canonical-design` | 2 | Adversarial design exploration |
+| `raid-canonical-implementation-plan` | 3 | Task decomposition |
+| `raid-canonical-implementation` | 4 | TDD implementation with cross-testing |
+| `raid-canonical-review` | 5 | Pinning + fixing + black cards (optional) |
+| `raid-wrap-up` | 6 | Storyboard, PR, vault archival |
+| `raid-tdd` | Any | RED-GREEN-REFACTOR enforcement |
+| `raid-verification` | Any | Evidence-before-claims gate |
+| `raid-debugging` | Any | Root-cause investigation |
+| `raid-browser` | 4, 5 | Browser orchestration |
+| `raid-browser-chrome` | 5 | Live Chrome inspection |
+
+## Red Flags
+
+| Thought | Reality |
+|---------|---------|
+| "This phase is obvious, skip it" | Obvious phases hide assumptions. |
+| "The agents agree, no need for cross-testing" | Agreement without challenge is groupthink. |
+| "TDD would slow us down" | TDD is an Iron Law. No exceptions. |
+| "Let me ask the human directly" | Route through the Wizard. Always. |
+| "Let me just post everything to the Dungeon" | Pin only what survived challenge. |
+| "I'll wait for the Wizard to tell me what to do" | Self-organize within the round. |

package/template/.claude/skills/{raid-review → raid-canonical-review}/SKILL.md

@@ -1,14 +1,14 @@
 ---
-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."
+name: raid-canonical-review
+description: "Phase 5 of Canonical Quest (optional). Two subphases: Pinning (find issues) and Fixing (resolve them). Black Card system for breaking changes. Wizard asks human before entering."
 ---
 
-# Raid Review — Phase 4
+# Raid Review — Phase 5 (Optional)
 
-Three reviewers, three angles, zero mercy. They fight each other, not just the code.
+Three reviewers, three angles, zero mercy. Pinning then fixing. Black cards for the unfixable.
 
 <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.
+This phase is OPTIONAL — the Wizard asks the human before entering. 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
@@ -21,7 +21,7 @@ Do NOT declare work complete without Phase 4 (except Scout mode). All assigned a
 
 ```dot
 digraph review {
-  "Wizard reads design doc, plan, Phase 3 Dungeon" -> "Wizard opens Dungeon + dispatches";
+  "Wizard reads design doc, plan, Phase 4 implementation log" -> "Wizard opens review board";
   "Wizard opens Dungeon + dispatches" -> "Agents review independently";
   "Agents review independently" -> "Agents fight over findings directly";
   "Agents fight over findings directly" -> "Agents challenge missing findings";
@@ -32,14 +32,14 @@ digraph review {
   "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 final ruling" -> "Commit + invoke raid-wrap-up" [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
+1. **Prepare** — gather git range, design doc, plan doc, read `{questDir}/phase-4-implementation.md`
+2. **Open the review board** — create `{questDir}/phase-5-review.md`
 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
@@ -48,15 +48,15 @@ digraph review {
 8. **Rule on fixes** — Critical and Important must be fixed (code AND browser)
 9. **Verify fixes** — targeted re-attack after fixes (use `raid-verification`)
 10. **Final ruling** — approved or rejected
-11. **Archive Dungeon** — rename to `.claude/raid-dungeon-phase-4.md`
-12. **Transition** — invoke `raid-finishing`
+11. **Commit** — `fix(quest-{slug}): phase 5 review — {N} findings resolved`
+12. **Transition** — invoke `raid-wrap-up`
 
 ## Opening the Dungeon
 
-Create `.claude/raid-dungeon.md`:
+Create `{questDir}/phase-5-review.md`:
 
 ```markdown
-# Dungeon — Phase 4: Review
+# Phase 5: Review
 ## Quest: Full adversarial review of <feature> implementation
 ## Mode: <Full Raid | Skirmish>
 
@@ -97,6 +97,30 @@ Create `.claude/raid-dungeon.md`:
 
 **Production:** Performance OK? External calls have timeouts? No secrets in code?
 
+## Verification Protocol for Findings
+
+Before acting on ANY finding (yours or a teammate's):
+1. **READ:** Complete the finding without reacting
+2. **VERIFY:** Check against codebase reality — read the actual code at the referenced location
+3. **EVALUATE:** Is this technically sound for THIS codebase? Does fixing it break something else?
+4. **RESPOND:** Technical evidence or reasoned pushback
+
+## No Performative Agreement
+
+NEVER respond with "You're absolutely right!" or "Great point!" or "Good catch!"
+Instead: state the technical finding, show evidence, or push back.
+Actions speak. Fix and show — don't compliment.
+
+If a finding IS correct: `"Fixed. [Brief description of what changed]."` or just fix it silently.
+
+## YAGNI Check on Findings
+
+Before implementing a "professional improvement" suggestion:
+- Grep codebase for actual usage of the component
+- If unused: suggest removing (YAGNI) — `"This endpoint isn't called. Remove it?"`
+- If used: implement properly
+- Don't gold-plate during review
+
 ## The Fight — Agents Challenge Each Other
 
 After independent reviews, agents fight DIRECTLY over findings AND missing findings:
@@ -141,9 +165,45 @@ After code review findings are pinned, the Wizard announces browser inspection.
 
 **Browser bugs block merge the same way code bugs do.**
 
+## Black Card System
+
+If any agent finds something that fundamentally breaks the architecture — a change so deep it invalidates the implementation — they play a `BLACKCARD:`:
+
+```
+BLACKCARD: [description of breaking concern]
+Evidence: [file paths, scenarios, why this is unfixable within current design]
+Impact: [what breaks, how deep the damage goes]
+```
+
+**Black Card flow:**
+1. Agent plays `BLACKCARD:` → other agents independently verify
+2. If 2+ agents agree it's a black card → Wizard escalates to human
+3. Wizard presents to human with full context (digested, not raw):
+   - What the black card is
+   - Why it's unfixable in current design
+   - Options:
+     a) **Rollback** — Go back to PRD or Design phase (creates `phase-2-design-v2.md`)
+     b) **Accept** — Live with the limitation, document it, continue
+4. Human decides → Wizard acts accordingly
+
+**Black cards are RARE.** Most issues are Critical or Important, not black cards. A black card means "the foundation is wrong" — not "there's a bug."
+
+## Fix Implementation Order
+
+When the Wizard assigns fixes during the Fixing subphase, prioritize in this order within each severity level:
+1. **Blocking issues** — crashes, security holes, data loss
+2. **Simple fixes** — typos, imports, naming inconsistencies
+3. **Complex fixes** — refactoring, logic changes, architectural adjustments
+
+Test each fix individually. Verify no regressions before moving to the next fix.
+
+## Unclear Finding Protocol
+
+If ANY finding is unclear — unclear what the problem is, unclear how to reproduce, unclear what the fix should be — **STOP**. Clarify ALL unclear items before implementing ANY fixes. Partial understanding leads to wrong implementation.
+
 ## Closing the Phase
 
-The Wizard closes when agents have exhausted their findings and the Dungeon has all issues classified:
+The Wizard closes when agents have exhausted their findings and the review board has all issues classified:
 
 **RULING: APPROVED FOR MERGE** — all Critical/Important fixed, tests pass, requirements met.
 
@@ -165,8 +225,9 @@ The Wizard closes when agents have exhausted their findings and the Dungeon has
 
 When the RULING is APPROVED FOR MERGE:
 
-1. Archive the Dungeon: rename `.claude/raid-dungeon.md` to `.claude/raid-dungeon-phase-4.md`
-2. Update `.claude/raid-session` phase to `"finishing"`
-3. **Load the `raid-finishing` skill now and begin Finishing.**
+1. Update `.claude/raid-session` phase to `"wrap-up"`
+2. **Commit**: `fix(quest-{slug}): phase 5 review — {N} findings resolved`
+3. **Send phase report to human**: findings count, fixes applied, any black cards
+4. **Load the `raid-wrap-up` skill now and begin Phase 6.**
 
 Do not wait. Do not ask. The next action after approving for merge is loading the next skill.

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

@@ -60,8 +60,19 @@ digraph debugging {
 1. **Read error messages carefully** — stack traces, line numbers, error codes. Don't skip past them. The answer is often in the first error.
 2. **Reproduce consistently** — exact steps, every time. If not reproducible, gather more data — don't guess. An unreproducible bug is not understood.
 3. **Check recent changes** — `git diff`, recent commits, new dependencies, config changes. What changed since it last worked?
-4. **Gather evidence at boundaries** — in multi-component systems, log what enters and exits each component boundary. Run once to see WHERE it breaks. THEN investigate that component.
-5. **Trace data flow** — where does the bad value originate? Keep tracing upstream until you find the source. Fix at source, not at symptom.
+4. **Gather evidence at boundaries** — in multi-component systems, add diagnostic instrumentation:
+   ```
+   For EACH component boundary:
+     - Log what data enters the component
+     - Log what data exits the component
+     - Verify environment/config propagation
+     - Check state at each layer
+   Run ONCE to gather evidence showing WHERE it breaks.
+   THEN investigate that specific component.
+   ```
+   Example: API → Service → Database → Response. Log at each boundary. The layer where input looks right but output looks wrong is your target.
+
+5. **Trace data flow backward** — where does the bad value appear? What function produced it? What called that function with what input? Keep tracing backward until you find the SOURCE. Fix at SOURCE, not at symptom.
 
 ### Phase 2: Pattern Analysis
 
@@ -72,9 +83,10 @@ digraph debugging {
 
 ### Phase 3: Hypothesis and Testing
 
-1. **Form a single, specific hypothesis:** "X is the root cause because Y"
-2. **Make the SMALLEST possible change** to test it. One variable at a time.
-3. **Did it work?** -> Phase 4. **Didn't work?** -> NEW hypothesis. Don't pile fixes on top of failed fixes.
+**Per-agent hypothesis discipline:**
+1. **Form ONE specific hypothesis:** "I think X is the root cause because Y." Write it down. Be specific, not vague.
+2. **Make the SMALLEST possible change** to test it. One variable at a time. Don't fix multiple things at once.
+3. **Did it work?** → Phase 4. **Didn't work?** → Form a NEW hypothesis based on what you learned. Don't pile fixes on top of failed fixes. Don't just "try another thing" — the failed test gave you information. Use it.
 
 ### Phase 4: Fix Implementation
 
@@ -127,6 +139,13 @@ If 3 or more fix attempts fail, **STOP fixing and question architecture:**
 
 This is not failure — it's the system working. Detecting architectural problems before sinking more time into symptom fixes.
 
+**Pattern indicating architectural problem:**
+- Each fix reveals new shared state or coupling in a different place
+- Fixes require "massive refactoring" to implement
+- Each fix creates new symptoms elsewhere
+
+If within a Canonical Quest: consider playing a `BLACKCARD:` — this may be a design-level problem, not an implementation bug.
+
 ## Defense in Depth
 
 After finding and fixing the root cause, add validation at multiple layers:
@@ -148,6 +167,12 @@ After finding and fixing the root cause, add validation at multiple layers:
 | "The issue is simple, don't need process" | Simple issues have root causes too. Process is fast. |
 | "Emergency, no time" | Systematic debugging is FASTER than thrashing. Always. |
 | "Just try this first" | The first fix sets the pattern. Do it right. |
+| "Pattern says X but I'll adapt" | Partial understanding guarantees bugs. Read it completely. |
+| "I don't fully understand but this might work" | STOP. Return to Phase 1. |
+| "Multiple changes at once saves time" | Can't isolate what worked. Causes new bugs. |
+| "I'll write the test after confirming fix" | Untested fixes don't stick. Test first proves it. |
+| "Skip investigation, the error message says it all" | Error messages describe symptoms, not root causes. |
+| "Add multiple changes, run tests" | One variable at a time. Scientific method. |
 
 ## Escalation
 

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

@@ -0,0 +1,130 @@
+---
+name: raid-init
+description: "Quest selection, greeting, session setup, and dungeon resume. Loaded by wizard at session start. Teaches the wizard how to greet the human, present quest choices, and begin the quest."
+---
+
+# Raid Init — Quest Selection & Session Setup
+
+The first skill loaded when the Wizard starts. Guides the greeting, quest selection, and session bootstrap.
+
+<HARD-GATE>
+Do NOT skip the greeting. Do NOT skip quest selection. Do NOT begin any phase without the human choosing a quest type and confirming the mode.
+</HARD-GATE>
+
+## Process Flow
+
+```dot
+digraph init {
+  "Read rules + raid.json" -> "Check for in-progress quests";
+  "Check for in-progress quests" -> "Offer to resume?" [shape=diamond];
+  "Offer to resume?" -> "Resume existing quest" [label="yes, human confirms"];
+  "Offer to resume?" -> "Greet the human" [label="no"];
+  "Greet the human" -> "Present quest menu";
+  "Present quest menu" -> "Canonical Quest?" [shape=diamond];
+  "Canonical Quest?" -> "Ask: PRD needed?" [label="A"];
+  "Canonical Quest?" -> "Coming soon message" [label="B/D/E/F"];
+  "Coming soon message" -> "Present quest menu";
+  "Ask: PRD needed?" -> "Human describes task";
+  "Human describes task" -> "Assess complexity + recommend mode";
+  "Assess complexity + recommend mode" -> "Human approves mode?";
+  "Human approves mode?" -> "Spawn team + create quest dir" [label="yes"];
+  "Human approves mode?" -> "Assess complexity + recommend mode" [label="override"];
+  "Spawn team + create quest dir" -> "Begin first phase" [shape=doublecircle];
+}
+```
+
+## Step 1: Check for In-Progress Quests
+
+Look in `.claude/dungeon/` for existing quest directories. If any exist:
+
+> "I sense an unfinished quest in the dungeon: **{quest-slug}**. Shall we resume where we left off, or begin a new adventure?"
+
+If the human wants to resume, read the raid-session file and continue from the current phase.
+
+## Step 2: Greet the Human
+
+```
+Farewell brave Engineer, Welcome to the dungeon —
+the raid is waiting for you.
+Let's make the bards sing about the quest we are embracing today:
+```
+
+## Step 3: Present Quest Menu
+
+```
+Choose your quest:
+
+A) Canonical Quest — Full 6-phase development cycle
+   (PRD, Design, Plan, Build, Review, Wrap Up)
+
+B) Round Table — (Coming soon)
+D) Map Exploration — (Coming soon)
+E) Bug Hunting — (Coming soon)
+F) Bard Bonfire — (Coming soon)
+```
+
+If the human selects B, D, E, or F:
+> "That quest type is still being forged by the arcane smiths. Choose another path for now."
+
+Loop back to the menu.
+
+## Step 4: Canonical Quest Setup
+
+### 4a. PRD Question
+
+> "Do you carry a Product Requirements scroll, or shall we forge one together?"
+
+- If PRD needed → first phase will be PRD (raid-canonical-prd)
+- If PRD not needed → first phase will be Design (raid-canonical-design)
+
+### 4b. Task Description
+
+Ask the human to describe the task/feature they want to build. Listen carefully. Read 3 times internally.
+
+### 4c. Mode Recommendation
+
+Assess complexity and recommend a mode:
+
+| Mode | When | Agents |
+|------|------|--------|
+| **Full Raid** | Large features, architectural changes, complex refactors | 3 (Warrior, Archer, Rogue) |
+| **Skirmish** | Medium features, focused changes | 2 (pick most relevant) |
+| **Scout** | Small fixes, minor additions | 1 (pick most relevant) |
+
+Present recommendation. Wait for human to approve or override.
+
+### 4d. Spawn Team & Setup
+
+1. Update raid-session with:
+   - `questType`: `"canonical"`
+   - `questId`: slugified from task description (e.g., `"auth-redesign"`)
+   - `questDir`: `.claude/dungeon/{questId}`
+   - `phase`: `""` (will be set by first phase skill)
+2. Create quest directory if not already created by hook:
+   ```
+   mkdir -p {questDir}
+   ```
+3. Spawn team:
+   ```
+   TeamCreate(team_name="raid-{mode}-{questId}")
+   Agent(subagent_type="warrior", team_name="raid-...", name="warrior")
+   Agent(subagent_type="archer", team_name="raid-...", name="archer")   // Full Raid + Skirmish
+   Agent(subagent_type="rogue", team_name="raid-...", name="rogue")     // Full Raid only
+   ```
+
+## Step 5: Begin First Phase
+
+- If PRD needed → Load `raid-canonical-prd` skill, begin Phase 1
+- If PRD skipped → Load `raid-canonical-design` skill, begin Phase 2
+
+**Announce the quest to the party and the human:**
+> "The quest begins: **{task description}**. Mode: **{mode}**. {agent count} brave souls answer the call."
+
+## Red Flags
+
+| Thought | Reality |
+|---------|---------|
+| "Skip the greeting, get to work" | The greeting sets the tone. It takes 5 seconds. Do it. |
+| "The human knows what mode to use" | Recommend first. Let them override. That's the protocol. |
+| "Let me start exploring the codebase" | You are the Wizard. You don't explore. You dispatch. |
+| "I'll figure out the quest type later" | Quest type determines the phase flow. Choose now. |

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

@@ -106,7 +106,7 @@ Follow the same RED-GREEN-REFACTOR discipline but with Playwright:
 4. **Verify GREEN:** Run FULL suite (unit + browser) → all green
 5. **REFACTOR:** Clean up → re-run all
 
-Use `raid-browser-playwright` for detailed guidance. Invoke `raid-browser` for pre-flight and boot.
+Invoke `raid-browser` for pre-flight and boot. Use the browser test patterns below for Playwright-specific guidance.
 
 ### "Tests pass" = Unit AND Browser Tests