| name | battle |
| description | Red vs Blue team security competition orchestrator. Runs long-running overnight battles with 1000s of interactions, scoring, and insight generation.
|
| allowed-tools | ["Bash","Read"] |
| triggers | ["battle","thunderdome","red vs blue","overnight battle","security competition","red team vs blue team"] |
| metadata | {"short-description":"Red vs Blue team security competition","requires":"docker"} |
| provides | ["competitive-selection","docker-isolation"] |
| composes | ["hack","anvil","memory","treesitter","taxonomy","task-monitor","ops-docker","code-runner"] |
| complies | ["best-practices-skills","best-practices-python","best-practices-security"] |
| taxonomy | ["competition","selection","resilience"] |
STOP. READ THIS ENTIRE SKILL.MD BEFORE CALLING ANY ENDPOINT.
Battle Skill
Red vs Blue Team Security Competition Orchestrator
Pits a Red Team (attack) against a Blue Team (defense) in a long-running competitive loop. Each team leverages all .pi/skills to attack or defend a target codebase.
Architecture
Production Battle is an orchestration skill, not a large bespoke security
engine. The host-side process should schedule rounds, choose personas, dispatch
subagents, provision Docker runtimes, collect receipts, score hard runtime
signals, write reports, and persist learning. Target code and team-generated
code must execute only inside Docker.
Required production invariants:
- Red and Blue are subagent teams. Each dispatched subagent must include an
explicit persona selected by the orchestrator for that turn. Multiple personas
per team may run concurrently when the turn benefits from breadth.
- Red-team
$hack execution is a subagent responsibility, not a Battle Python
import. Battle performs or schedules scan/research/memory recall, builds the
candidate exploit list, chooses the Red persona, dispatches an
agent-skills/agents/Tau subagent with that contract, and records the
returned exploit receipt.
- Subagent handoffs and receipts should follow the compact Tau-style JSON
contract shape used by
tau.agent_handoff.v1 and tau.subagent_receipt.v1,
with Battle-specific fields layered on top rather than a separate ad hoc
protocol.
- Battle calls modular Tau subagent contracts. Tau and the loop/agentic harness
own subagent execution and use
scillm as the LLM/model caller. Battle owns
team selection, persona assignment, Docker runtimes, scorekeeping, artifacts,
and memory promotion.
- Model choice is strategic but routed through Tau/loop: SOTA models for
planning, small fast models for high-throughput mutation generation and
triage, specialist models for language/security niches, and batch calls for
broad candidate generation.
- Red and Blue have free research access through approved agent-side research
skills, including
dogpile, brave-search, memory, GitHub/code search,
docs, papers, CVEs, and public writeups.
- All target apps, exploit probes, fuzzers, payloads, repro scripts, patch
builds, tests, migrations, dependency installs, and replay checks run in
Docker. The host is control plane only.
- Docker target runtimes may be rebuilt and relaunched between rounds. Persist
only controlled volumes and artifacts that must survive a rebuild; store
durable strategic context and learnings in
$memory.
- Docker runtimes must support dynamic language/toolchain selection. Any code
language required by the target may be added to the runtime image or selected
adapter; Battle should not hard-code one language.
- Battle should be high-throughput when the target runtime is warm: thousands of
exploit/defense mutations may be attempted with tight 10-15 second Docker
execution windows on capable workstation hardware.
- Battle should use combinatorial mutation. Red tries every plausible exploit
family and combination within safety/time budgets; Blue tries every plausible
patch, hardening, configuration, test, detection, and mitigation combination.
Successful combinations receive stronger promotion than isolated tactics.
- Research may burst concurrently from the agent side. Red and Blue may fan out
multiple
brave-search and dogpile calls, including 10x concurrent Brave
search batches when needed, then store useful results and negative evidence in
$memory.
- Target containers default to no network. External research happens from the
agent side through controlled skills unless a scenario explicitly grants
target-container network access.
- The scorekeeper records objective outcomes: system down, system still up after
the allotted time, exploit success, crash artifacts, patch timing, regression
behavior, resource limits, and replay results. It is not an LLM judge.
Based on research into RvB framework, DARPA AIxCC, and Microsoft PyRIT:
┌─────────────────────────────────────────────────────────┐
│ Battle Orchestrator │
│ - Game loop (RvB pattern) │
│ - Concurrent Red/Blue execution │
│ - Entropy-driven termination │
│ - Checkpointing for overnight runs │
└─────────────────────────────────────────────────────────┘
│ │
┌────┴────┐ ┌────┴────┐
│ Red Team │ │ Blue Team│
│ (Thread) │ │ (Thread) │
├──────────┤ ├──────────┤
│ Skills: │ │ Skills: │
│ - hack │ │ - anvil │
│ - memory │ │ - memory │
└──────────┘ └──────────┘
│ │
└──────────┬───────────────────┘
│
┌───────────────┴────────────────────┐
│ Digital Twin │
│ ┌─────────────────────────────┐ │
│ │ Mode: git_worktree │ │
│ │ - Red attacks arena │ │
│ │ - Blue patches workspace │ │
│ │ - Cherry-pick to test │ │
│ ├─────────────────────────────┤ │
│ │ Mode: docker │ │
│ │ - Isolated containers │ │
│ │ - Battle network │ │
│ ├─────────────────────────────┤ │
│ │ Mode: qemu │ │
│ │ - Emulated firmware │ │
│ │ - GDB attach points │ │
│ └─────────────────────────────┘ │
└────────────────────────────────────┘
Digital Twin Modes
The battle skill supports multiple target types through its Digital Twin system:
1. Source Code (git_worktree)
For battling over git repositories. Creates isolated git worktrees for each team.
./run.sh battle /path/to/repo --rounds 100
2. Docker Container (docker)
For battling over containerized applications. Spins up separate containers for each team.
./run.sh battle --docker-image nginx:latest --rounds 100
./run.sh battle /path/with/Dockerfile --mode docker
3. Firmware/Microprocessor (qemu)
For battling over firmware and embedded systems. Boots firmware in QEMU emulator.
./run.sh battle firmware.elf --rounds 100
./run.sh battle firmware.bin --qemu-machine arm
./run.sh battle firmware.bin --qemu-machine riscv64
./run.sh battle bios.rom --qemu-machine x86_64
Supported QEMU machines:
arm - ARM Cortex-M (STM32, etc.)aarch64 - ARM64riscv32/riscv64 - RISC-Vx86_64/i386 - x86mips - MIPS (routers, embedded)
4. Copy Mode (fallback)
For non-git directories. Creates simple file copies for each team.
Commands
./run.sh battle /path/to/codebase --rounds 10
./run.sh battle /path/to/codebase --overnight
./run.sh battle --docker-image myapp:latest --rounds 100
./run.sh battle firmware.bin --qemu-machine arm --rounds 100
./run.sh status
./run.sh resume <battle-id>
./run.sh report <battle-id>
./run.sh battle-fixture battle-001 --out /tmp/battle-001
./run.sh arena-parent-spawn-proof battle-004 --out /tmp/battle-004-parent-spawn --red-workers 2 --blue-workers 2
Battle v0 Fixture Proof
Battle v0 is a narrow, deterministic proof rung for the Battle artifact contract.
It runs one local Red -> Blue -> Judge fixture and emits replayable receipts:
red-receipt.jsonblue-receipt.jsonjudge/judge-receipt.jsonscoreboard.jsonmonitor-index.jsonrun-receipt.json
The Battle v0 scoreboard is derived from the independent Judge receipt, not from
Blue-side self-certification fields. This addresses the current battle loop gap
where a Blue patch can carry verified and functionality_preserved claims
without a separate Judge phase.
The fixture proof is intentionally limited:
mocked: no
live: local_deterministic_fixture
agentic: false
models_used: []
It proves the receipt boundary and monitor artifact rendering for the local
fixture only. It does not prove real Red or Blue agent behavior, scillm,
OpenCode, anvil, code-runner, memory learning, Docker, QEMU, or multi-round
campaign readiness. See docs/BATTLE_V0.md for the validation commands and
artifact-backed monitor proof path.
Scoring System (AIxCC-style)
| Metric | Weight | Description |
|---|
| Vulnerability Discovery | 1x | Red team finds vulnerability |
| Exploit Proof | +0.5x | Red team proves exploitability |
| Successful Patch | 3x | Blue team patches vulnerability |
| Time Decay | Variable | Faster responses score higher |
| Functionality Preserved | Required | Patches must not break code |
Scores
- TDSR (True Defense Success Rate): Vulnerabilities fixed AND code works
- FDSR (Fake Defense Success Rate): Attack blocked but code broken
- ASC (Attack Success Count): Total unique exploits discovered
Game Loop (Learning-Based)
Each round follows a learn → act → reflect pattern:
Round k:
┌─────────────────────────────────────────────────────────────┐
│ 1. RESEARCH PHASE │
├─────────────────────────────────────────────────────────────┤
│ Red Team: Blue Team: │
│ - Recall past attack attempts - Recall past defenses │
│ - Query /dogpile for new - Query /dogpile for │
│ exploitation techniques hardening strategies │
│ - Review opponent's patterns - Analyze attack evolution │
│ (Budget: 3 research calls max) │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 2. ACTION PHASE │
├─────────────────────────────────────────────────────────────┤
│ Red Team Attack: Blue Team Defense: │
│ - Execute learned strategy - Apply patches via anvil │
│ - AFL++ fuzzing with coverage - Verify via QCOW2 overlay │
│ - Collect crashes/findings - Run regression tests │
│ - Tag findings with /taxonomy - Tag patches with /taxonomy │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 3. REFLECTION PHASE │
├─────────────────────────────────────────────────────────────┤
│ Both Teams: │
│ - Archive round episode (actions, outcomes, learnings) │
│ - Store successful strategies in /memory │
│ - Update belief about opponent's capabilities │
│ - Evolve strategy for next round │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ 4. SCORING & CHECKPOINT │
├─────────────────────────────────────────────────────────────┤
│ - Calculate AIxCC-style scores │
│ - Check termination conditions │
│ - Save checkpoint (QEMU state + team memories) │
└─────────────────────────────────────────────────────────────┘
Memory Architecture
Each team maintains isolated knowledge:
battle_red_<battle_id>/ battle_blue_<battle_id>/
├── strategies/ ├── strategies/
│ ├── successful_attacks │ ├── successful_patches
│ └── failed_attempts │ └── broken_defenses
├── research/ ├── research/
│ └── dogpile_results │ └── dogpile_results
├── episodes/ ├── episodes/
│ ├── round_001.json │ ├── round_001.json
│ └── round_002.json │ └── round_002.json
└── taxonomy/ └── taxonomy/
├── cwe_classifications ├── mitigation_types
└── severity_scores └── effectiveness_scores
Teams cannot access opponent's memory - this creates true adversarial learning.
Termination Conditions
Battle ends when ANY condition is met:
- Null Production: Both teams fail to generate new findings for 3 rounds
- Maximum Rounds: Configured limit reached
- Metric Convergence: Scores stable for 5 consecutive rounds
- Kill Switch: Manual termination via
./run.sh stop
Task Monitor Integration
Battles register with task-monitor for overnight progress tracking:
.pi/skills/task-monitor/run.sh tui --filter battle
Report Output
After battle completion, generates:
- Executive Summary: Winner, key metrics, risk score
- Vulnerability Report: By severity, category, remediation status
- Attack Evolution: How Red team adapted over rounds
- Defense Timeline: Blue team improvements over time
- Recommendations: Prioritized security improvements
Memory + Taxonomy Integration
The skill integrates with the shared memory and taxonomy systems via
memory_integration.py for cross-battle learning:
- Pre-hook (
recall_prior_battles): Before starting a battle, recalls prior
battle findings for the same target or technique. Enables teams to build on
accumulated security knowledge across battles.
- Post-hook (
learn_battle): After battle completes, stores the full outcome
(target, red findings, blue defenses, winner, scores, TDSR) to memory with
taxonomy bridge tags.
- Bridge keywords: Precision, Resilience, Fragility, Corruption, Loyalty, Stealth
(tuned to security/exploitation domain).
- Tags:
["battle", "security"] + bridges
Gracefully degrades if common.memory_client or taxonomy/taxonomy.py are unavailable.
Nondeterministic Exploit Specimen Synthesis
Battle Red agents may behave as nondeterministic exploit-code authors. A Red
exploit subagent may combine high-level web, protocol, MITM, packet, timing,
source-level, binary, assembly, fuzzing, and obscure research-derived
techniques into generated exploit specimens.
Most generated specimens may be bad ideas: they may fail to compile, fail at
runtime, combine irrelevant methods, or produce no useful target signal. Battle
treats those outputs as genetic material, not proof.
Battle owns deterministic selection and evidence:
- generated code must be materialized as an artifact;
- generated code must run only in Docker;
- stdout, stderr, HTTP observations, timing, exit code, and optional packet
summaries must be captured;
- runnable code is not exploit success;
- target contact is not exploit success;
- Judge replay is required before any exploit-success claim;
- memory promotion requires replayable evidence.
The first backend proof rung is exploit-combiner-proof. It is fixture-backed,
agentic:false, and proves the specimen lifecycle only: bad generated code,
Docker execution, captured failure observations, target contact, runnable
unproven code, and fail-closed non-claims. Live Tau generation, child
materialization, packet capture, Blue adaptation, memory promotion, and Judge
exploit-success replay are later rungs.
The second backend proof rung is spawn-architect-proof. It is fixture-backed,
agentic:false, and proves the DAG birth contract only: Battle loads a
spawn-policy decision, constructs a child knowledge packet from parent specimen
evidence, authors a tau.dag_contract.v1 child exploit-synthesis DAG, validates
private-artifact exclusions, and records that Tau execution is deferred to PR3.
It does not run Tau, materialize a child exploit, generate live exploit code,
compile child code, contact the target, or claim exploit success.
The current live Tau child DAG canary is live-tau-child-dag-canary. It is
non-mocked and invokes the existing local Tau DAG runtime without fixture
fallback. The PR3b/PR3c boundary is:
lineage-summarizer PASS
research-scout PASS with Tau-validated source-bearing design-input receipts
method-combiner PASS with a deterministic exploit genome candidate
exploit-code-author PASS only when Tau/SciLLM returns provider_live:true
provider-authorship evidence; otherwise BLOCKED at the precise attestation gap
The PR3c boundary may materialize provider-authored child exploit code, but it
does not compile child code, run a child specimen in Docker, or claim exploit
success. Compile repair, Docker execution, and Judge replay are later gates.
File Structure
battle/
SKILL.md # This file
run.sh # Shell entry point; launches package through uv
sanity.sh # Deterministic fixture and structure sanity gate
pyproject.toml # Dependencies
.ask/browser-oracles.yaml # WebGPT project mapping for browser-oracle walk-up
src/battle_skill/
cli.py # Typer CLI entry point
config.py # Constants and paths
state.py # Data classes and BattleState
memory.py # Team-isolated memory system
scoring.py # AIxCC-style scoring
digital_twin.py # Git worktree, Docker, QEMU isolation
red_team.py # Red Team attack agent
blue_team.py # Blue Team defense agent
orchestrator.py # Game loop orchestrator
battle_fixture.py # Deterministic fixture proof runner
judge.py # Deterministic scorekeeper verifier
receipts.py # Receipt dataclasses and JSON writer
report.py # Report generation
qemu_support.py # QEMU emulator support
qemu_peripherals.py # QEMU peripheral emulation
fixtures/battle-001/ # Deterministic local fixture
spectator/ # Self-contained BATTLE-004 spectator UI + Pixi engine
monitor/battle/ # Artifact-backed React monitor
Leveraged Skills
| Skill | Team | Purpose |
|---|
| hack | Red | Scanning, auditing, exploitation |
| anvil | Blue | Multi-agent patching (Thunderdome) |
| memory | Both | Recall prior strategies |
| treesitter | Blue | Code structure analysis |
| taxonomy | Both | Classify findings |
| task-monitor | Orchestrator | Progress tracking |
| ops-docker | Both | Container management |
Example Battle
./run.sh battle --target . --rounds 100
