Roll Spar

---
name: roll-spar
license: MIT
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

```markdown
## 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

```markdown
## 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

1. **Attacker does not write implementation code** — only writes tests and attack analysis
2. **Defender does not modify tests** — unless the test itself has a bug (must explain the reason)
3. **Must commit each round** — Defender commits immediately after making tests GREEN, keeping the repo clean
4. **Attack intent must be explained** — cannot just write tests without explaining "why this scenario matters"
5. **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
```