Purple Team

Purple Team

The combined red+blue loop — the outer orchestration the red-team skill says "lives outside it." The artifact is a target system (frozen within a phase, patched between phases); the feedback signal is how many new failure classes a fresh attack pass finds against the patched target. Each cycle runs three strictly separated phases — find (red-team), fix (blue-team), re-verify (a fresh red-team pass) — and you repeat until a fresh find stays dry (zero new classes), meaning the target is hardened. Red and blue run as independent agents so the attacker that wrote a catalogue never grades its own patch. On stop it opens a pull request with the cycle history and the patch set.

When to use

Use to harden a guardrail/classifier/filter/prompt/API the user owns or is authorized to test, when the goal is an actually-hardened target plus a reviewable patch — not just a catalogue (that is red-team alone) and not just closing a pre-existing catalogue (that is blue-team alone). It needs a runnable oracle for the objective signal, and the two sibling skills installed.

Default: spawn red and blue as separate subagents per phase. Escape hatch: on hosts without subagent dispatch, run each phase inline (serial) per the role files — still correct, but the same context plays both sides, so be deliberate about not letting the fix bias the re-verify. Not for unauthorized targets.

Setup

Resolve bindings interactively. If loop.run.yaml exists, load it, confirm the values in one line, and skip to the loop. Otherwise: on Claude Code (the AskUserQuestion tool is available) infer a likely value per binding and recommend it; on other hosts ask each as a quoted prompt. Then write loop.run.yaml (format: examples/run.example.yaml) and confirm before creating any other files.

The phases reuse the sibling skills, so the bindings are their union — one shared loop.run.yaml drives both. The same file is <target_files> to blue (writable) and the program behind <target_cmd> to red (read-only); the same path is red's <failures_log> and blue's <catalogue>.

<skill_dir> is this skill's installed folder. The phases run the sibling skills' tools (red-team/tools/harness.py, blue-team/tools/verify.py); the role files name them.

The loop

Copy this checklist and tick items off each cycle. Cycles are numbered from 0; per-cycle artifacts go in <sandbox_root> with the cycle index in the name so nothing is overwritten: the find catalogue is failures.cycle<N>.jsonl (cycle 0 may use <catalogue> directly) and the re-verify result is failures.cycle<N>_reverify.jsonl. The catalogue blue fixes in cycle N is the failures file from that cycle's find/re-verify pass — never append back into one shared file, so each cycle's accounting is clean.

• Cycle 0 — Find. Run the red-team phase against the frozen target (spawn-or-degrade, roles/red-find.md), writing failures.cycle0.jsonl. Read back its distinct failure classes.
• If the catalogue is empty on cycle 0, stop — the target is already dry; report clean, no PR.
• Fix. Run the blue-team phase on this cycle's failures file (spawn-or-degrade, roles/blue-fix.md): it patches <target_files> one class per iteration under the gate + regression guard, committing kept fixes on <pr_branch>. Read back the classes it closed and any residuals.
• Re-verify. Run a fresh red-team phase against the patched target into failures.cycle<N>_reverify.jsonl. This confirms the closed classes no longer reproduce and surfaces any new classes the fix introduced (e.g. an over-block).
• Append one cycle row to the ledger. If the re-verify pass found new classes, they become the next cycle's catalogue (failures.cycle<N+1>.jsonl) — loop to Find/Fix for cycle N+1. Repeat find→fix→re-verify until a re-verify pass stays dry (no new classes) or <cycle_budget> is hit.
• Handoff. Open the pull request with the full cycle history (see Handoff).

Phase independence (why three separated phases). The target is read-only ground truth for the duration of a red pass, so patches happen only between passes — mutating it mid-pass would break reproducibility and the class accounting. Spawn red and blue as separate subagents so neither grades its own work; the orchestrator only passes artifacts (the catalogue, the closed/residual summary) between them. Launch a phase's subagent and wait for its structured return before the next phase.