Three-Musketeers
Public Unreviewedby Drew Owens
Execute complex plans and projects with three agents — a Builder, an Adversarial Reviewer, and a Verifier — looping until it genuinely works. The build half of the plan->build pipeline.
| Name | Last updated |
|---|---|
| screenshots | 21d ago |
| install.sh | 21d ago |
| package.json | 21d ago |
| page.json | 10d ago |
| README.md | 21d ago |
| SKILL.md | 21d ago |
| triggers.test.yaml | 21d ago |
| uninstall.sh | 21d ago |
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.
| 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."