Three-Musketeers

{
  "schema_version": 1,
  "type": "skill",
  "slug": "three-musketeers",
  "title": "Three-Musketeers",
  "brief": "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.",
  "version": "0.1.0",
  "tags": [
    "multi-agent",
    "build",
    "verification",
    "adversarial",
    "claude-code",
    "skill"
  ],
  "license": "MIT",
  "sample_prompts": [
    {
      "label": "Build with the loop",
      "prompt": "Drive this build with a builder, an adversarial reviewer, and a verifier until it genuinely works"
    },
    {
      "label": "After planning",
      "prompt": "I just finished adom-plan — now build it robustly with three-musketeers"
    },
    {
      "label": "Adversarial build",
      "prompt": "Build this feature, have a separate agent try to poke holes, then verify it as a user"
    },
    {
      "label": "Verify by behavior",
      "prompt": "Build it and verify by actually using it, not by checking against the plan"
    },
    {
      "label": "Invoke",
      "prompt": "/three-musketeers"
    }
  ],
  "source_path": "SKILL.md",
  "readme": "# Three-Musketeers\n\nExecute 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**.\n\n![Builder · Adversary · Verifier](/blob/skill/three-musketeers/screenshots/crest.png)\n\n| Role | Job | Mandate |\n|------|-----|---------|\n| **Builder** | Does the actual work | Build it. If the plan is wrong, do the smarter thing and note the change. |\n| **Adversarial Reviewer** | Tries to poke holes | Assume it's broken. Find what the builder missed. |\n| **Verifier** | Confirms it's genuinely done | Behave as a user. Does the thing actually work? |\n\n## The complex-project pipeline: plan robustly, then build robustly\n\nthree-musketeers is the **build half of a two-stage pipeline** for serious, expensive-to-get-wrong work:\n\n1. **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.\n2. **Build robustly with three-musketeers** — hand that plan to the Builder, then loop Builder → Adversary → Verifier until it genuinely works.\n\nadom-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.\n\n## The core idea: verify behavior, not plan-conformance\n\nThe most important rule, and the reason the skill exists:\n\n> 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.\n\nA 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.\n\n## Model assignment\n\n| Role | Default | Why |\n|------|---------|-----|\n| **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. |\n| **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. |\n| **Verifier** | Sonnet | Behavioral verification is mostly mechanical tool-driven execution. Escalate to Opus when \"is it done?\" is ambiguous or safety-critical. |\n\n**Net pattern:** Opus builds, Opus adversarially reviews (diverse context), Sonnet verifies by behavior.\n\n## When to use it\n\n| Situation | Use |\n|-----------|-----|\n| Long/complex build driven Builder→Adversary→Verifier to convergence | **three-musketeers** |\n| Only a sketch/spec; want it stress-tested before building | **[adom-plan](/adom/adom-plan)** (run first, then come here) |\n| Something already finished; want a read-only second opinion | **deep-audit** |\n| One small change; just confirm it works | plain edit + **verify** |\n\n## Invoking\n\n```\n/three-musketeers                 # drive the active plan / described task\n/three-musketeers path/to/plan.md # build a specific plan\n```\n\nOr just describe it: *\"build this, have a separate agent poke holes, then verify it actually works.\"*\n",
  "author": {
    "name": "Drew Owens",
    "email": "[email protected]"
  },
  "visibility": {
    "public": true
  },
  "hero": {
    "type": "image",
    "path": "screenshots/hero.png"
  },
  "discovery_triggers": [
    "build this with three agents",
    "builder adversary verifier",
    "adversarial build loop",
    "build and verify with subagents"
  ],
  "discovery_pitch": null,
  "metadata": {}
}