claude-raid 0.1.6 → 0.2.1

package/template/.claude/hooks/raid-teammate-idle.sh

@@ -1,28 +0,0 @@
-#!/usr/bin/env bash
-# Raid lifecycle hook: TeammateIdle
-# Nudges idle agents to pick up unclaimed tasks.
-set -euo pipefail
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-source "$SCRIPT_DIR/raid-lib.sh"
-
-if [ "$RAID_ACTIVE" != "true" ]; then
-  exit 0
-fi
-
-if [ "$RAID_LIFECYCLE_NUDGE" != "true" ]; then
-  exit 0
-fi
-
-raid_read_lifecycle_input
-TEAMMATE=$(echo "$RAID_HOOK_INPUT" | jq -r '.teammate_name // "Agent"')
-
-cat <<ENDJSON
-{
-  "hookSpecificOutput": {
-    "hookEventName": "TeammateIdle",
-    "additionalContext": "$TEAMMATE: Unclaimed tasks remain on the board. Pick up the next available task and report your plan before starting."
-  }
-}
-ENDJSON
-exit 0

package/template/.claude/raid-rules.md

@@ -1,30 +0,0 @@
-# Raid Team Rules
-
-Three pillars. Non-negotiable. Every agent, every phase, every interaction.
-
-## Pillar 1: Intellectual Honesty
-
-- Every claim has evidence you gathered yourself. No exceptions.
-- If you haven't read the code or run the command this turn, you don't know what it says.
-- If you don't know, say so. Guessing is worse than silence.
-- Never respond to a finding you haven't independently verified. Read the code. Run the test. Form your own conclusion first. Then respond — with your evidence, not theirs.
-- "Reports lie" — including your own from prior turns. Verify fresh.
-- Never fabricate evidence, certainty, or findings.
-
-## Pillar 2: Zero Ego Collaboration
-
-- When proven wrong, concede instantly. No face to save — only the output matters.
-- Defend with evidence, never with authority or repetition.
-- A teammate catching your mistake is a gift. Absorb the lesson, carry it forward.
-- Share findings immediately. Hoarding information serves ego, not quality.
-- Build on each other's work genuinely. The best findings come from combining perspectives — Warrior's stress test sharpened by Archer's pattern analysis weaponized by Rogue's attack scenario.
-
-## Pillar 3: Discipline and Efficiency
-
-- Maximum effort on every task. No coasting, no rubber-stamping, no going through motions.
-- Every interaction carries work forward. If you're not adding new information or evidence, stop talking.
-- The Dungeon is a scoreboard, not a chat log. Pin only what survived challenge from at least two agents.
-- Agents talk directly to each other. The Wizard is not a relay.
-- Escalate to the Wizard only after you've tried to resolve it by reading code and discussing with teammates.
-- All agents participate actively at every step. Silence when you have nothing to add is fine — silence when you haven't investigated is laziness.
-- This team uses agent teams only. Never delegate to subagents.

package/template/.claude/skills/raid-browser-playwright/SKILL.md

@@ -1,163 +0,0 @@
----
-name: raid-browser-playwright
-description: "Playwright MCP automated browser test authoring. Extends TDD RED-GREEN-REFACTOR with .spec.ts files. Console + network assertions mandatory. Invoked from raid-tdd and raid-implementation during Phase 3."
----
-
-# Raid Browser Playwright — Automated Test Authoring
-
-Write browser tests as part of TDD. Use Playwright MCP to explore, then encode verified interactions into durable `.spec.ts` files.
-
-<HARD-GATE>
-Do NOT write browser tests without invoking `raid-browser` pre-flight first. Do NOT skip console/network assertions. Do NOT write tests without watching them fail first (TDD RED step). No subagents.
-</HARD-GATE>
-
-## When to Write Browser Tests vs Unit Tests
-
-Not every task needs a browser test. The implementer decides and states reasoning. Challengers attack this decision.
-
-| Write Browser Test | Write Unit Test Only |
-|---|---|
-| New user-facing flow (signup, checkout) | Pure utility function |
-| UI interaction (drag-drop, modal, form) | API endpoint logic |
-| Client-side routing / navigation | Data transformation |
-| Visual state changes (loading, error, empty) | Business rule validation |
-| Integration between frontend and API | Database queries |
-
-**If unsure:** Write the browser test. It's easier to remove an unnecessary test than to find a bug in production.
-
-## Browser TDD Cycle
-
-### RED (browser)
-
-1. Write Playwright test file: `tests/e2e/<feature>.spec.ts`
-2. Test describes **user behavior**, not implementation:
-   - Navigate to page
-   - Interact (click, type, select, drag)
-   - Assert visible outcome (text appears, redirect happens, element state changes)
-3. Include mandatory infrastructure assertions (see below)
-4. Run test → **MUST fail**
-5. Verify it fails for the **RIGHT reason** (page/element missing — not test syntax error)
-
-### GREEN (browser)
-
-1. Implement the feature code
-2. Run Playwright test → **MUST pass**
-3. Run full test suite (unit + browser) → all green
-
-### REFACTOR
-
-1. Clean up implementation and test code
-2. Re-run all tests → still green
-
-## Using Playwright MCP During Test Authoring
-
-While writing the test, the implementer explores interactively to understand the current state and find correct selectors:
-
-| Tool | Purpose |
-|---|---|
-| `browser_navigate` | Load the page, see what's there |
-| `browser_snapshot` | Get DOM state, find correct selectors |
-| `browser_click` / `browser_fill_form` | Test interactions manually first |
-| `browser_console_messages` | Check for errors during interaction |
-| `browser_network_requests` | Verify API calls, check payloads |
-| `browser_take_screenshot` | Capture visual state for evidence |
-
-**The MCP tools are the exploratory scratchpad. The `.spec.ts` file is the durable artifact.**
-
-Encode what you verified interactively into the test file. The test must run headlessly in CI without MCP tools.
-
-## Mandatory Assertions
-
-Every browser test file MUST include at least:
-
-### 1. Console-Clean Assertion
-
-```typescript
-test('no console errors during <feature> flow', async ({ page }) => {
-  const errors: string[] = [];
-  page.on('console', msg => {
-    if (msg.type() === 'error') errors.push(msg.text());
-  });
-
-  // ... perform the feature flow ...
-
-  expect(errors).toEqual([]);
-});
-```
-
-### 2. Network-Health Assertion
-
-```typescript
-test('API calls succeed during <feature> flow', async ({ page }) => {
-  const failures: string[] = [];
-  page.on('response', response => {
-    if (response.status() >= 400) {
-      failures.push(`${response.status()} ${response.url()}`);
-    }
-  });
-
-  // ... perform the feature flow ...
-
-  expect(failures).toEqual([]);
-});
-```
-
-**Missing either of these is an automatic challenge from any reviewer.**
-
-## Selector Best Practices
-
-| Prefer | Avoid | Why |
-|---|---|---|
-| `data-testid="submit-btn"` | `button.btn-primary` | CSS classes change for styling reasons |
-| `getByRole('button', { name: 'Submit' })` | `#submit` | Accessible and resilient |
-| `getByText('Welcome back')` | `.header > div:nth-child(2)` | Structural selectors break on layout changes |
-
-## Challenger Attacks on Browser Tests (Phase 3)
-
-**Warrior attacks:**
-- "You only tested the happy path — what happens with network failure?"
-- "No test for rapid double-submit on the form"
-- "What about a 10,000-character input in the name field?"
-- "You didn't test with JavaScript disabled / slow network"
-
-**Archer attacks:**
-- "Your selector `button[type=submit]` is fragile — use `data-testid`"
-- "No assertion on console errors — the feature works but throws warnings"
-- "Missing network assertion — you don't verify the POST payload"
-- "Tested at desktop width only — what about mobile viewport?"
-
-**Rogue attacks:**
-- "What happens if the user is already logged in and hits /register?"
-- "No test for XSS in the input fields"
-- "What if the API returns 200 but with an error body?"
-- "Race condition: what if the user navigates away during submission?"
-
-**Each challenger BOOTS their own app instance** (on their own port via `raid-browser`), runs the tests independently, and verifies they pass without flakiness.
-
-## Running Browser Tests
-
-Use the test command from `.claude/raid.json`:
-- Read `project.execCommand` (e.g., `pnpm dlx`, `npx`, `bunx`)
-- Run: `{execCommand} playwright test`
-- For a specific test: `{execCommand} playwright test tests/e2e/<feature>.spec.ts`
-
-## Test File Organization
-
-```
-tests/
-  e2e/
-    <feature-name>.spec.ts       # One file per feature/flow
-    auth/
-      login.spec.ts              # Group related flows in directories
-      registration.spec.ts
-```
-
-## Red Flags
-
-| Thought | Reality |
-|---------|---------|
-| "The feature is too simple for a browser test" | Simple features break in the browser. If it's user-facing, test it. |
-| "I'll add console assertions later" | Later never comes. Add them now. |
-| "The unit tests cover this" | Unit tests don't catch hydration mismatches, missing CSS, broken routing. |
-| "I tested it manually with MCP tools" | Manual verification isn't reproducible. Write the `.spec.ts`. |
-| "Selectors are fine, they work" | They work today. Will they work after a CSS refactor? Use `data-testid`. |

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

@@ -1,131 +0,0 @@
----
-name: raid-finishing
-description: "Use after Phase 4 review is approved. Agents debate completeness directly, fighting over what's truly done. Wizard closes with verdict, presents merge options, cleans up Dungeon files and session."
----
-
-# Raid Finishing — Complete the Development Branch
-
-Agents debate completeness directly. Verify. Present options. Execute. Clean up.
-
-**Violating the letter of this process is violating its spirit.**
-
-## Mode Behavior
-
-- **Full Raid**: All 3 agents debate completeness directly. Full verification.
-- **Skirmish**: 1 agent + Wizard verify completeness.
-- **Scout**: Wizard verifies alone.
-
-## Process Flow
-
-```dot
-digraph finishing {
-  "Wizard opens final debate" -> "Agents argue directly: truly done?";
-  "Agents argue directly: truly done?" -> "Any agent says incomplete?" [shape=diamond];
-  "Any agent says incomplete?" -> "Agent presents evidence, others attack" [label="yes"];
-  "Agent presents evidence, others attack" -> "Wizard rules" [shape=diamond];
-  "Wizard rules" -> "Return to Phase 3 or 4" [label="incomplete"];
-  "Wizard rules" -> "Verify all tests pass (fresh run)" [label="complete"];
-  "Any agent says incomplete?" -> "Verify all tests pass (fresh run)" [label="no, all agree"];
-  "Verify all tests pass (fresh run)" -> "Tests pass?" [shape=diamond];
-  "Tests pass?" -> "Fix first. Do not present options." [label="no"];
-  "Fix first. Do not present options." -> "Verify all tests pass (fresh run)";
-  "Tests pass?" -> "Present 4 options" [label="yes"];
-  "Present 4 options" -> "Execute choice";
-  "Execute choice" -> "Clean up: Dungeon files + worktree + raid-session";
-  "Clean up: Dungeon files + worktree + raid-session" -> "Done" [shape=doublecircle];
-}
-```
-
-## Wizard Checklist
-
-1. **Open final debate** — dispatch agents to argue completeness directly
-2. **Observe the fight** — agents challenge each other on what's done vs. missing
-3. **Wizard rules on completeness** — only proceed if ruling is "complete"
-4. **Verify all tests pass** — full suite, fresh run
-5. **Present options** — exactly 4 choices
-6. **Execute choice** — merge, PR, keep, or discard
-7. **Clean up** — remove all Dungeon files (`.claude/raid-dungeon.md`, `.claude/raid-dungeon-phase-*.md`), worktree if applicable, remove `.claude/raid-session`
-
-## Step 1: The Completeness Debate
-
-**DISPATCH:**
-
-> **@Warrior**: Review the implementation against the plan. Is every task completed? Every acceptance criterion met? Every test passing? Is anything half-done? Fight @Archer and @Rogue directly on their assessments.
->
-> **@Archer**: Review the implementation against the design doc. Is every requirement covered? Naming patterns consistent throughout? File structure clean? Did we introduce inconsistencies with the rest of the codebase? Fight @Warrior and @Rogue directly.
->
-> **@Rogue**: Review from the adversarial angle. What did we miss? What edge case is untested? What requirement was subtly misinterpreted? What will break in the first week of production? Fight @Warrior and @Archer directly.
->
-> **All**: Reference ALL archived Dungeons (Phase 1-4) for full context. Debate directly. If you believe the work is incomplete, present evidence. Others challenge your claim. Pin conclusions to conversation (no Dungeon for finishing — this is the final debate).
-
-**The agents must fight over this.** If any agent believes the work is incomplete, they present evidence. The other two challenge that claim directly.
-
-RULING: [Complete — proceed | Incomplete — return to Phase 3/4 with specific issues]
-
-## Step 2: Final Verification
-
-```
-BEFORE presenting options:
-1. IDENTIFY: test command from .claude/raid.json
-2. RUN: Execute the FULL test suite (fresh, complete)
-3. READ: Full output, check exit code, count failures
-4. VERIFY: Zero failures?
-   If NO → STOP. Fix first. Do not present options.
-   If YES → Proceed with evidence.
-```
-
-### Browser Verification (when `browser.enabled` in raid.json)
-
-Additional final checks:
-- Full Playwright test suite passes headlessly
-- Verify no leaked processes from prior browser sessions
-- Verify all ports in `browser.portRange` are free (`lsof -i :PORT`)
-- Agents debate: "Are browser tests sufficient for this feature's coverage?"
-
-## Step 3: Present Options
-
-```
-RULING: Implementation complete and verified.
-
-Tests: [N] passing, 0 failures (evidence: [command output])
-
-Options:
-1. Merge back to [base-branch] locally
-2. Push and create a Pull Request
-3. Keep the branch as-is (handle later)
-4. Discard this work
-
-Which option?
-```
-
-## Step 4: Execute
-
-| Option | Actions |
-|--------|---------|
-| **1. Merge** | Checkout base -> pull -> merge -> run tests on merged result -> delete branch -> clean up |
-| **2. PR** | Push with -u -> create PR via gh -> clean up |
-| **3. Keep** | Report branch location. Done. |
-| **4. Discard** | Require typed "discard" confirmation -> delete branch (force) -> clean up |
-
-## Step 5: Clean Up
-
-Remove ALL Dungeon artifacts:
-- `.claude/raid-dungeon.md` (if exists)
-- `.claude/raid-dungeon-phase-1.md`
-- `.claude/raid-dungeon-phase-2.md`
-- `.claude/raid-dungeon-phase-3.md`
-- `.claude/raid-dungeon-phase-4.md`
-- `.claude/raid-session`
-- Worktree (if applicable)
-
-## Red Flags
-
-| Thought | Reality |
-|---------|---------|
-| "Tests passed earlier, no need to re-run" | Verification Iron Law. Fresh run or no claim. |
-| "The completeness debate is a formality" | It's where missed requirements surface. Take it seriously. |
-| "Let me report to the Wizard whether it's complete" | Debate with the other agents directly. |
-| "Merge without testing the merged result" | Merges introduce conflicts. Always test after merge. |
-| "Leave the Dungeon files, they might be useful" | Clean up. Session artifacts don't belong in the repo. |
-
-**Terminal state:** Choice executed. All Dungeon files removed. `.claude/raid-session` removed. Session over.

package/template/.claude/skills/raid-git-worktrees/SKILL.md

@@ -1,96 +0,0 @@
----
-name: raid-git-worktrees
-description: "Use when starting Raid implementation that needs isolation. Creates isolated git worktree with safety verification and clean test baseline."
----
-
-# Raid Git Worktrees — Isolated Workspaces
-
-Systematic directory selection + safety verification = reliable isolation.
-
-## Process Flow
-
-```dot
-digraph worktree {
-  "Check worktree path from raid.json" -> "Directory exists?";
-  "Directory exists?" -> "Verify gitignored" [label="yes"];
-  "Directory exists?" -> "Create directory" [label="no"];
-  "Create directory" -> "Add to .gitignore + commit";
-  "Add to .gitignore + commit" -> "Verify gitignored";
-  "Verify gitignored" -> "Ignored?" [shape=diamond];
-  "Ignored?" -> "Create worktree" [label="yes"];
-  "Ignored?" -> "Add to .gitignore + commit" [label="no"];
-  "Create worktree" -> "Install dependencies";
-  "Install dependencies" -> "Run baseline tests";
-  "Run baseline tests" -> "Tests pass?" [shape=diamond];
-  "Tests pass?" -> "Report ready" [label="yes", shape=doublecircle];
-  "Tests pass?" -> "Report failures, ask user" [label="no"];
-}
-```
-
-## Directory Selection Priority
-
-1. Check worktrees path from `.claude/raid.json` (default: `.worktrees/`) -> use it (verify ignored)
-2. Check CLAUDE.md for preference -> use it
-3. Ask the user
-
-## Safety Verification
-
-```bash
-# MUST verify directory is gitignored before creating worktree
-git check-ignore -q [worktrees-path] 2>/dev/null
-```
-
-If NOT ignored: add to `.gitignore`, commit immediately, then proceed. Fix broken things immediately — don't leave unignored worktree directories.
-
-## Creation
-
-```bash
-WORKTREE_PATH=$(jq -r '.paths.worktrees // ".worktrees"' .claude/raid.json)
-git worktree add "$WORKTREE_PATH/$BRANCH_NAME" -b "$BRANCH_NAME"
-cd "$WORKTREE_PATH/$BRANCH_NAME"
-
-# Auto-detect and install deps
-[ -f package.json ] && npm install
-[ -f Cargo.toml ] && cargo build
-[ -f requirements.txt ] && pip install -r requirements.txt
-[ -f pyproject.toml ] && poetry install
-[ -f go.mod ] && go mod download
-
-# Verify clean baseline
-TEST_CMD=$(jq -r '.project.testCommand // empty' .claude/raid.json)
-[ -n "$TEST_CMD" ] && eval "$TEST_CMD"
-```
-
-## Report
-
-```
-Worktree ready at [path]
-Branch: [branch-name]
-Tests: [N] passing, 0 failures
-Ready for Raid implementation
-
-Note: Dungeon files (.claude/raid-dungeon*.md) are session artifacts
-and will be cleaned up by raid-finishing. No gitignore needed.
-```
-
-## Quick Reference
-
-| Situation | Action |
-|-----------|--------|
-| `.worktrees/` exists | Use it (verify ignored) |
-| `worktrees/` exists | Use it (verify ignored) |
-| Both exist | Use `.worktrees/` |
-| Neither exists | Check raid.json -> CLAUDE.md -> ask user |
-| Directory not ignored | Add to .gitignore + commit first |
-| Tests fail during baseline | Report failures + ask user before proceeding |
-| No test command configured | Warn, proceed without baseline |
-
-## Red Flags
-
-| Thought | Reality |
-|---------|---------|
-| "I'll add it to .gitignore later" | Fix it now. Worktree dirs must never be committed. |
-| "Baseline tests don't matter" | Failing baseline = you'll waste time debugging pre-existing failures. |
-| "Skip dependency install, it'll be fine" | Missing deps = mysterious failures during implementation. |
-
-**Never** create a worktree without verifying it's gitignored. **Never** skip baseline test verification. **Never** proceed with failing baseline tests without asking.