Swarm
Get consistent predictable, well tested results from claude code sessions.
This plugin gives users a few commands that greatly improve results using agent teams/swarms with outcome based directives. It works well with both coding and non-coding tasks.
Unlike out-of-the-box agent teams, swarm gives the team members much needed instruction on being better at communicating with each other, better at following instructions, staying active during long lasting sessions, applying great quality improvement processes, all while requiring fewer course corrections.
Swarm launches a small team of agents for each task: a lead, a Socratic facilitator, and specialists you pick for the work. They research independently and argue through disagreements before the team scores its own output. Work only reaches you after the team agrees it's at 9 out of 10. Most of the quality work happens in the cycles you never see.
/swarm:launch
New here? Start with /swarm:onboard, a short walkthrough of the four concepts before your first launch.
Quick start
Install the plugin:
claude plugin marketplace add DheerG/swarms
claude plugin install swarm@swarms --scope project
Agent teams must also be enabled in Claude Code. Add to ~/.claude/settings.json:
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
/swarm:launch checks for this and will enable it for you if it's missing. For local development:
claude --plugin-dir /path/to/swarms
Changes take effect in the next session.
If you ship in auto mode to an org that isn't one of this repo's configured remotes (a fork's upstream, a mirror, or a different org), the permission classifier may deny the first push. Press r in /permissions to approve and ship right then; to stop it recurring, add the destination to autoMode.environment in user scope (~/.claude/settings.json) or local scope (.claude/settings.local.json, gitignored) — Claude Code ignores autoMode in shared project scope. Keep $defaults (it already trusts this repo's own remotes), and replace the placeholders with your host/org:
{
"autoMode": {
"environment": [
"$defaults",
"Source control: <your-host>/<your-org>. Pushing branches and opening pull requests is part of the standard development workflow."
]
}
}
Why I built this
I built this across hundreds of sessions, pruning rules, memories, and skills until the quality stopped varying. When model quality shifted, small targeted changes kept it working, even on smaller models. Once the results were consistent enough to rely on, I started sharing with teammates and friends.
That's when the real problem showed up. I'd send a prompt to someone I work with and watch them get wildly different results. Their Claude had a different CLAUDE.md, different memories, different local skills, different settings hooks. All of that ambient context quietly rewrote what they were trying to do, not just their prompts. The prompt alone wasn't the problem. The environment around it was.
Swarm is the fix. It bundles the rules and the phases into one plugin you install and invoke, so what you share is what actually runs, on your machine or anyone else's. Portable quality, not just personal repeatability.
— Dheer
More on how I think about agents: dheer.co
Who this is for
Swarm is for you if:
- You've noticed the same prompt produces a great result on Tuesday and a mediocre one on Thursday, and you want structural pushback instead of hoping for a good day.
- You're sharing prompts with teammates, friends, or family and their results don't match yours because their local context is different.
- You want a second (and third, and fourth) opinion enforced on every piece of work before it reaches you.
- Your task is complex enough that you want a plan approved before anything runs.
Swarm is not:
- A task manager. There's no backlog, no tickets, no sprint.
- A workflow framework. There are no DAGs, no YAML, no runtime composition.
How it works
Running /swarm:launch is a guided interaction. At every step you either see something or make a choice, with no silent spawns and no mystery setup.
1. State what you want
/swarm:launch
The first question is always about outcomes. An outcome describes what success looks like when the work is done, rather than what to build.
Do you have outcomes defined, or would you like help?
- I'll provide my outcomes (Recommended)
I know what success looks like and will describe it
- Help me define outcomes
Use /swarm:refine-outcomes to reframe my ideas into outcome statements
