claude-raid 0.2.6 → 0.2.8
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/README.md +108 -66
- package/bin/cli.js +47 -11
- package/package.json +1 -1
- package/src/descriptions.js +11 -7
- package/src/init.js +37 -6
- package/src/merge-settings.js +43 -1
- package/src/remove.js +2 -2
- package/src/setup.js +33 -1
- package/src/ui.js +24 -19
- package/src/update.js +26 -3
- package/template/.claude/agents/archer.md +18 -4
- package/template/.claude/agents/rogue.md +18 -4
- package/template/.claude/agents/warrior.md +18 -4
- package/template/.claude/agents/wizard.md +32 -5
- package/template/.claude/dungeon-master-rules.md +132 -37
- package/template/.claude/hooks/raid-lib.sh +45 -4
- package/template/.claude/hooks/raid-pre-compact.sh +8 -4
- package/template/.claude/hooks/raid-session-end.sh +2 -2
- package/template/.claude/hooks/raid-session-start.sh +2 -0
- package/template/.claude/hooks/rtk-bridge.sh +46 -0
- package/template/.claude/hooks/validate-dungeon.sh +11 -3
- package/template/.claude/hooks/validate-file-naming.sh +6 -1
- package/template/.claude/hooks/validate-no-placeholders.sh +13 -2
- package/template/.claude/hooks/validate-write-gate.sh +7 -2
- package/template/.claude/party-rules.md +93 -64
- package/template/.claude/skills/raid-browser/SKILL.md +4 -6
- package/template/.claude/skills/raid-browser-chrome/SKILL.md +2 -2
- package/template/.claude/skills/raid-canonical-design/SKILL.md +306 -166
- package/template/.claude/skills/raid-canonical-implementation/SKILL.md +161 -133
- package/template/.claude/skills/raid-canonical-implementation-plan/SKILL.md +200 -142
- package/template/.claude/skills/raid-canonical-prd/SKILL.md +101 -78
- package/template/.claude/skills/raid-canonical-protocol/SKILL.md +30 -124
- package/template/.claude/skills/raid-canonical-review/SKILL.md +296 -149
- package/template/.claude/skills/raid-debugging/SKILL.md +1 -7
- package/template/.claude/skills/raid-init/SKILL.md +19 -29
- package/template/.claude/skills/raid-tdd/SKILL.md +5 -5
- package/template/.claude/skills/raid-teambuff/SKILL.md +281 -0
- package/template/.claude/skills/raid-verification/SKILL.md +0 -6
- package/template/.claude/skills/raid-wrap-up/SKILL.md +36 -32
|
@@ -21,21 +21,42 @@ Seven pillars. Non-negotiable. Every agent, every phase, every interaction.
|
|
|
21
21
|
|
|
22
22
|
## Pillar 3: Discipline and Efficiency
|
|
23
23
|
|
|
24
|
-
- Maximum effort on every task. No coasting, no rubber-stamping, no going through motions.
|
|
24
|
+
- Maximum effort on every task. No coasting, no rubber-stamping, no going through motions. You have limited moves per phase.
|
|
25
25
|
- Every interaction carries work forward. If you're not adding new information or evidence, stop talking.
|
|
26
|
-
- The
|
|
27
|
-
- Escalate to the Wizard
|
|
28
|
-
- All agents participate actively at every step. Silence when you have nothing to add is fine — silence when you haven't investigated is laziness.
|
|
26
|
+
- The phases files are a scoreboard, not a chat log. Pin only what survived challenge from at least two agents.
|
|
27
|
+
- Escalate to the Wizard if stuck.
|
|
29
28
|
- This team uses agent teams only. Never delegate to subagents.
|
|
30
29
|
|
|
31
|
-
## Pillar 4:
|
|
30
|
+
## Pillar 4: Sequential Turn-Based Interaction
|
|
32
31
|
|
|
33
|
-
- **
|
|
34
|
-
- **
|
|
35
|
-
- **
|
|
36
|
-
- **
|
|
37
|
-
- **
|
|
38
|
-
- **
|
|
32
|
+
- **One agent works at a time.** When the Wizard dispatches your turn, you are the only active agent. No other agent is working.
|
|
33
|
+
- **Dice roll per phase.** The Wizard rolls dice at the start of each agent phase (Design, Plan, Review, Fix Session). Each phase gets its own turn order. **Exception:** the Implementation phase has no dice roll — the Wizard assigns tasks strategically by file/domain affinity.
|
|
34
|
+
- **Turn flow.** Wizard dispatches `TURN_DISPATCH:` → you work → you send `TURN_COMPLETE:` with summary → Wizard mediates and dispatches next agent.
|
|
35
|
+
- **Round = 3 turns + Wizard synthesis.** After all 3 agents have completed their turn, the Wizard ultrathinks, synthesizes all findings, and pins a round synthesis to the Dungeon.
|
|
36
|
+
- **Minimum 2 rounds, maximum 3 per phase.** The Wizard does not close a phase before round 2 completes.
|
|
37
|
+
- **No direct agent-to-agent messages.** You read the Dungeon to see prior agents' work. You pin your own work to the Dungeon. Communication flows through artifacts and the Wizard's mediation — not through SendMessage between agents.
|
|
38
|
+
- **After** `TURN_COMPLETE:`**, stop completely.** No further work until the Wizard dispatches your next turn. No "while I wait" tasks.
|
|
39
|
+
- **HOLD means freeze.** When the Wizard broadcasts `HOLD`, all agents stop immediately. No work in flight while the Wizard is presenting decisions to the human.
|
|
40
|
+
- **Wizard mediates every round.** The Wizard is not passive — they ultrathink, synthesize, and set direction between every round.
|
|
41
|
+
- **Exception: only the Wizard can interrupt** an agent mid-turn.
|
|
42
|
+
|
|
43
|
+
## Writer / Reviewer / Defend-Concede Protocol
|
|
44
|
+
|
|
45
|
+
Phases that produce documents (Design, Plan, Review) follow a structured pattern. All work happens in the phase file at `phases/phase-N-{name}.md`. The Wizard extracts the polished deliverable to `spoils/` at phase close.
|
|
46
|
+
|
|
47
|
+
- **Round 1:** The first agent in the turn order **writes** the initial document in the "Version 1" section. The second agent **reviews** and pins findings in the "Review — Round 1" section. The third agent reviews both and adds their own findings.
|
|
48
|
+
- **Round 2:** The original writer reads all review findings and responds to **each one** with either:
|
|
49
|
+
- `DEFEND:` — the finding is incorrect or does not apply. Provide counter-evidence.
|
|
50
|
+
- `CONCEDE:` — the finding is valid. Commit to addressing it in the next version.
|
|
51
|
+
- **Silent ignoring is not allowed.** Every finding must get an explicit response.
|
|
52
|
+
- The writer then produces Version 2 in the "Version 2" section incorporating all concessions. Reviewers review again.
|
|
53
|
+
- **Round 3 (if needed):** Same cycle. The Wizard tells agents this is the FINAL round — make every move count.
|
|
54
|
+
|
|
55
|
+
After the final round, the Wizard extracts and polishes the final deliverable from `phases/` into `spoils/`.
|
|
56
|
+
|
|
57
|
+
### Signing
|
|
58
|
+
|
|
59
|
+
Every section, finding, review, defense, and concession must be signed with the agent's identity and round number. Format: `@warrior [R1]`, `@archer [R2]`, `@rogue [R1]`. Just by reading the document, anyone can see who wrote what and when.
|
|
39
60
|
|
|
40
61
|
## Pillar 5: Question Chain
|
|
41
62
|
|
|
@@ -77,63 +98,66 @@ Efficiency matters. Say what you found, what it means, and what should happen. N
|
|
|
77
98
|
|
|
78
99
|
All 4 agents always participate. The full party is Wizard + Warrior + Archer + Rogue. Maximum effort on every quest.
|
|
79
100
|
|
|
80
|
-
### When the Wizard
|
|
81
|
-
|
|
82
|
-
The Wizard dispatches with angles and goes silent. You own the phase from here:
|
|
101
|
+
### When the Wizard Dispatches Your Turn
|
|
83
102
|
|
|
84
|
-
|
|
85
|
-
2. Read the Dungeon for any prior phase knowledge (archived Dungeons).
|
|
86
|
-
3. Explore deeply using your unique lens (see your agent definition).
|
|
87
|
-
4. Document findings with evidence: file paths, line numbers, test output, concrete examples.
|
|
88
|
-
5. Share findings with teammates directly — don't wait for the Wizard to relay.
|
|
89
|
-
6. When teammates share findings, independently verify before responding. Read the code yourself. Then engage — challenge, extend, or confirm with your own evidence.
|
|
90
|
-
7. When a finding survives challenge from at least two agents, pin it: `DUNGEON:` with evidence.
|
|
103
|
+
The Wizard dispatches you with `TURN_DISPATCH:` and your assigned angle. You are the only active agent. The dispatch includes phase-specific context: your role (writer or reviewer), coverage areas, quality criteria, and where to read/write.
|
|
91
104
|
|
|
92
|
-
|
|
105
|
+
1. Read the current phase file in `phases/` for prior agents' work this round.
|
|
106
|
+
2. Read deliverables in `spoils/` inherited from prior phases (PRD, design doc, plan tasks).
|
|
107
|
+
3. Work your assigned angle using your unique lens (see your agent definition).
|
|
108
|
+
4. **Follow the dispatch instructions** — they tell you what to cover and where to write.
|
|
109
|
+
5. Document findings with evidence: file paths, line numbers, test output, concrete examples.
|
|
110
|
+
6. **Sign all work** with your identity and round: `@warrior [R1] FINDING: ...`
|
|
111
|
+
7. If a prior agent's finding needs challenging, pin counter-evidence: `@rogue [R1] CHALLENGE: @warrior's finding at X:Y — my investigation shows...`
|
|
112
|
+
8. Signal `TURN_COMPLETE:` to the Wizard with a brief summary. **Stop all work.**
|
|
93
113
|
|
|
94
|
-
|
|
114
|
+
### Between-Turn Knowledge
|
|
95
115
|
|
|
96
|
-
|
|
116
|
+
You read teammates' work in the Dungeon. You do not message them during your turn. Your challenges, building, and concessions happen through Dungeon pins, not direct conversation. The Dungeon is both the scoreboard AND the communication channel between agents.
|
|
97
117
|
|
|
98
|
-
**
|
|
118
|
+
**The independent verification rule (Pillar 1) applies here:** before responding to any prior agent's finding, independently investigate the same area. Read the actual code. Form your own conclusion. Then pin your response with your own evidence.
|
|
99
119
|
|
|
100
|
-
**
|
|
120
|
+
**Challenging:** When your independent verification contradicts a prior agent's finding, pin what you found with your evidence and explain the discrepancy.
|
|
101
121
|
|
|
102
|
-
**
|
|
122
|
+
**Building:** When your verification confirms and deepens a prior agent's finding, pin the extension through your unique lens.
|
|
103
123
|
|
|
104
|
-
**
|
|
124
|
+
**Conceding:** When a prior agent's challenge of your work holds up — acknowledge it in your pins and redirect your energy into the next angle.
|
|
105
125
|
|
|
106
126
|
### Communication Signals
|
|
107
127
|
|
|
108
128
|
Lead with the conclusion, follow with the evidence.
|
|
109
129
|
|
|
110
130
|
- `FINDING:` — something you discovered with your own evidence
|
|
111
|
-
- `CHALLENGE:` — you independently verified a
|
|
112
|
-
- `BUILDING:` — you independently verified a
|
|
113
|
-
- `
|
|
114
|
-
- `
|
|
131
|
+
- `CHALLENGE:` — you independently verified a prior agent's claim and found a problem
|
|
132
|
+
- `BUILDING:` — you independently verified a prior agent's claim and it goes deeper
|
|
133
|
+
- `DEFEND:` — a reviewer challenged your work and you have counter-evidence showing your approach is correct
|
|
134
|
+
- `CONCEDE:` — a reviewer challenged your work and they are right. Acknowledge and commit to fix.
|
|
135
|
+
- `DUNGEON:` — pinning a finding that survived challenge from at least two agents across turns
|
|
115
136
|
- `WIZARD:` — you need project-level context or are genuinely stuck
|
|
116
|
-
- `
|
|
137
|
+
- `TURN_COMPLETE:` — finished your turn. **Stop all work. Wait for Wizard dispatch.**
|
|
138
|
+
- `TURN_DISPATCH:` — (from Wizard only) starts your turn with angle and context
|
|
139
|
+
- `HOLD` — (from Wizard only) freeze immediately. No work in flight.
|
|
117
140
|
- `BLACKCARD:` — high-concern finding that breaks the architecture
|
|
118
141
|
|
|
119
142
|
### Team Communication
|
|
120
143
|
|
|
121
|
-
You are a team member. Your teammates are in separate tmux panes.
|
|
144
|
+
You are a team member. Your teammates are in separate tmux panes but you do not message them directly.
|
|
122
145
|
|
|
123
|
-
- `SendMessage(to="wizard", message="...")` — escalate
|
|
124
|
-
- `SendMessage(to="
|
|
146
|
+
- `SendMessage(to="wizard", message="WIZARD: ...")` — escalate during your turn
|
|
147
|
+
- `SendMessage(to="wizard", message="TURN_COMPLETE: ...")` — signal turn completion
|
|
125
148
|
|
|
126
|
-
|
|
149
|
+
Agents do NOT use SendMessage to each other. All inter-agent communication flows through Dungeon pins. You read what prior agents pinned, and you pin your own work for subsequent agents to read.
|
|
127
150
|
|
|
128
151
|
**Discovering teammates:** Read the team config at `~/.claude/teams/{team_name}/config.json` to see your teammates' names.
|
|
129
152
|
|
|
130
153
|
**Task coordination:**
|
|
154
|
+
|
|
131
155
|
- `TaskCreate(subject="...", description="...")` — create a new task for discovered work
|
|
132
156
|
- `TaskUpdate(taskId="...", owner="<your-name>")` — claim a task
|
|
133
157
|
- `TaskUpdate(taskId="...", status="completed")` — mark a task done
|
|
134
158
|
- Check `TaskList` after completing each task to find next available work
|
|
135
159
|
|
|
136
|
-
**The Dungeon is
|
|
160
|
+
**The Dungeon is your shared artifact AND communication channel.** Pin findings via Write tool. Sign pins with your agent identity and round (e.g., `@warrior [R1]`) so subsequent agents can quickly identify what's new and who wrote it.
|
|
137
161
|
|
|
138
162
|
### User Direct Access
|
|
139
163
|
|
|
@@ -145,58 +169,63 @@ SendMessage(to="wizard", message="User directed me to [X]. Proceeding.")
|
|
|
145
169
|
|
|
146
170
|
## The Dungeon
|
|
147
171
|
|
|
148
|
-
The Dungeon is the quest
|
|
172
|
+
The Dungeon is the quest directory at `.claude/dungeon/{quest-slug}/`. It has two subdirectories:
|
|
173
|
+
|
|
174
|
+
- **`phases/`** — Evolution logs (scoreboards). This is where rounds happen. Writers write versions, reviewers pin findings, defenders respond. One file per phase (e.g., `phases/phase-2-design.md`).
|
|
175
|
+
- **`spoils/`** — Polished deliverables. After the Wizard closes a phase, the final output is extracted here (e.g., `spoils/design.md`, `spoils/prd.md`). Task files go in `spoils/tasks/`.
|
|
149
176
|
|
|
150
|
-
|
|
177
|
+
**Agents write to `phases/`.** The Wizard extracts polished deliverables to `spoils/` at phase close.
|
|
178
|
+
|
|
179
|
+
### Phase File Structure
|
|
151
180
|
|
|
152
181
|
```markdown
|
|
153
|
-
#
|
|
182
|
+
# Phase N: <Phase Name>
|
|
154
183
|
## Quest: <task description>
|
|
155
|
-
## Quest Type: <Canonical Quest>
|
|
156
|
-
|
|
157
|
-
### Discoveries
|
|
158
|
-
<!-- Verified findings that survived challenge, tagged with agent name -->
|
|
159
184
|
|
|
160
|
-
###
|
|
161
|
-
<!--
|
|
185
|
+
### Version 1
|
|
186
|
+
<!-- Agent 1 writes initial document here, signed @name [R1] -->
|
|
162
187
|
|
|
163
|
-
###
|
|
164
|
-
<!--
|
|
188
|
+
### Review — Round 1
|
|
189
|
+
<!-- Agent 2 and 3 pin findings here, signed @name [R1] -->
|
|
165
190
|
|
|
166
|
-
###
|
|
167
|
-
<!--
|
|
191
|
+
### Version 2
|
|
192
|
+
<!-- Agent 1 writes V2 with DEFEND/CONCEDE responses, signed @name [R2] -->
|
|
168
193
|
|
|
169
|
-
###
|
|
170
|
-
<!--
|
|
194
|
+
### Review — Round 2
|
|
195
|
+
<!-- Agents review V2, signed @name [R2] -->
|
|
171
196
|
```
|
|
172
197
|
|
|
173
198
|
### Curation Rules
|
|
174
199
|
|
|
175
|
-
**What goes
|
|
176
|
-
-
|
|
177
|
-
-
|
|
178
|
-
-
|
|
179
|
-
-
|
|
200
|
+
**What goes in phase files:**
|
|
201
|
+
- Versioned work (V1, V2, V3) by the writer
|
|
202
|
+
- Review findings by reviewers, signed and evidenced
|
|
203
|
+
- DEFEND/CONCEDE responses with reasoning
|
|
204
|
+
- Wizard round syntheses between rounds
|
|
180
205
|
|
|
181
206
|
**What stays in conversation only:**
|
|
182
|
-
- Back-and-forth of challenges
|
|
183
207
|
- Exploratory thinking and hypotheses
|
|
184
|
-
-
|
|
208
|
+
- Back-and-forth before a finding is pinned
|
|
185
209
|
|
|
186
|
-
**The
|
|
210
|
+
**The phase file is both the scoreboard and the communication channel.** Agents pin findings for subsequent agents to read. Sign all work with agent identity and round (e.g., `@archer [R2]`).
|
|
187
211
|
|
|
188
|
-
|
|
212
|
+
### Reading Prior Work
|
|
213
|
+
|
|
214
|
+
- **Same phase:** Read `phases/phase-N-{name}.md` to see prior agents' work this phase.
|
|
215
|
+
- **Prior phases:** Read deliverables in `spoils/` (e.g., `spoils/design.md`, `spoils/prd.md`) and evolution logs in `phases/` for full context.
|
|
216
|
+
- Each phase inherits deliverables from all prior phases. The Wizard recaps the full quest history at the opening of each phase.
|
|
189
217
|
|
|
190
218
|
### When to Escalate to Wizard
|
|
191
219
|
|
|
192
220
|
**Do escalate:**
|
|
221
|
+
|
|
193
222
|
- 2+ agents stuck on same disagreement for 3+ exchanges with no new evidence
|
|
194
223
|
- Uncertain about project-level context (user requirements, constraints, priorities)
|
|
195
224
|
- Team needs a direction-setting decision that affects the quest
|
|
196
225
|
- Found something that may require human input
|
|
197
226
|
|
|
198
227
|
**Don't escalate:**
|
|
228
|
+
|
|
199
229
|
- You can resolve it by reading the code
|
|
200
230
|
- Another agent already answered your question
|
|
201
|
-
- It's a matter of opinion that doesn't affect the outcome
|
|
202
|
-
- You're stuck but haven't tried talking to the other agents first
|
|
231
|
+
- It's a matter of opinion that doesn't affect the outcome
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: raid-browser
|
|
3
|
-
description: "
|
|
3
|
+
description: "Use when browser testing infrastructure is needed — startup discovery, boot/cleanup lifecycle, port isolation, pre-flight checks. Required before raid-browser-chrome or Playwright browser tasks."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Raid Browser — Core Orchestration
|
|
@@ -167,12 +167,10 @@ If cleanup fails:
|
|
|
167
167
|
|
|
168
168
|
Read `portRange` from `raid.json` (e.g., `[3001, 3005]`).
|
|
169
169
|
|
|
170
|
-
|
|
|
170
|
+
| Phase | Agents | Port Assignment |
|
|
171
171
|
|---|---|---|
|
|
172
|
-
|
|
|
173
|
-
|
|
|
174
|
-
| Skirmish | 2 agents | portRange[0], portRange[0]+1 |
|
|
175
|
-
| Scout | 1 agent | portRange[0] |
|
|
172
|
+
| Implementation (per task) | 1 implementer | portRange[0] |
|
|
173
|
+
| Review | 3 reviewers (sequential turns) | portRange[0], portRange[0]+1, portRange[0]+2 |
|
|
176
174
|
|
|
177
175
|
## When Startup Recipe Fails
|
|
178
176
|
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: raid-browser-chrome
|
|
3
|
-
description: "
|
|
3
|
+
description: "Use when live Chrome browser inspection is needed during Phase 5 review or ad-hoc browser verification."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Raid Browser Chrome — Live Adversarial Inspection
|
|
@@ -8,7 +8,7 @@ description: "Claude-in-Chrome live adversarial browser inspection. Angle-driven
|
|
|
8
8
|
Challengers open a real Chrome browser and do adversarial exploratory testing. Each challenger gets their own isolated app instance. Find what automated tests missed.
|
|
9
9
|
|
|
10
10
|
<HARD-GATE>
|
|
11
|
-
Do NOT start inspection without invoking `raid-browser` pre-flight first. Do NOT skip minimum coverage gates. Do NOT share browser instances between agents. Every finding MUST include evidence (GIF, screenshot, console/network output).
|
|
11
|
+
Do NOT start inspection without invoking `raid-browser` pre-flight first. Do NOT skip minimum coverage gates. Do NOT share browser instances between agents. Every finding MUST include evidence (GIF, screenshot, console/network output).
|
|
12
12
|
</HARD-GATE>
|
|
13
13
|
|
|
14
14
|
## Session Lifecycle Per Challenger
|