claude-raid 0.1.6 → 0.2.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bin/cli.js +13 -1
- package/package.json +1 -1
- package/src/descriptions.js +26 -25
- package/src/init.js +6 -10
- package/src/merge-settings.js +1 -22
- package/src/remove.js +18 -16
- package/src/ui.js +1 -1
- package/src/update.js +28 -13
- package/template/.claude/agents/archer.md +14 -109
- package/template/.claude/agents/rogue.md +15 -110
- package/template/.claude/agents/warrior.md +12 -108
- package/template/.claude/agents/wizard.md +15 -235
- package/template/.claude/dungeon-master-rules.md +210 -0
- package/template/.claude/hooks/raid-lib.sh +29 -2
- package/template/.claude/hooks/raid-pre-compact.sh +12 -1
- package/template/.claude/hooks/raid-session-end.sh +23 -13
- package/template/.claude/hooks/raid-session-start.sh +28 -16
- package/template/.claude/hooks/validate-commit.sh +15 -74
- package/template/.claude/hooks/validate-dungeon.sh +47 -13
- package/template/.claude/hooks/validate-file-naming.sh +6 -2
- package/template/.claude/hooks/validate-no-placeholders.sh +3 -3
- package/template/.claude/hooks/validate-write-gate.sh +47 -36
- package/template/.claude/party-rules.md +202 -0
- package/template/.claude/skills/raid-browser-chrome/SKILL.md +1 -1
- package/template/.claude/skills/{raid-design → raid-canonical-design}/SKILL.md +60 -14
- package/template/.claude/skills/{raid-implementation → raid-canonical-implementation}/SKILL.md +48 -11
- package/template/.claude/skills/{raid-implementation-plan → raid-canonical-implementation-plan}/SKILL.md +57 -15
- package/template/.claude/skills/raid-canonical-prd/SKILL.md +133 -0
- package/template/.claude/skills/raid-canonical-protocol/SKILL.md +211 -0
- package/template/.claude/skills/{raid-review → raid-canonical-review}/SKILL.md +86 -15
- package/template/.claude/skills/raid-debugging/SKILL.md +30 -5
- package/template/.claude/skills/raid-init/SKILL.md +130 -0
- package/template/.claude/skills/raid-tdd/SKILL.md +1 -1
- package/template/.claude/skills/raid-wrap-up/SKILL.md +184 -0
- package/template/.claude/hooks/raid-stop.sh +0 -68
- package/template/.claude/hooks/raid-task-completed.sh +0 -37
- package/template/.claude/hooks/raid-teammate-idle.sh +0 -28
- package/template/.claude/raid-rules.md +0 -30
- package/template/.claude/skills/raid-browser-playwright/SKILL.md +0 -163
- package/template/.claude/skills/raid-finishing/SKILL.md +0 -131
- package/template/.claude/skills/raid-git-worktrees/SKILL.md +0 -96
- package/template/.claude/skills/raid-protocol/SKILL.md +0 -335
|
@@ -1,14 +1,14 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: raid-review
|
|
3
|
-
description: "Phase
|
|
2
|
+
name: raid-canonical-review
|
|
3
|
+
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."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
# Raid Review — Phase
|
|
6
|
+
# Raid Review — Phase 5 (Optional)
|
|
7
7
|
|
|
8
|
-
Three reviewers, three angles, zero mercy.
|
|
8
|
+
Three reviewers, three angles, zero mercy. Pinning then fixing. Black cards for the unfixable.
|
|
9
9
|
|
|
10
10
|
<HARD-GATE>
|
|
11
|
-
|
|
11
|
+
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.
|
|
12
12
|
</HARD-GATE>
|
|
13
13
|
|
|
14
14
|
## Mode Behavior
|
|
@@ -21,7 +21,7 @@ Do NOT declare work complete without Phase 4 (except Scout mode). All assigned a
|
|
|
21
21
|
|
|
22
22
|
```dot
|
|
23
23
|
digraph review {
|
|
24
|
-
"Wizard reads design doc, plan, Phase
|
|
24
|
+
"Wizard reads design doc, plan, Phase 4 implementation log" -> "Wizard opens review board";
|
|
25
25
|
"Wizard opens Dungeon + dispatches" -> "Agents review independently";
|
|
26
26
|
"Agents review independently" -> "Agents fight over findings directly";
|
|
27
27
|
"Agents fight over findings directly" -> "Agents challenge missing findings";
|
|
@@ -32,14 +32,14 @@ digraph review {
|
|
|
32
32
|
"Assign fixes" -> "Fix + verify + challengers re-attack";
|
|
33
33
|
"Fix + verify + challengers re-attack" -> "Wizard closes: categorizes surviving issues";
|
|
34
34
|
"Critical or Important?" -> "Wizard final ruling" [label="no"];
|
|
35
|
-
"Wizard final ruling" -> "
|
|
35
|
+
"Wizard final ruling" -> "Commit + invoke raid-wrap-up" [shape=doublecircle];
|
|
36
36
|
}
|
|
37
37
|
```
|
|
38
38
|
|
|
39
39
|
## Wizard Checklist
|
|
40
40
|
|
|
41
|
-
1. **Prepare** — gather git range, design doc, plan doc, read
|
|
42
|
-
2. **Open the
|
|
41
|
+
1. **Prepare** — gather git range, design doc, plan doc, read `{questDir}/phase-4-implementation.md`
|
|
42
|
+
2. **Open the review board** — create `{questDir}/phase-5-review.md`
|
|
43
43
|
3. **Dispatch** — all agents review independently, then interact directly
|
|
44
44
|
4. **Observe the fight** — agents challenge findings and missing findings directly
|
|
45
45
|
5. **Close** — categorize surviving issues by severity from Dungeon
|
|
@@ -48,15 +48,15 @@ digraph review {
|
|
|
48
48
|
8. **Rule on fixes** — Critical and Important must be fixed (code AND browser)
|
|
49
49
|
9. **Verify fixes** — targeted re-attack after fixes (use `raid-verification`)
|
|
50
50
|
10. **Final ruling** — approved or rejected
|
|
51
|
-
11. **
|
|
52
|
-
12. **Transition** — invoke `raid-
|
|
51
|
+
11. **Commit** — `fix(quest-{slug}): phase 5 review — {N} findings resolved`
|
|
52
|
+
12. **Transition** — invoke `raid-wrap-up`
|
|
53
53
|
|
|
54
54
|
## Opening the Dungeon
|
|
55
55
|
|
|
56
|
-
Create
|
|
56
|
+
Create `{questDir}/phase-5-review.md`:
|
|
57
57
|
|
|
58
58
|
```markdown
|
|
59
|
-
#
|
|
59
|
+
# Phase 5: Review
|
|
60
60
|
## Quest: Full adversarial review of <feature> implementation
|
|
61
61
|
## Mode: <Full Raid | Skirmish>
|
|
62
62
|
|
|
@@ -97,6 +97,30 @@ Create `.claude/raid-dungeon.md`:
|
|
|
97
97
|
|
|
98
98
|
**Production:** Performance OK? External calls have timeouts? No secrets in code?
|
|
99
99
|
|
|
100
|
+
## Verification Protocol for Findings
|
|
101
|
+
|
|
102
|
+
Before acting on ANY finding (yours or a teammate's):
|
|
103
|
+
1. **READ:** Complete the finding without reacting
|
|
104
|
+
2. **VERIFY:** Check against codebase reality — read the actual code at the referenced location
|
|
105
|
+
3. **EVALUATE:** Is this technically sound for THIS codebase? Does fixing it break something else?
|
|
106
|
+
4. **RESPOND:** Technical evidence or reasoned pushback
|
|
107
|
+
|
|
108
|
+
## No Performative Agreement
|
|
109
|
+
|
|
110
|
+
NEVER respond with "You're absolutely right!" or "Great point!" or "Good catch!"
|
|
111
|
+
Instead: state the technical finding, show evidence, or push back.
|
|
112
|
+
Actions speak. Fix and show — don't compliment.
|
|
113
|
+
|
|
114
|
+
If a finding IS correct: `"Fixed. [Brief description of what changed]."` or just fix it silently.
|
|
115
|
+
|
|
116
|
+
## YAGNI Check on Findings
|
|
117
|
+
|
|
118
|
+
Before implementing a "professional improvement" suggestion:
|
|
119
|
+
- Grep codebase for actual usage of the component
|
|
120
|
+
- If unused: suggest removing (YAGNI) — `"This endpoint isn't called. Remove it?"`
|
|
121
|
+
- If used: implement properly
|
|
122
|
+
- Don't gold-plate during review
|
|
123
|
+
|
|
100
124
|
## The Fight — Agents Challenge Each Other
|
|
101
125
|
|
|
102
126
|
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.
|
|
|
141
165
|
|
|
142
166
|
**Browser bugs block merge the same way code bugs do.**
|
|
143
167
|
|
|
168
|
+
## Black Card System
|
|
169
|
+
|
|
170
|
+
If any agent finds something that fundamentally breaks the architecture — a change so deep it invalidates the implementation — they play a `BLACKCARD:`:
|
|
171
|
+
|
|
172
|
+
```
|
|
173
|
+
BLACKCARD: [description of breaking concern]
|
|
174
|
+
Evidence: [file paths, scenarios, why this is unfixable within current design]
|
|
175
|
+
Impact: [what breaks, how deep the damage goes]
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
**Black Card flow:**
|
|
179
|
+
1. Agent plays `BLACKCARD:` → other agents independently verify
|
|
180
|
+
2. If 2+ agents agree it's a black card → Wizard escalates to human
|
|
181
|
+
3. Wizard presents to human with full context (digested, not raw):
|
|
182
|
+
- What the black card is
|
|
183
|
+
- Why it's unfixable in current design
|
|
184
|
+
- Options:
|
|
185
|
+
a) **Rollback** — Go back to PRD or Design phase (creates `phase-2-design-v2.md`)
|
|
186
|
+
b) **Accept** — Live with the limitation, document it, continue
|
|
187
|
+
4. Human decides → Wizard acts accordingly
|
|
188
|
+
|
|
189
|
+
**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."
|
|
190
|
+
|
|
191
|
+
## Fix Implementation Order
|
|
192
|
+
|
|
193
|
+
When the Wizard assigns fixes during the Fixing subphase, prioritize in this order within each severity level:
|
|
194
|
+
1. **Blocking issues** — crashes, security holes, data loss
|
|
195
|
+
2. **Simple fixes** — typos, imports, naming inconsistencies
|
|
196
|
+
3. **Complex fixes** — refactoring, logic changes, architectural adjustments
|
|
197
|
+
|
|
198
|
+
Test each fix individually. Verify no regressions before moving to the next fix.
|
|
199
|
+
|
|
200
|
+
## Unclear Finding Protocol
|
|
201
|
+
|
|
202
|
+
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.
|
|
203
|
+
|
|
144
204
|
## Closing the Phase
|
|
145
205
|
|
|
146
|
-
The Wizard closes when agents have exhausted their findings and the
|
|
206
|
+
The Wizard closes when agents have exhausted their findings and the review board has all issues classified:
|
|
147
207
|
|
|
148
208
|
**RULING: APPROVED FOR MERGE** — all Critical/Important fixed, tests pass, requirements met.
|
|
149
209
|
|
|
@@ -159,4 +219,15 @@ The Wizard closes when agents have exhausted their findings and the Dungeon has
|
|
|
159
219
|
| "The tests pass, so it works" | Tests prove what they test. What DON'T they test? |
|
|
160
220
|
| "Let's skip re-review of the fixes" | Fixes introduce new bugs. Always re-attack. |
|
|
161
221
|
|
|
162
|
-
|
|
222
|
+
---
|
|
223
|
+
|
|
224
|
+
## Phase Transition
|
|
225
|
+
|
|
226
|
+
When the RULING is APPROVED FOR MERGE:
|
|
227
|
+
|
|
228
|
+
1. Update `.claude/raid-session` phase to `"wrap-up"`
|
|
229
|
+
2. **Commit**: `fix(quest-{slug}): phase 5 review — {N} findings resolved`
|
|
230
|
+
3. **Send phase report to human**: findings count, fixes applied, any black cards
|
|
231
|
+
4. **Load the `raid-wrap-up` skill now and begin Phase 6.**
|
|
232
|
+
|
|
233
|
+
Do not wait. Do not ask. The next action after approving for merge is loading the next skill.
|
|
@@ -60,8 +60,19 @@ digraph debugging {
|
|
|
60
60
|
1. **Read error messages carefully** — stack traces, line numbers, error codes. Don't skip past them. The answer is often in the first error.
|
|
61
61
|
2. **Reproduce consistently** — exact steps, every time. If not reproducible, gather more data — don't guess. An unreproducible bug is not understood.
|
|
62
62
|
3. **Check recent changes** — `git diff`, recent commits, new dependencies, config changes. What changed since it last worked?
|
|
63
|
-
4. **Gather evidence at boundaries** — in multi-component systems,
|
|
64
|
-
|
|
63
|
+
4. **Gather evidence at boundaries** — in multi-component systems, add diagnostic instrumentation:
|
|
64
|
+
```
|
|
65
|
+
For EACH component boundary:
|
|
66
|
+
- Log what data enters the component
|
|
67
|
+
- Log what data exits the component
|
|
68
|
+
- Verify environment/config propagation
|
|
69
|
+
- Check state at each layer
|
|
70
|
+
Run ONCE to gather evidence showing WHERE it breaks.
|
|
71
|
+
THEN investigate that specific component.
|
|
72
|
+
```
|
|
73
|
+
Example: API → Service → Database → Response. Log at each boundary. The layer where input looks right but output looks wrong is your target.
|
|
74
|
+
|
|
75
|
+
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.
|
|
65
76
|
|
|
66
77
|
### Phase 2: Pattern Analysis
|
|
67
78
|
|
|
@@ -72,9 +83,10 @@ digraph debugging {
|
|
|
72
83
|
|
|
73
84
|
### Phase 3: Hypothesis and Testing
|
|
74
85
|
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
86
|
+
**Per-agent hypothesis discipline:**
|
|
87
|
+
1. **Form ONE specific hypothesis:** "I think X is the root cause because Y." Write it down. Be specific, not vague.
|
|
88
|
+
2. **Make the SMALLEST possible change** to test it. One variable at a time. Don't fix multiple things at once.
|
|
89
|
+
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.
|
|
78
90
|
|
|
79
91
|
### Phase 4: Fix Implementation
|
|
80
92
|
|
|
@@ -127,6 +139,13 @@ If 3 or more fix attempts fail, **STOP fixing and question architecture:**
|
|
|
127
139
|
|
|
128
140
|
This is not failure — it's the system working. Detecting architectural problems before sinking more time into symptom fixes.
|
|
129
141
|
|
|
142
|
+
**Pattern indicating architectural problem:**
|
|
143
|
+
- Each fix reveals new shared state or coupling in a different place
|
|
144
|
+
- Fixes require "massive refactoring" to implement
|
|
145
|
+
- Each fix creates new symptoms elsewhere
|
|
146
|
+
|
|
147
|
+
If within a Canonical Quest: consider playing a `BLACKCARD:` — this may be a design-level problem, not an implementation bug.
|
|
148
|
+
|
|
130
149
|
## Defense in Depth
|
|
131
150
|
|
|
132
151
|
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:
|
|
|
148
167
|
| "The issue is simple, don't need process" | Simple issues have root causes too. Process is fast. |
|
|
149
168
|
| "Emergency, no time" | Systematic debugging is FASTER than thrashing. Always. |
|
|
150
169
|
| "Just try this first" | The first fix sets the pattern. Do it right. |
|
|
170
|
+
| "Pattern says X but I'll adapt" | Partial understanding guarantees bugs. Read it completely. |
|
|
171
|
+
| "I don't fully understand but this might work" | STOP. Return to Phase 1. |
|
|
172
|
+
| "Multiple changes at once saves time" | Can't isolate what worked. Causes new bugs. |
|
|
173
|
+
| "I'll write the test after confirming fix" | Untested fixes don't stick. Test first proves it. |
|
|
174
|
+
| "Skip investigation, the error message says it all" | Error messages describe symptoms, not root causes. |
|
|
175
|
+
| "Add multiple changes, run tests" | One variable at a time. Scientific method. |
|
|
151
176
|
|
|
152
177
|
## Escalation
|
|
153
178
|
|
|
@@ -0,0 +1,130 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: raid-init
|
|
3
|
+
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."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Raid Init — Quest Selection & Session Setup
|
|
7
|
+
|
|
8
|
+
The first skill loaded when the Wizard starts. Guides the greeting, quest selection, and session bootstrap.
|
|
9
|
+
|
|
10
|
+
<HARD-GATE>
|
|
11
|
+
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.
|
|
12
|
+
</HARD-GATE>
|
|
13
|
+
|
|
14
|
+
## Process Flow
|
|
15
|
+
|
|
16
|
+
```dot
|
|
17
|
+
digraph init {
|
|
18
|
+
"Read rules + raid.json" -> "Check for in-progress quests";
|
|
19
|
+
"Check for in-progress quests" -> "Offer to resume?" [shape=diamond];
|
|
20
|
+
"Offer to resume?" -> "Resume existing quest" [label="yes, human confirms"];
|
|
21
|
+
"Offer to resume?" -> "Greet the human" [label="no"];
|
|
22
|
+
"Greet the human" -> "Present quest menu";
|
|
23
|
+
"Present quest menu" -> "Canonical Quest?" [shape=diamond];
|
|
24
|
+
"Canonical Quest?" -> "Ask: PRD needed?" [label="A"];
|
|
25
|
+
"Canonical Quest?" -> "Coming soon message" [label="B/D/E/F"];
|
|
26
|
+
"Coming soon message" -> "Present quest menu";
|
|
27
|
+
"Ask: PRD needed?" -> "Human describes task";
|
|
28
|
+
"Human describes task" -> "Assess complexity + recommend mode";
|
|
29
|
+
"Assess complexity + recommend mode" -> "Human approves mode?";
|
|
30
|
+
"Human approves mode?" -> "Spawn team + create quest dir" [label="yes"];
|
|
31
|
+
"Human approves mode?" -> "Assess complexity + recommend mode" [label="override"];
|
|
32
|
+
"Spawn team + create quest dir" -> "Begin first phase" [shape=doublecircle];
|
|
33
|
+
}
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
## Step 1: Check for In-Progress Quests
|
|
37
|
+
|
|
38
|
+
Look in `.claude/dungeon/` for existing quest directories. If any exist:
|
|
39
|
+
|
|
40
|
+
> "I sense an unfinished quest in the dungeon: **{quest-slug}**. Shall we resume where we left off, or begin a new adventure?"
|
|
41
|
+
|
|
42
|
+
If the human wants to resume, read the raid-session file and continue from the current phase.
|
|
43
|
+
|
|
44
|
+
## Step 2: Greet the Human
|
|
45
|
+
|
|
46
|
+
```
|
|
47
|
+
Farewell brave Engineer, Welcome to the dungeon —
|
|
48
|
+
the raid is waiting for you.
|
|
49
|
+
Let's make the bards sing about the quest we are embracing today:
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
## Step 3: Present Quest Menu
|
|
53
|
+
|
|
54
|
+
```
|
|
55
|
+
Choose your quest:
|
|
56
|
+
|
|
57
|
+
A) Canonical Quest — Full 6-phase development cycle
|
|
58
|
+
(PRD, Design, Plan, Build, Review, Wrap Up)
|
|
59
|
+
|
|
60
|
+
B) Round Table — (Coming soon)
|
|
61
|
+
D) Map Exploration — (Coming soon)
|
|
62
|
+
E) Bug Hunting — (Coming soon)
|
|
63
|
+
F) Bard Bonfire — (Coming soon)
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
If the human selects B, D, E, or F:
|
|
67
|
+
> "That quest type is still being forged by the arcane smiths. Choose another path for now."
|
|
68
|
+
|
|
69
|
+
Loop back to the menu.
|
|
70
|
+
|
|
71
|
+
## Step 4: Canonical Quest Setup
|
|
72
|
+
|
|
73
|
+
### 4a. PRD Question
|
|
74
|
+
|
|
75
|
+
> "Do you carry a Product Requirements scroll, or shall we forge one together?"
|
|
76
|
+
|
|
77
|
+
- If PRD needed → first phase will be PRD (raid-canonical-prd)
|
|
78
|
+
- If PRD not needed → first phase will be Design (raid-canonical-design)
|
|
79
|
+
|
|
80
|
+
### 4b. Task Description
|
|
81
|
+
|
|
82
|
+
Ask the human to describe the task/feature they want to build. Listen carefully. Read 3 times internally.
|
|
83
|
+
|
|
84
|
+
### 4c. Mode Recommendation
|
|
85
|
+
|
|
86
|
+
Assess complexity and recommend a mode:
|
|
87
|
+
|
|
88
|
+
| Mode | When | Agents |
|
|
89
|
+
|------|------|--------|
|
|
90
|
+
| **Full Raid** | Large features, architectural changes, complex refactors | 3 (Warrior, Archer, Rogue) |
|
|
91
|
+
| **Skirmish** | Medium features, focused changes | 2 (pick most relevant) |
|
|
92
|
+
| **Scout** | Small fixes, minor additions | 1 (pick most relevant) |
|
|
93
|
+
|
|
94
|
+
Present recommendation. Wait for human to approve or override.
|
|
95
|
+
|
|
96
|
+
### 4d. Spawn Team & Setup
|
|
97
|
+
|
|
98
|
+
1. Update raid-session with:
|
|
99
|
+
- `questType`: `"canonical"`
|
|
100
|
+
- `questId`: slugified from task description (e.g., `"auth-redesign"`)
|
|
101
|
+
- `questDir`: `.claude/dungeon/{questId}`
|
|
102
|
+
- `phase`: `""` (will be set by first phase skill)
|
|
103
|
+
2. Create quest directory if not already created by hook:
|
|
104
|
+
```
|
|
105
|
+
mkdir -p {questDir}
|
|
106
|
+
```
|
|
107
|
+
3. Spawn team:
|
|
108
|
+
```
|
|
109
|
+
TeamCreate(team_name="raid-{mode}-{questId}")
|
|
110
|
+
Agent(subagent_type="warrior", team_name="raid-...", name="warrior")
|
|
111
|
+
Agent(subagent_type="archer", team_name="raid-...", name="archer") // Full Raid + Skirmish
|
|
112
|
+
Agent(subagent_type="rogue", team_name="raid-...", name="rogue") // Full Raid only
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
## Step 5: Begin First Phase
|
|
116
|
+
|
|
117
|
+
- If PRD needed → Load `raid-canonical-prd` skill, begin Phase 1
|
|
118
|
+
- If PRD skipped → Load `raid-canonical-design` skill, begin Phase 2
|
|
119
|
+
|
|
120
|
+
**Announce the quest to the party and the human:**
|
|
121
|
+
> "The quest begins: **{task description}**. Mode: **{mode}**. {agent count} brave souls answer the call."
|
|
122
|
+
|
|
123
|
+
## Red Flags
|
|
124
|
+
|
|
125
|
+
| Thought | Reality |
|
|
126
|
+
|---------|---------|
|
|
127
|
+
| "Skip the greeting, get to work" | The greeting sets the tone. It takes 5 seconds. Do it. |
|
|
128
|
+
| "The human knows what mode to use" | Recommend first. Let them override. That's the protocol. |
|
|
129
|
+
| "Let me start exploring the codebase" | You are the Wizard. You don't explore. You dispatch. |
|
|
130
|
+
| "I'll figure out the quest type later" | Quest type determines the phase flow. Choose now. |
|
|
@@ -106,7 +106,7 @@ Follow the same RED-GREEN-REFACTOR discipline but with Playwright:
|
|
|
106
106
|
4. **Verify GREEN:** Run FULL suite (unit + browser) → all green
|
|
107
107
|
5. **REFACTOR:** Clean up → re-run all
|
|
108
108
|
|
|
109
|
-
|
|
109
|
+
Invoke `raid-browser` for pre-flight and boot. Use the browser test patterns below for Playwright-specific guidance.
|
|
110
110
|
|
|
111
111
|
### "Tests pass" = Unit AND Browser Tests
|
|
112
112
|
|
|
@@ -0,0 +1,184 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: raid-wrap-up
|
|
3
|
+
description: "Phase 6 of Canonical Quest. Generates quest storyboard report, creates PR, archives dungeon to vault, dismisses party. No new code."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Raid Wrap Up — Phase 6
|
|
7
|
+
|
|
8
|
+
The quest ends. The bard sings the tale. The treasure is committed. The party rests.
|
|
9
|
+
|
|
10
|
+
<HARD-GATE>
|
|
11
|
+
Do NOT write new code. This phase is about reporting, cleanup, PR creation, and archival. Agents are dismissed, not dispatched.
|
|
12
|
+
</HARD-GATE>
|
|
13
|
+
|
|
14
|
+
## Mode Behavior
|
|
15
|
+
|
|
16
|
+
- **Full Raid**: Wizard writes full storyboard from all phase files. Full PR with narrative.
|
|
17
|
+
- **Skirmish**: Wizard writes condensed storyboard. Standard PR.
|
|
18
|
+
- **Scout**: Wizard writes brief summary. Quick PR.
|
|
19
|
+
|
|
20
|
+
## Process Flow
|
|
21
|
+
|
|
22
|
+
```dot
|
|
23
|
+
digraph wrapup {
|
|
24
|
+
"Wizard updates phase to wrap-up" -> "Create phase-6-wrap-up.md";
|
|
25
|
+
"Create phase-6-wrap-up.md" -> "Write phase-by-phase storyboard";
|
|
26
|
+
"Write phase-by-phase storyboard" -> "Cleanup temp files";
|
|
27
|
+
"Cleanup temp files" -> "Verify all tests pass (fresh run)";
|
|
28
|
+
"Verify all tests pass (fresh run)" -> "Tests pass?" [shape=diamond];
|
|
29
|
+
"Tests pass?" -> "Fix first. Do not proceed." [label="no"];
|
|
30
|
+
"Fix first. Do not proceed." -> "Verify all tests pass (fresh run)";
|
|
31
|
+
"Tests pass?" -> "Present merge options" [label="yes"];
|
|
32
|
+
"Present merge options" -> "Human chooses";
|
|
33
|
+
"Human chooses" -> "Execute choice";
|
|
34
|
+
"Execute choice" -> "Dismiss party";
|
|
35
|
+
"Dismiss party" -> "Archive to vault";
|
|
36
|
+
"Archive to vault" -> "Final commit + cleanup" [shape=doublecircle];
|
|
37
|
+
}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
## Wizard Checklist
|
|
41
|
+
|
|
42
|
+
1. **Update raid-session** — set phase to `"wrap-up"`
|
|
43
|
+
2. **Create storyboard** — `{questDir}/phase-6-wrap-up.md`
|
|
44
|
+
3. **Write narrative** — phase-by-phase story from quest files
|
|
45
|
+
4. **Cleanup** — remove temp configs, debug files, stale artifacts
|
|
46
|
+
5. **Verify tests** — fresh full run, must pass
|
|
47
|
+
6. **Present options** — 4 merge choices
|
|
48
|
+
7. **Execute choice** — merge, PR, keep, or discard
|
|
49
|
+
8. **Dismiss party** — RPG flavor shutdown
|
|
50
|
+
9. **Archive** — move dungeon to vault
|
|
51
|
+
10. **Final commit** — `docs(quest-{slug}): phase 6 wrap-up — quest complete`
|
|
52
|
+
11. **Session cleanup** — remove `.claude/raid-session`
|
|
53
|
+
|
|
54
|
+
## Step 1: The Quest Storyboard
|
|
55
|
+
|
|
56
|
+
Create `{questDir}/phase-6-wrap-up.md` and write a phase-by-phase narrative:
|
|
57
|
+
|
|
58
|
+
```markdown
|
|
59
|
+
# Phase 6: Wrap Up — Quest Storyboard
|
|
60
|
+
## Quest: <quest name>
|
|
61
|
+
## Mode: <mode>
|
|
62
|
+
|
|
63
|
+
### Phase 1: PRD — Forging the Scroll
|
|
64
|
+
(if phase-1-prd.md exists)
|
|
65
|
+
- What requirements were established
|
|
66
|
+
- Key decisions from research
|
|
67
|
+
|
|
68
|
+
### Phase 2: Design — Charting the Map
|
|
69
|
+
- Architecture chosen and why
|
|
70
|
+
- Key trade-offs resolved
|
|
71
|
+
- Alternatives considered and rejected
|
|
72
|
+
|
|
73
|
+
### Phase 3: Implementation Plan — Marshaling the Forces
|
|
74
|
+
- Number of tasks, dependency structure
|
|
75
|
+
- Risk areas identified
|
|
76
|
+
|
|
77
|
+
### Phase 4: Implementation — Into the Fray
|
|
78
|
+
- What was built
|
|
79
|
+
- Challenges overcome
|
|
80
|
+
- Test coverage highlights
|
|
81
|
+
|
|
82
|
+
### Phase 5: Review — Inspecting the Treasure
|
|
83
|
+
(if phase-5-review.md exists)
|
|
84
|
+
- Findings pinned and resolved
|
|
85
|
+
- Black cards (if any)
|
|
86
|
+
- Fixes applied
|
|
87
|
+
|
|
88
|
+
### Summary
|
|
89
|
+
- Total phases completed
|
|
90
|
+
- Key achievements
|
|
91
|
+
- Known limitations
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
Read all prior phase files from the quest directory to build this narrative.
|
|
95
|
+
|
|
96
|
+
## Step 2: Cleanup
|
|
97
|
+
|
|
98
|
+
Remove temporary artifacts:
|
|
99
|
+
- Debug files
|
|
100
|
+
- Temp configs
|
|
101
|
+
- Stale backups in the quest directory
|
|
102
|
+
|
|
103
|
+
## Step 3: Final Verification
|
|
104
|
+
|
|
105
|
+
```
|
|
106
|
+
1. IDENTIFY: test command from .claude/raid.json
|
|
107
|
+
2. RUN: Execute the FULL test suite (fresh, complete)
|
|
108
|
+
3. READ: Full output, check exit code, count failures
|
|
109
|
+
4. VERIFY: Zero failures?
|
|
110
|
+
If NO → STOP. Fix first. Do not present options.
|
|
111
|
+
If YES → Proceed with evidence.
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
## Step 4: Present Options
|
|
115
|
+
|
|
116
|
+
```
|
|
117
|
+
RULING: The quest is complete and verified.
|
|
118
|
+
|
|
119
|
+
Tests: [N] passing, 0 failures (evidence: [command output])
|
|
120
|
+
|
|
121
|
+
Options:
|
|
122
|
+
1. Merge back to [base-branch] locally
|
|
123
|
+
2. Push and create a Pull Request
|
|
124
|
+
3. Keep the branch as-is (handle later)
|
|
125
|
+
4. Discard this work
|
|
126
|
+
|
|
127
|
+
Which option?
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
**For option 2 (PR):** Create the PR with:
|
|
131
|
+
- **Title**: Descriptive, includes quest name
|
|
132
|
+
- **Body**: The phase-by-phase storyboard from the wrap-up doc
|
|
133
|
+
|
|
134
|
+
## Step 5: Execute
|
|
135
|
+
|
|
136
|
+
| Option | Actions |
|
|
137
|
+
|--------|---------|
|
|
138
|
+
| **1. Merge** | Checkout base -> pull -> merge -> run tests on merged result -> delete branch -> clean up |
|
|
139
|
+
| **2. PR** | Push with -u -> create PR via gh with storyboard body -> clean up |
|
|
140
|
+
| **3. Keep** | Report branch location. Done. |
|
|
141
|
+
| **4. Discard** | Require typed "discard" confirmation -> delete branch (force) -> clean up |
|
|
142
|
+
|
|
143
|
+
## Step 6: Dismiss the Party
|
|
144
|
+
|
|
145
|
+
Send shutdown to all teammates with RPG flavor:
|
|
146
|
+
|
|
147
|
+
> "The quest is done, brave engineers. The bards will sing of **{quest-name}**. Sheathe your tools — until the next adventure."
|
|
148
|
+
|
|
149
|
+
```
|
|
150
|
+
SendMessage(to="warrior", message={"type": "shutdown_request"})
|
|
151
|
+
SendMessage(to="archer", message={"type": "shutdown_request"})
|
|
152
|
+
SendMessage(to="rogue", message={"type": "shutdown_request"})
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
## Step 7: Archive to Vault
|
|
156
|
+
|
|
157
|
+
1. Move quest directory to vault:
|
|
158
|
+
```
|
|
159
|
+
mv .claude/dungeon/{quest-slug}/ .claude/vault/{quest-slug}/
|
|
160
|
+
```
|
|
161
|
+
2. Update vault index at `.claude/vault/index.md`:
|
|
162
|
+
```
|
|
163
|
+
| {date} | [{quest-name}]({quest-slug}/quest.md) | {mode} | {tags} |
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
## Step 8: Final Commit & Cleanup
|
|
167
|
+
|
|
168
|
+
1. **Commit**: `docs(quest-{slug}): phase 6 wrap-up — quest complete`
|
|
169
|
+
2. **Remove**: `.claude/raid-session`
|
|
170
|
+
3. **Session is over. No further skills to load.**
|
|
171
|
+
|
|
172
|
+
## Red Flags
|
|
173
|
+
|
|
174
|
+
| Thought | Reality |
|
|
175
|
+
|---------|---------|
|
|
176
|
+
| "Tests passed earlier, no need to re-run" | Fresh run or no claim. Always. |
|
|
177
|
+
| "Skip the storyboard, just make the PR" | The storyboard IS the PR body. It documents the journey. |
|
|
178
|
+
| "Leave the dungeon files, they might be useful" | Archive to vault. Session artifacts don't belong in the repo. |
|
|
179
|
+
| "Merge without testing the merged result" | Merges introduce conflicts. Test after merge. |
|
|
180
|
+
| "I'll write the code fix myself" | You are the Wizard. Dispatch the fix to an agent. |
|
|
181
|
+
|
|
182
|
+
## Phase Spoils
|
|
183
|
+
|
|
184
|
+
**Output**: `{questDir}/phase-6-wrap-up.md` — The complete quest narrative, phase by phase.
|
|
@@ -1,68 +0,0 @@
|
|
|
1
|
-
#!/usr/bin/env bash
|
|
2
|
-
# Raid lifecycle hook: Stop
|
|
3
|
-
# Detects phase transitions and injects human confirmation gate.
|
|
4
|
-
set -euo pipefail
|
|
5
|
-
|
|
6
|
-
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
7
|
-
source "$SCRIPT_DIR/raid-lib.sh"
|
|
8
|
-
|
|
9
|
-
if [ "$RAID_ACTIVE" != "true" ]; then
|
|
10
|
-
exit 0
|
|
11
|
-
fi
|
|
12
|
-
|
|
13
|
-
if [ "$RAID_LIFECYCLE_PHASE_CONFIRM" != "true" ]; then
|
|
14
|
-
exit 0
|
|
15
|
-
fi
|
|
16
|
-
|
|
17
|
-
STORED_PHASE="$RAID_PHASE"
|
|
18
|
-
|
|
19
|
-
# Phase ordering: name → rank for comparison
|
|
20
|
-
phase_rank() {
|
|
21
|
-
case "$1" in
|
|
22
|
-
design) echo 1 ;;
|
|
23
|
-
plan) echo 2 ;;
|
|
24
|
-
implementation) echo 3 ;;
|
|
25
|
-
review) echo 4 ;;
|
|
26
|
-
finishing) echo 5 ;;
|
|
27
|
-
*) echo 0 ;;
|
|
28
|
-
esac
|
|
29
|
-
}
|
|
30
|
-
|
|
31
|
-
# Detect current phase from Dungeon file
|
|
32
|
-
# Only matches structured markers: <!-- RAID_PHASE: plan -->
|
|
33
|
-
DETECTED_PHASE="$STORED_PHASE"
|
|
34
|
-
if [ -f ".claude/raid-dungeon.md" ]; then
|
|
35
|
-
BEST_RANK=0
|
|
36
|
-
BEST_PHASE="$STORED_PHASE"
|
|
37
|
-
for phase_name in $(grep -oE '<!-- RAID_PHASE: (design|plan|implementation|review|finishing) -->' ".claude/raid-dungeon.md" 2>/dev/null | grep -oE '(design|plan|implementation|review|finishing)'); do
|
|
38
|
-
RANK=$(phase_rank "$phase_name")
|
|
39
|
-
if [ "$RANK" -gt "$BEST_RANK" ]; then
|
|
40
|
-
BEST_RANK=$RANK
|
|
41
|
-
BEST_PHASE=$phase_name
|
|
42
|
-
fi
|
|
43
|
-
done
|
|
44
|
-
DETECTED_PHASE="$BEST_PHASE"
|
|
45
|
-
fi
|
|
46
|
-
|
|
47
|
-
# Compare phases by rank
|
|
48
|
-
STORED_RANK=$(phase_rank "$STORED_PHASE")
|
|
49
|
-
DETECTED_RANK=$(phase_rank "$DETECTED_PHASE")
|
|
50
|
-
|
|
51
|
-
if [ "$DETECTED_RANK" -gt "$STORED_RANK" ] 2>/dev/null; then
|
|
52
|
-
# Update raid-session with new phase name
|
|
53
|
-
if command -v jq >/dev/null 2>&1; then
|
|
54
|
-
jq --arg phase "$DETECTED_PHASE" '.phase = $phase' ".claude/raid-session" > ".claude/raid-session.tmp" 2>/dev/null && \
|
|
55
|
-
mv ".claude/raid-session.tmp" ".claude/raid-session"
|
|
56
|
-
fi
|
|
57
|
-
|
|
58
|
-
cat <<ENDJSON
|
|
59
|
-
{
|
|
60
|
-
"hookSpecificOutput": {
|
|
61
|
-
"hookEventName": "Stop",
|
|
62
|
-
"additionalContext": "Phase transition detected ($STORED_PHASE → $DETECTED_PHASE). The Wizard must confirm with the human before opening the next phase."
|
|
63
|
-
}
|
|
64
|
-
}
|
|
65
|
-
ENDJSON
|
|
66
|
-
fi
|
|
67
|
-
|
|
68
|
-
exit 0
|
|
@@ -1,37 +0,0 @@
|
|
|
1
|
-
#!/usr/bin/env bash
|
|
2
|
-
# Raid lifecycle hook: TaskCompleted
|
|
3
|
-
# Blocks task completion if tests haven't run recently.
|
|
4
|
-
set -euo pipefail
|
|
5
|
-
|
|
6
|
-
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
|
7
|
-
source "$SCRIPT_DIR/raid-lib.sh"
|
|
8
|
-
|
|
9
|
-
if [ "$RAID_ACTIVE" != "true" ]; then
|
|
10
|
-
exit 0
|
|
11
|
-
fi
|
|
12
|
-
|
|
13
|
-
if [ "$RAID_LIFECYCLE_COMPLETION_GATE" != "true" ]; then
|
|
14
|
-
exit 0
|
|
15
|
-
fi
|
|
16
|
-
|
|
17
|
-
TEST_RUN_FILE=".claude/raid-last-test-run"
|
|
18
|
-
|
|
19
|
-
if [ ! -f "$TEST_RUN_FILE" ]; then
|
|
20
|
-
raid_block "Tests must pass before marking a task complete. No test run recorded — run your test command first."
|
|
21
|
-
fi
|
|
22
|
-
|
|
23
|
-
LAST_RUN=$(cat "$TEST_RUN_FILE" 2>/dev/null | tr -d '[:space:]')
|
|
24
|
-
NOW=$(date +%s)
|
|
25
|
-
WINDOW=$((RAID_LIFECYCLE_TEST_WINDOW * 60))
|
|
26
|
-
# Guard against corrupted/non-numeric timestamp
|
|
27
|
-
case "$LAST_RUN" in
|
|
28
|
-
''|*[!0-9]*) raid_block "Tests must pass before marking a task complete. Test run timestamp is invalid — run your test command first." ;;
|
|
29
|
-
esac
|
|
30
|
-
AGE=$((NOW - LAST_RUN))
|
|
31
|
-
|
|
32
|
-
if [ "$AGE" -gt "$WINDOW" ]; then
|
|
33
|
-
MINS_AGO=$((AGE / 60))
|
|
34
|
-
raid_block "Tests last ran $MINS_AGO minutes ago (window is $RAID_LIFECYCLE_TEST_WINDOW min). Run tests again before marking this task complete."
|
|
35
|
-
fi
|
|
36
|
-
|
|
37
|
-
exit 0
|