| name | roll-spar |
| license | MIT |
| model | sonnet |
| allowed-tools | Read, Edit, Write, Bash, Agent, Skill |
| description | Adversarial TDD mode with Attacker/Defender agents. Attacker writes tests to break the system, Defender writes minimal code to pass. Use for high-risk logic like auth, payments, data integrity, or complex state machines. |
Spar
Adversarial TDD: two agents collaborate in attack-and-defend mode to build a more robust system.
When to Use
Manual trigger:
- User explicitly requests
$roll-spar
- Involves core business logic requiring higher quality assurance
Auto trigger (agent judgment): Recommend enabling when any of these conditions are met
- Involves authentication / authorization / security
- Involves money / payments / billing
- Involves data integrity (writes are irreversible)
- Complex state machines / concurrency logic
- Module has had previous bugs (BACKLOG has related FIX records)
Do not use for:
- UI styling adjustments, copy changes
- Simple CRUD
- Configuration changes
- Small tasks not worth the overhead of two-agent collaboration
Roles
Attacker (Red Agent)
Goal: Find weaknesses in the code and write tests that break the system.
- Think about boundary conditions, invalid inputs, concurrency scenarios, state inconsistencies
- Write the trickiest test cases possible
- Don't care about implementation difficulty — only care about "can the system handle this scenario"
- Write at least 1 RED test per round, can write multiple
Defender (Green Agent)
Goal: Make all tests pass with the simplest, most robust code possible.
- Cannot modify tests written by the Attacker (unless the test itself has a bug)
- Aim for minimal implementation, avoid over-engineering
- Make all tests GREEN each round, then commit
- May refactor, but must stay GREEN
Workflow
User: "$roll-spar implement transfer logic" or agent auto-triggers
│
▼
┌─────────────────────────────────────┐
│ 0. Setup │
│ - Define feature scope and AC │
│ - Create test file skeleton │
│ - Context brief for Attacker │
│ and Defender │
└─────────────┬───────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Spar Loop (repeat until converged) │
│ │
│ ┌───────────────────────────────┐ │
│ │ 🔴 Attacker Turn │ │
│ │ - Analyze current code/API │ │
│ │ - Write 1+ RED tests │ │
│ │ - State attack intent: │ │
│ │ "Test balance consistency│ │
│ │ during concurrent │ │
│ │ transfers" │ │
│ └──────────────┬────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────┐ │
│ │ 🟢 Defender Turn │ │
│ │ - Read Attacker's tests │ │
│ │ - Write minimal code to │ │
│ │ make tests pass │ │
│ │ - Run all tests → GREEN │ │
│ │ - git commit │ │
│ └──────────────┬────────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────────────────┐ │
│ │ 🔴 Attacker Turn (again) │ │
│ │ - Review Defender's impl │ │
│ │ - Find new weaknesses, │ │
│ │ write new RED tests │ │
│ │ - Or: "No new weaknesses │ │
│ │ found" │ │
│ └──────────────┬────────────────┘ │
│ │ │
│ ┌────────┴────────┐ │
│ │ │ │
│ Has new tests No new tests │
│ → Continue loop → Exit Spar │
│ │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ Wrap-up │
│ - Attacker summarizes attack │
│ coverage │
│ - Defender summarizes defense │
│ strategy │
│ - Merged report │
│ - Continue normal roll-build │
│ flow │
│ (push → CI → deploy → verify) │
└─────────────────────────────────────┘
Spar Convergence Conditions
Attacker declares completion when any of these are met:
- Cannot write a new RED test for 2 consecutive rounds
- Already covered: happy path + boundary values + invalid inputs + concurrency/race conditions + state consistency
- Reached the agreed maximum number of rounds (default: 5 rounds)
Agent Context Brief
Attacker Brief Template
## Role: Attacker (Red Agent)
Your goal is to find weaknesses in this code.
### Feature Description
{Feature AC and interface definition}
### Current Implementation
{Defender's latest code, or "not yet implemented"}
### Existing Tests
{Currently existing test cases}
### Your Task
Write 1+ new test cases that make the current implementation fail (RED).
Directions to explore:
- Boundary values (0, -1, MAX_INT, empty string, null)
- Exception flows (network disconnect, timeout, duplicate requests)
- Concurrency (two requests arriving simultaneously)
- State consistency (is system state clean after mid-process failure)
### Output Format
For each test, state the attack intent:
"Attack: {scenario description} — expected system behavior: {expected behavior}"
Defender Brief Template
## Role: Defender (Green Agent)
Your goal is to make all tests pass with the simplest implementation.
### Feature Description
{Feature AC and interface definition}
### Current Code
{Your previously written code, or empty}
### New RED Tests
{Tests written by the Attacker this round}
### Your Task
Modify/add code to make all tests (including previous ones) pass.
Rules:
- Cannot modify tests written by the Attacker
- Aim for minimal changes
- Keep the code clear
- Commit after all tests are GREEN
Status Report
Report to the user after each round:
⚔️ Spar Round {N}
🔴 Attacker:
Attack: {scenario 1} — {result}
Attack: {scenario 2} — {result}
🟢 Defender:
Defense strategy: {brief description of how it was defended}
Test status: {passed}/{total} ✅
📊 Cumulative: {total tests} tests, {total rounds} rounds
🔄 Next round: Attacker continues looking for weaknesses...
Hard Rules
- Attacker does not write implementation code — only writes tests and attack analysis
- Defender does not modify tests — unless the test itself has a bug (must explain the reason)
- Must commit each round — Defender commits immediately after making tests GREEN, keeping the repo clean
- Attack intent must be explained — cannot just write tests without explaining "why this scenario matters"
- Maximum round limit — default 5 rounds, prevents infinite loops
Integration with roll-build
Spar replaces steps 4-5 in roll-build (Test Design + TCR Implementation):
roll-build normal flow:
1. Clarify Story
2. Split Actions
3. Define verification
──────────────────────
4. Test Design Review ← Spar replaces this step
5. TCR Implementation ← and this step
──────────────────────
6. Local CI check ← Back to normal flow
7. Quality Review
...
Auto-switching from roll-build to Spar:
When the agent assesses an Action as high-risk at step 3:
⚔️ High-risk Action detected: {description}
Risk factors: {auth/payment/data integrity/...}
Recommend enabling Spar mode — confirm? [Y/n]
After user confirms, enter Spar. Once complete, return to roll-build step 6 to continue.
Example
User: "$roll-spar implement user balance transfer"
⚔️ Spar: User Balance Transfer
── Round 1 ──
🔴 Attacker:
Attack 1: Transfer amount is 0 — should reject
Attack 2: Transfer amount is negative — should reject
Attack 3: Transfer amount exceeds balance — should reject and keep balance unchanged
🟢 Defender:
Implementation: transfer(from, to, amount) basic validation
Tests: 3/3 ✅
commit: "tcr: transfer basic validation"
── Round 2 ──
🔴 Attacker:
Attack 4: Transfer to self — should reject
Attack 5: Two concurrent transfers whose total exceeds balance — only one should succeed
🟢 Defender:
Implementation: add self-transfer check + optimistic lock
Tests: 5/5 ✅
commit: "tcr: transfer self-check and concurrency lock"
── Round 3 ──
🔴 Attacker:
Attack 6: Database error mid-transfer — both balances should remain unchanged (atomicity)
Attack 7: Recipient account does not exist — should reject and keep sender's balance
🟢 Defender:
Implementation: database transaction wrapper + recipient existence check
Tests: 7/7 ✅
commit: "tcr: transfer atomicity and recipient validation"
── Round 4 ──
🔴 Attacker:
No new weaknesses found. Covered: input validation, self-transfer, concurrency, atomicity, related accounts.
⚔️ Spar Complete!
📊 4 rounds, 7 tests, 3 commits
🔴 Attack coverage: input boundaries + business rules + concurrency + atomicity
🟢 Defense strategy: upfront validation + optimistic lock + transactions
