Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

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

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:

Plan robustly with 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.
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 (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."

# 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."*