# Three-Musketeers

Execute complex plans and projects with three agents — a **Builder**, an **Adversarial Reviewer**, and a **Verifier** — looping until the work genuinely works. Where most multi-agent skills help you *plan*, three-musketeers drives the **actual build and verification**.

![Builder · Adversary · Verifier](/blob/skill/three-musketeers/screenshots/crest.png)

| Role | Job | Mandate |
|------|-----|---------|
| **Builder** | Does the actual work | Build it. If the plan is wrong, do the smarter thing and note the change. |
| **Adversarial Reviewer** | Tries to poke holes | Assume it's broken. Find what the builder missed. |
| **Verifier** | Confirms it's genuinely done | Behave as a user. Does the thing actually work? |

## The complex-project pipeline: plan robustly, then build robustly

three-musketeers is the **build half of a two-stage pipeline** for serious, expensive-to-get-wrong work:

1. **Plan robustly with [adom-plan](/adom/adom-plan)** — expand the sketch, then stress-test it with 6+ adversarial debate agents (Opus vs Sonnet pairs across architecture, implementation, and security) plus a red-team consensus pass. Output: a vetted plan with a risk register and prioritized action items.
2. **Build robustly with three-musketeers** — hand that plan to the Builder, then loop Builder → Adversary → Verifier until it genuinely works.

adom-plan hardens *what to build*; three-musketeers hardens *that it was built and actually works*. The pipeline is **expensive (many agents, multiple model calls) but highly effective** — reach for it on high-stakes or long-running projects. For a quick build, three-musketeers alone (or a single agent) is enough.

## The core idea: verify behavior, not plan-conformance

The most important rule, and the reason the skill exists:

> The Verifier confirms the work by acting as a user — running the real flows via browser/computer use — and asking **"does this actually work?"** It never passes or fails the work by diffing against the original plan.

A plan encodes assumptions. A good builder experiments, discovers an assumption was wrong, and adapts. A verifier that checks against the *original* plan would then raise a false alarm — flagging correct work as "not implemented as described." The work was fine; the plan was wrong. So the Builder is free to correct the plan (logging each deviation as an amendment), and a plan↔behavior mismatch is a note for the human, never an automatic failure.

## Model assignment

| Role | Default | Why |
|------|---------|-----|
| **Builder** | Opus (1M-context for long builds) | Adapting when the plan is wrong is high-judgment work; builder errors are the most expensive downstream. Drop to Sonnet for mechanical, well-specified builds. |
| **Adversarial Reviewer** | Opus, fresh context + different disposition | Finding subtle holes is the highest-value adversarial task; diversity surfaces what a single model self-censors. Scale to a fan-out (or deep-audit) for high stakes. |
| **Verifier** | Sonnet | Behavioral verification is mostly mechanical tool-driven execution. Escalate to Opus when "is it done?" is ambiguous or safety-critical. |

**Net pattern:** Opus builds, Opus adversarially reviews (diverse context), Sonnet verifies by behavior.

## When to use it

| Situation | Use |
|-----------|-----|
| Long/complex build driven Builder→Adversary→Verifier to convergence | **three-musketeers** |
| Only a sketch/spec; want it stress-tested before building | **[adom-plan](/adom/adom-plan)** (run first, then come here) |
| Something already finished; want a read-only second opinion | **deep-audit** |
| One small change; just confirm it works | plain edit + **verify** |

## Invoking

```
/three-musketeers                 # drive the active plan / described task
/three-musketeers path/to/plan.md # build a specific plan
```

Or just describe it: *"build this, have a separate agent poke holes, then verify it actually works."*