Show HN: Redteam:If you are using more than 2 coding agents A developer released Redteam, an open-source adversarial agent-pair harness that uses two different AI models to plan, implement, and review code changes, producing draft pull requests for human review. The tool aims to prevent automatic self-agreement by forcing independent model perspectives, and is designed for use with coding agents like Claude Code. 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; the output is a draft PR you review before merge. 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 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 install . 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 : php 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 -- HGR human gate rescue -- 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 when-to-use-it . mode agent-pair by default, or tdd decides which phases run. The authority is phase order in orchestrator.py AGENT PAIR PHASE ORDER / TDD PHASE ORDER — 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 table shows the worker + reviewer phases. A rescue slot is entered only if a blocker persists across review rounds — in the untiered default a rescue is then human-reviewed human gate rescue before the PR. A plan-approval gate is opt-in per tier profile when-to-use-it . 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. A plain "two-model" setup stops at a second model takes a second look . redteam makes that separation structural and then acts on it: Findings are tiered, not pass/fail. The reviewer emits findings with a severity blocker / major / minor , and the orchestrator tracks each one across review rounds a carry-over count — a review is not a single thumbs up/down. Persistent problems escalate on a ladder. A blocker that survives multiple rounds climbs: retry the worker → a heavier rescue pass → hand to a human ask user . So one rejection doesn't kill a run, and a stubborn real bug doesn't get rubber-stamped after a single retry. The reviewer is blind to the writer. It's a fresh agent — and a configurably different model — that sees only the diff and the security checklist, never the implementer's reasoning, so self-justification can't cross the boundary. The draft PR is the human checkpoint; the default common path has no gates. The pair plus verification is the automated trust, so the output is a draft PR you review before merge — it never autonomously merges. Blocking human gates plan approval, etc. are opt-in per tier for risky changes, not the default. Either model on either side, zero runtime deps. See Model freedom model-freedom and Install install . Roles bind to providers through a small adapter registry, not hardcoded calls. Today Claude and Codex can each take either side: | role | providers implemented | |---|---| | worker planner / implementer | claude , codex | | reviewer / rescue | codex , claude | You choose per role in .redteam/config.toml models . A reviewer value that isn't an adapter e.g. "human" falls back to the manual flow you paste the review and touch the sentinel . Adding another provider is one adapter file plus one registry line. The goal is minimal human intervention, without losing trust — the adversarial pair is the automated trust, so the common path has no human gates. But not every change needs the same weight: a typo shouldn't pay for a full agent-pair, and an auth change shouldn't ship with only the light path. So you scale the response to the risk of the change : | change | response | |---|---| | trivial — non-behavior-changing rename, comment, formatting | single-agent, no review | | routine — small, local, reversible | single-agent loop; review optional | guarded — behavior change with real blast radius auth, storage, concurrency, public API, migrations | the adversarial pair + verification the default | strategic / production-critical — architectural, irreversible, or changes prod posture | the pair plus human gates and a rollback plan you require | Tier-aware routing lets the harness apply this automatically opt-in via config.toml . You define tier profiles as declarative toggles, and a deterministic classifier picks each task's tier: tiers.0 trivial review = false single-agent, no adversarial pair models = { implementer = "claude-haiku-4-5" } cheap model tiers.2 guarded a sensible default review = true the adversarial pair; no human gate tiers.4 production-critical review = true gates = "outcome", "pr" add human checkpoints back here tier triggers " /auth/ " = 4 touching auth floors the task at tier 4 default = 2 unclassified → safe default The binding tier is max declared, path-triggered, default — a task can be raised but never lowered below what its paths demand, and an unclassified task falls to the mandatory safe default. With no tiers section, routing is off and every task takes the default pipeline fully backward-compatible . Two levers also work on their own, without tiers: Model per role models — a cheaper implementer for routine work, a frontier reviewer for guarded work; either provider on either side. The escalation ladder — a blocker finding that survives review rounds climbs retry → rescue , concentrating effort where a problem actually persists. Trigger globs are git-pathspec-style: matches within a path segment, matches across directories so /auth/ matches auth/x at any depth . Scope note: v1 path triggers match the paths a task declaresin its front-matter, and tier profiles vary review/gates/models over the canonical pipeline not arbitrary phase orders . Re-checking the real committed diff and richer profiles are tracked on issue 13 . This repo doubles as a single-plugin marketplace, so two commands install it: /plugin marketplace add https://github.com/AscendyProject/redteam /plugin install redteam@ascendy-redteam The HTTPS URL works everywhere, including behind firewalls that block SSH port 22 . The AscendyProject/redteam shorthand also works if you have GitHub SSH keys configured. That registers the six sub-agents and the /redteam: commands. Run redteam-install also exposed as a redteam-install tool on PATH from your project root to vendor the harness in, then use the others as needed: /redteam:redteam-install vendor .redteam/ into the current repo /redteam:redteam-new-task scaffold the next task-NNN dir + input.md from the template /redteam:redteam-review one-shot cross-model review of the current branch diff /redteam:redteam-config choose the per-role models writer / reviewer / rescue /redteam:redteam-status show the pipeline status for a batch from a clone of this repo: python3 .redteam/scripts/install.py /path/to/your/project preview first: python3 .redteam/scripts/install.py /path/to/your/project --dry-run Useful flags: --overwrite refresh harness-owned files; never touches your config.toml / docs/ / batches/ , --protect-config opt-in: add Claude Code Edit/Write deny rules for .redteam/config.toml to the consumer's .claude/settings.json , add-only — the runtime pairing guard is the backstop regardless , and --check report whether a vendored install is behind this harness version, then exit — writes nothing . Either way it's the same vendoring model: the harness ships inside your project tree .redteam/ because the engine resolves your repo root from its own file location. Harness-owned files workflows/ , prompts/ , templates/ , agent skeletons are re-vendored on each run --overwrite to refresh ; project-owned files config.toml , docs/ , verify.sh , your batches/ are seeded once and never overwritten. The installer does not vendor the harness's own unit tests, so a consumer never runs or maintains them — your verify.sh runs your tests, not the engine's. The vendored .redteam/ engine follows the harness's own style, so exclude .redteam/ from your project's linter/formatter e.g. ruff's extend-exclude , an eslint ignore to avoid it flagging code you don't own.- Python 3.11+ stdlib only — zero runtime pip dependencies . - The model CLIs you configure, installed and authenticated: and/or claude codex . A vendored install is a copy of the engine in your repo, so it doesn't update itself — you re-vendor when a new version ships. --overwrite refreshes only harness-owned trees workflows/ , prompts/ , templates/ , scripts/install.py , the six agent skeletons, and the .redteam/.redteam-version stamp ; your existing project-owned files config.toml , docs/ , verify.sh and your task content under batches/ are never overwritten the installer only ensures an add-only batches/.gitignore rule there, leaving your files intact . --check compares thesourceside against your vendored stamp, so it's only meaningful when the source is thenewerone — run it from an updated plugin redteam-install … or a fresh clone. Running your repo's own vendored .redteam/scripts/install.py against that same repo compares the stamp to itself, so it can't reveal an upstream release it just echoes the vendored version, or unknown if the stamp is missing . Exit codes: 0 current/ahead · 1 outdated · 2 cannot determine. It writes nothing. The plugin ships the engine and puts redteam-install on PATH, so updating is two layers — refresh the plugin first, then re-vendor the engine it carries: /plugin marketplace update ascendy-redteam refresh the cached marketplace /plugin update redteam@ascendy-redteam update the plugin to the latest /plugin list confirm the new version /reload-plugins apply updated commands/agents no restart needed Then re-vendor the engine into your repo and confirm. Because redteam-install self-locates the plugin's now-updated source, its --check meaningfully compares that against your repo's vendored stamp: redteam-install . --check plugin source vs your vendored stamp: 1 = outdated redteam-install . --overwrite re-vendor the new engine into .redteam/ redteam-install . --check expect "verdict: up-to-date." bash .redteam/scripts/verify.sh your gate still passes Pull the latest of this repo your clone , then run the clone's installer against your project so the source side is the updated one: from your refreshed clone of this repo: python3 /path/to/redteam-clone/.redteam/scripts/install.py /path/to/your/project --check python3 /path/to/redteam-clone/.redteam/scripts/install.py /path/to/your/project --overwrite Do the update on a branch and open a PR don't push the engine bump straight to your default branch , and keep .redteam/ excluded from your linter as in Install install . Edit .redteam/config.toml for your stack paths, verify command , branch prefix , role→model , then fill the three project docs the sub-agents read: .redteam/docs/project-context.md — stack + hard rules .redteam/docs/security-checklist.md — the reviewer's hard lines .redteam/docs/test-conventions.md — how your test suite is wired Two complete examples to copy the shape from: examples/fastapi-like/ Python — FastAPI + Celery + Postgres + a vector DB and examples/nuxt-like/ JS/TS — Nuxt 3 + Vue + Vitest . python3 .redteam/workflows/orchestrator.py new .redteam/batches/