audit-context

Swarm

Describe what you want. Get a reviewed, ship-ready PR — without babysitting the agent.

Out-of-the-box agent teams can be excellent, but getting there takes time and effort — the right specialists, each with a point of view, and a bias applied where it sharpens the team and held back where it would box the agents in. Swarm puts in that effort for you, so the team converges instead of chattering and the work holds up.

/swarm:code add SSO so enterprise customers can log in with their own identity provider

Swarm assembles a team of five to eight for the task: experienced engineers, plus the customer and business voices a lone coder usually works without. They research the problem, debate the approach, build it, and review each other's work until it's ready, then hand you a PR. You approve the plan and the approach, then stay out of the build. You have the final say before anything ships.

Swarm also runs triage, writing, and general-purpose teams — see other ways to launch.

---

What you get

• Ships code that holds up — reviewed by a different agent, not rubber-stamped by its author.
• Runs unattended for hours — even across days.
• Survives interrupted turns without stalling.
• Avoids the rate-limit errors parallel teams hit — at a fraction of the tokens.

---

Quick start

Swarm is a Claude Code plugin, so you'll need the CLI installed first (v2.1.178 or newer).

claude plugin marketplace add DheerG/swarms
claude plugin install swarm@swarms --scope project

Agent teams must be enabled in Claude Code. Add this to ~/.claude/settings.json (or let /swarm:code enable it for you on first run):

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Restart Claude Code so the plugin and the flag take effect, then run /swarm:code and describe what you want.

---

How it works

Three moments need you. The rest runs itself.

1. Tell it what you want — 1-2 sentences describing the outcome. It has the ability to refine the outcome with you and work around prompting gotchas that would normally result in poor code.
2. Approve the team and the plan — the suggested specialists (swap or add members by pointing at them), the plan, and, mid-run, the approach the team converged on. Nothing irreversible happens without your sign-off.
3. Decide how to finish — when the team hits the bar, you choose to refine further or ship; you see the result, not the debate, though you can follow it live in AgentChat if you want to.

You see the whole plan before a single agent runs:

Team Plan

Mode: Code Outcomes: (your words, verbatim) Team: lead (your Claude session) + Principal Engineer facilitator + specialists for the work Cost tier: Ultra Ship definition: Create a feature branch from main, commit, push, open PR

---

Is this plan final, or do you have remaining inputs?

• Launch the team — Plan is final — start creating the team now
• I have changes — Let me adjust outcomes, members, or settings first

Nothing runs until you pick "Launch the team" — and before this plan you've already picked the cost tier and approved the team member by member.

---

A real Converge, in excerpt

Here is an excerpt from a real caching-strategy Converge:

Principal Engineer: Two approaches on the table — cache-aside with a TTL, or read-through with invalidation on write. Security Reviewer, you flagged the TTL approach earlier. What's the actual risk you see?

Security Reviewer: TTL means stale data can persist for up to N minutes after a permission change. If this endpoint returns authorization state, that's a window.

Principal Engineer: Lead, does this endpoint return authorization state, or pure profile data?

Lead: Profile data only — no permissions in the response.

Principal Engineer: Then TTL risk is acceptable here. Team, any other concerns before I call CONVERGED?

Notice that the facilitator never settles the question itself. It hands the blocker to whoever can answer it and waits for evidence, and the lead fields that question like any other member. The security risk only surfaced because someone other than the implementer was looking. On their own, they'd have shipped the stale-data window. What reaches you is the conclusion; the argument stays inside the team.

---

Why it works

Outcomes over implementations

You describe what the world looks like when the work is done, rather than the steps to build it. That changes what the team debates.

• Implementation framing: "Add a Redis cache in front of the user service."
• Outcome framing: "User profile reads return in under 50ms and don't hit the DB when cached."

Implementation framing has the team comparing Redis and Memcached. Outcome framing has them weigh caching against query optimization, the wider and more useful argument.

Everything is a prompt

Most agent frameworks bury what's actually running behind config and abstraction, so changing how the agents behave means digging through someone else's machinery. Swarm keeps the whole coordination system, from pre-flight through delivery, in readable markdown you can open:

# /swarm:launch

You are launching an agent team using the Swarm plugin. Follow every step below in exact order...

No imports, no build step. To change how a team works, you edit the prompt. Read it all: the launch flow in commands/launch.md, the governance rules in skills/workflow-rules/SKILL.md.

Recursive review until it's ready

Picture how a high-value change lands at a real company. A group of senior engineers picks it apart over weeks, not satisfied until it has clearly solved the problem, its blast radius is understood, and every edge case has been either fixed or deliberately accepted. Each concern is another round of back-and-forth, which is why a PR like that can sit in review for a month or two before anyone trusts it to merge.

Swarm runs that same gauntlet in a single session. The gate is explicit:

9/10+ means: logic is correct, tests pass where applicable, no regressions introduced, no known defects left unaddressed, reviewers would ship this.

A build often starts around 6/10. The team grinds it up, fixing and re-reviewing, and once it clears the bar an optional ladder (9.25 → 9.5 → 9.75 → 10) pushes it to the full scope of your outcome, re-earning any rung a later fix knocks loose. That is routinely 15+ rounds you never have to sit through. The mechanic that keeps it honest: the facilitator, not the lead, controls the gate. The agent that did the work never signs off on it; that call goes to a reviewer coming at it fresh, who has every reason to push back.

Before delivery you can add an independent pass: a reviewer that fails differently from the authors, a different model via Codex or a fresh-context agent, reads the whole change against your outcome. The lead fixes what it finds and the loop repeats until nothing in scope remains, often eight or more rounds on a large PR. What you get back is a PR that carries the kind of scrutiny a strong team would normally spend months assembling.

Built to run anyway

Long agent-team runs hit a wall that has nothing to do with the work: rate limits. Run the members in parallel and they hammer the API hard enough to trip those limits, and the whole run can stall out partway through, often without a word. Swarm avoids that by spawning members one at a time, which keeps it under the limits and, as a side effect, costs a fraction of a parallel team's tokens. A heartbeat keeps the lead moving, and if a turn gets cut off, the team re-checks its last action and picks up where it left off.

Portable quality across environments

Every rule that governs a team is inline in the command file,