redteam

redteam

An adversarial agent-pair harness for shipping code with AI. One model drives a task through a pipeline (plan → implement → review); a different model reviews the work adversarially; humans gate the irreversible steps. The collision of two independent model perspectives is the point — automatic self-agreement is what it exists to prevent. (A single-model TDD mode that front-loads write_test → verify_test is also available — see Phases by mode.)

Status: early. redteam was built as one project's internal harness and then extracted into this standalone repo, which owns it going forward — it has driven real, merged pull requests. (Its early git history reflects that origin, including cross-repo coordination from the parent project.) APIs and layout may still move.

Quick install (Claude Code) — two commands:

/plugin marketplace add https://github.com/AscendyProject/redteam
/plugin install redteam@ascendy-redteam

Not on Claude Code? Vendor it into any repo — see Install.

What it does

Given a batch of tasks (each a short input.md brief), the orchestrator walks every task through a fixed pipeline, persisting state.json after each phase so a run is fully resumable and retrying on CHANGES_REQUESTED:

flowchart TD
    PO[plan_outcome]:::worker --> PRV[plan_review]:::rev
    PRV --> IMPL[implement]:::worker
    IMPL --> RC[review_code]:::rev
    RC -->|APPROVED| CPR[create_pr → draft PR]:::worker
    RC -->|CHANGES_REQUESTED| IMPL
    RC -. blocker persists .-> RES[rescue]:::rev
    RES --> CPR
    CPR --> DONE([done]):::done

    classDef worker fill:#e3f2fd,stroke:#1976d2,color:#0d47a1;
    classDef rev fill:#fce4ec,stroke:#c2185b,color:#880e4f;
    classDef done fill:#e8f5e9,stroke:#388e3c,color:#1b5e20;

_{Blue = worker model (writes) · pink = reviewer model (adversarial, fresh).}

This is the default agent-pair flow. By design it runs with no human gates in the common path — the adversarial pair plus verification is the trust, and the output is a draft PR (your existing human checkpoint before merge), not an auto-merge. Human gates are something you add back for risky changes, not the default tax on every change — see When to use it.

Phases by mode

mode (agent-pair by default, or tdd) decides which phases run. The authority is PHASE_ORDER in orchestrator.py — driving the pipeline manually must follow the row for the declared mode, not the prose:

Mode	Core phases
agent-pair (default)	plan_outcome → plan_review → implement → review_code → create_pr
tdd	plan_outcome → write_test → verify_test → implement → review_code → create_pr

The agent-pair worker writes its tests inside implement — there is no separate test-authoring phase; the second perspective is the adversarial reviewer (review_code), and the plan is independently checked by plan_review. The TDD mode instead drops plan_review and front-loads a write_test → verify_test pair before implement. So write_test / verify_test (the test-author / test-verifier sub-agents) run in TDD mode only — inserting them into an agent-pair task runs a phase the mode excludes.

(The conditional rescue escalation slot and any human gates are added per the tier profile; the table shows the common path.)

Each phase is run by a focused sub-agent with its own prompt and tool scope (.claude/agents/*.md): an outcome-planner, implementer, code-security-reviewer, and pr-author — plus a test-author / test-verifier pair used only in TDD mode. The reviewer is a fresh agent that only sees the diff and the project's security checklist — it never sees the implementer's reasoning.

How it's different

A plain "two-model" setup stops at a second model takes a second look. redteam makes that separation structural and then acts on it: