claude-raid 0.1.0

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

@@ -0,0 +1,147 @@
+---
+name: raid-tdd
+description: "Use during implementation. Enforces strict RED-GREEN-REFACTOR. No production code without a failing test first. Challengers attack test quality. No subagents."
+---
+
+# Raid TDD — Test-Driven Development
+
+Write the test first. Watch it fail. Write minimal code to pass. Then the others try to break it.
+
+**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.
+
+**Violating the letter of these rules is violating their spirit.**
+
+**TDD is enforced in ALL modes — Full Raid, Skirmish, and Scout. No exceptions.**
+
+## The Iron Law
+
+```
+NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+```
+
+Write code before the test? Delete it. Start over. No exceptions.
+- Don't keep it as "reference"
+- Don't "adapt" it while writing tests
+- Don't look at it
+- Delete means delete
+
+## Process Flow
+
+```dot
+digraph tdd {
+  "Write one failing test" -> "Run test";
+  "Run test" -> "Fails correctly?" [shape=diamond];
+  "Fails correctly?" -> "Write one failing test" [label="error, not failure — fix test"];
+  "Fails correctly?" -> "Write minimal code to pass" [label="yes, fails for right reason"];
+  "Write minimal code to pass" -> "Run test";
+  "Run test" -> "Passes?" [shape=diamond];
+  "Passes?" -> "Write minimal code to pass" [label="no"];
+  "Passes?" -> "Run FULL test suite" [label="yes"];
+  "Run FULL test suite" -> "All pass?" [shape=diamond];
+  "All pass?" -> "Fix regression" [label="no"];
+  "Fix regression" -> "Run FULL test suite";
+  "All pass?" -> "Refactor (optional)" [label="yes"];
+  "Refactor (optional)" -> "Run FULL test suite";
+  "Run FULL test suite" -> "Adversarial test review (challengers)" [label="green"];
+  "Adversarial test review (challengers)" -> "Next behavior" [shape=doublecircle];
+}
+```
+
+## Red-Green-Refactor
+
+### RED — Write Failing Test
+- One test, one behavior. "And" in the name? Split it.
+- Clear name describing the behavior, not the implementation
+- Real code, no mocks unless absolutely unavoidable
+- Good: `test_expired_token_returns_401`
+- Bad: `test_auth`, `test1`, `test_the_function`
+
+### Verify RED — Watch It Fail (MANDATORY. Never skip.)
+Run: test command from `.claude/raid.json`
+- Test **fails** (not errors — fails). A test that errors proves nothing.
+- Failure message matches your expectation
+- Fails because the feature is missing, not because of typos or import errors
+
+### GREEN — Minimal Code
+- Simplest code that makes the test pass. Nothing more.
+- No extra features, options, configurations
+- "Can I make it pass with less code?" — if yes, do that instead
+
+### Verify GREEN — Watch It Pass (MANDATORY.)
+Run: test command from `.claude/raid.json`
+- New test passes
+- ALL existing tests still pass
+- Output clean — no warnings, no deprecation notices
+
+### REFACTOR — Clean Up (only after green)
+- Remove duplication, improve names, extract helpers
+- Keep tests green throughout — run after every change
+- Refactor the TESTS too, not just the implementation
+
+## Adversarial Test Review
+
+After TDD cycle, challengers attack the TESTS directly — and build on each other's critiques:
+
+1. **Does this test prove the behavior, or just confirm the implementation?** If you renamed an internal method, would the test break? It shouldn't.
+2. **What input would make this test pass even with a broken implementation?** (e.g., a test that only checks the happy path passes for any implementation that doesn't crash)
+3. **What edge cases are uncovered?** Empty input, null, boundary values, Unicode, concurrent access.
+4. **Is it testing real code or mock behavior?** Mocks that don't match real behavior = false confidence.
+5. **Would this catch a regression?** If someone changes the implementation next month, does this test catch the break?
+
+**Challengers interact directly:**
+- `⚔️ CHALLENGE: @Warrior, your test at line 15 only validates the happy path — here's an input that passes with a broken implementation: ...`
+- `🔗 BUILDING ON @Archer: Your edge case finding — the same gap exists in the error path test at line 32...`
+- `🔥 ROAST: @Rogue, you claimed the test is implementation-dependent but renaming the internal method doesn't break it — here's proof: ...`
+
+**Challengers don't just report to the Wizard — they fight each other over test quality.**
+
+## Testing Anti-Patterns
+
+| Anti-Pattern | Problem | Fix |
+|---|---|---|
+| Testing mock behavior, not real behavior | Mocks pass, production breaks | Use real implementations. Mock only external services. |
+| Test-only methods in production code | Production API polluted for tests | Test through the public interface. If you can't, the design is wrong. |
+| Mocking without understanding the real behavior | Mock returns "success" but real service returns different shape | Read the real implementation before mocking. |
+| Incomplete mocks | Mock covers happy path, misses errors | Mock all paths, or don't mock at all. |
+| Integration tests as afterthought | Unit tests pass, integration breaks | Write integration tests as part of TDD, not after. |
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "Too simple to test" | Simple code breaks. Test takes 30 seconds. Write it. |
+| "I'll test after" | Tests passing immediately prove nothing about the design. |
+| "Need to explore first" | Fine. Throw away exploration code. Start fresh with TDD. |
+| "Test hard = skip it" | Hard to test = hard to use. Fix the design. |
+| "TDD slows me down" | TDD is faster than debugging. Every time. |
+| "Tests after achieve same goals" | Tests-after = "what does this code do?" Tests-first = "what should this code do?" |
+| "Keep the code as reference" | You'll "adapt" it. That's testing after with extra steps. Delete means delete. |
+| "Just this once" | Every exception is a precedent. Delete the code. Start with TDD. |
+| "Already manually tested" | Manual testing leaves no record, can't be re-run, can't catch regressions. |
+| "TDD is dogmatic" | TDD is evidence-based discipline. Dogma would skip the evidence. |
+
+## Verification Checklist
+
+Before claiming a TDD cycle is complete:
+
+- [ ] Every new function has a test
+- [ ] Watched each test fail before implementing
+- [ ] Each test failed for the expected reason (not errors)
+- [ ] Wrote minimal code to pass (no over-engineering)
+- [ ] All tests pass (new and existing)
+- [ ] Output clean (no warnings)
+- [ ] Tests use real code (minimal mocking)
+- [ ] Edge cases and error paths covered
+- [ ] Tests describe behavior, not implementation
+
+Can't check all boxes? Don't proceed. Fix what's missing.
+
+## When You're Stuck
+
+| Situation | Action |
+|-----------|--------|
+| Can't write the test | The requirement is unclear. Ask the Wizard. |
+| Test won't fail | You may already have the implementation. Delete it. Write test. Watch it fail. |
+| Test fails but for wrong reason | Fix the test setup, not the implementation. |
+| Can't make it pass with minimal code | The design may be wrong. Discuss before forcing. |
+| Tests are brittle (break on refactor) | Tests are testing implementation, not behavior. Rewrite them. |

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

@@ -0,0 +1,113 @@
+---
+name: raid-verification
+description: "Use before claiming any work is complete, fixed, or passing. No completion claims without fresh verification evidence. Challengers verify independently. No subagents."
+---
+
+# Raid Verification — Evidence Before Claims
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating its spirit.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command THIS turn, you cannot claim it passes.
+
+## Mode Behavior
+
+- **Full Raid**: Triple verification — implementer + 2 challengers verify independently.
+- **Skirmish**: Double verification — implementer + 1 challenger.
+- **Scout**: Single verification + Wizard confirms.
+
+## The Gate Function
+
+```
+BEFORE claiming any status:
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+   Use test command from .claude/raid.json
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   If NO → state actual status with evidence
+   If YES → state claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+This gate applies to EVERY status claim: "tests pass", "bug fixed", "feature complete", "regression resolved", "no issues found."
+
+## Common Failures
+
+| Claim | Requires | NOT Sufficient |
+|-------|----------|----------------|
+| "Tests pass" | Test command output: 0 failures | Previous run, "should pass", changed code without re-running |
+| "Bug fixed" | Reproduce original symptom: now passes | Code changed, assumed fixed |
+| "No regressions" | Full test suite: all pass | Running only new tests |
+| "Feature complete" | All acceptance criteria verified with evidence | Self-assessment without running tests |
+| "Regression test works" | Red-green cycle verified | Test passes once without seeing it fail |
+
+## Forbidden Phrases Without Evidence
+
+These phrases are NEVER allowed without preceding verification output:
+
+- "Done", "Complete", "Fixed", "Working", "Passing"
+- "Should work", "Probably fine", "Looks correct"
+- "Great!", "Perfect!", "All good!"
+
+Replace with: `[command] output shows [evidence]. [Claim].`
+
+Example:
+- Bad: "Tests pass."
+- Good: "`npm test` output: 31 passing, 0 failing. Tests pass."
+
+## Raid Triple Verification
+
+The implementer's claim is NOT sufficient. Challengers verify AND cross-check each other:
+
+1. **Implementer verifies** — runs tests, reports with evidence (command + output)
+2. **Challenger 1 verifies independently** — runs same tests, confirms output matches
+3. **Challenger 2 verifies adversarially** — runs tests PLUS tries to break it with edge cases
+4. **Challengers cross-check each other:** `@Archer, you said tests pass but did you run the full suite or just the changed files?` / `🔗 BUILDING ON @Warrior: Your verification missed the integration test at...`
+
+Only after all required verifications confirm — and challengers have cross-checked each other — does the Wizard accept.
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification. "Should" is not evidence. |
+| "I'm confident" | Confidence ≠ evidence. Confident people ship bugs too. |
+| "Just this once" | Every "just this once" is a bug waiting to ship. No exceptions. |
+| "Agent said success" | Verify independently. Reports lie — run the command yourself. |
+| "Partial check is enough" | Partial verification proves nothing about the whole. Run the full suite. |
+| "Different words so rule doesn't apply" | Spirit over letter. If you're claiming status without evidence, you're violating this. |
+| "I already verified earlier" | Earlier is not now. Code may have changed. Fresh run required. |
+
+## Red Flags
+
+| Thought | Reality |
+|---------|---------|
+| "I just ran the tests, they should still pass" | "Should" is not evidence. Run again. |
+| "The fix is obvious, it definitely works" | Obvious fixes break in non-obvious ways. Verify. |
+| "I don't need to verify a one-line change" | One-line changes cause production outages. Verify. |
+| Expressing satisfaction before verification | Satisfaction is not evidence. Run the command first. |
+| "Let me just commit and verify after" | Committing before verification = shipping unverified code. |
+
+## Why This Matters
+
+From real-world failure patterns:
+- Undefined functions shipped because "tests pass" was claimed without running
+- Missing requirements deployed because "feature complete" was asserted without checking spec
+- Hours wasted because "fixed" was reported without reproducing the original bug
+- Trust broken because claims weren't backed by evidence
+
+Every one of these was avoidable with: run the command, read the output, THEN claim.
+
+Run the command. Read the output. THEN claim the result. Non-negotiable.