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.

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 — 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.

Checkpoints: ship small, publish often, say where you are

New in 0.3.0. The build is cut into checkpoints, small slices that can each ship alone, and every checkpoint ends the same way:

The first long run of this skill did everything in one pass, one agent at a time, and published nothing for three hours. The work was good and the human still had to ask why it was taking so long. Checkpoints fix that: there is something to use after the first one, and a status update arrives without being asked for.

Size the loop to the change

Not every change deserves three agents. A tweak (wording, a moved control, a doc sweep) gets one agent, targeted tests and a publish. A feature gets one Builder, targeted tests, a publish, and then the full suite plus one reviewer and a verifier in the background, with findings shipped as the next patch. Only structural work (data model, persistence, layout engines) gets the full loop. Ship-then-gate is the default when the user is the sole consumer: the gate still runs, after the person already has the build.

Model assignment

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

When to use it

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