swarm

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