/swarm
Spawn N parallel implementations of a single ticket in isolated worktrees, then let you pick the winning approach.
When to use it
Most tickets have a single reasonable implementation. The team
discusses scope, the worker implements it, the reviewer approves it,
done. /swarm is for the cases that don’t fit that pattern: tickets
where the variation axis is the interesting thing.
Examples: “try three different visual treatments for the install tabs and let me pick.” “Implement the search component three ways — sidebar, modal, inline — so we can compare.” “Three candidate retry policies for the validation gate.” Each variation is a legitimate take; the right call requires seeing them side by side.
Do NOT use /swarm for single-shape work where you just want
implementation done. That’s /work-ticket — a
swarm of three identical implementations is wasted effort.
How it fits
The swarm-planner agent produces N distinct briefs. N ticket-worker agents run in isolated git worktrees. N PRs land. You pick which one ships.
What it does (quick)
- Verifies the ticket has a clear variation axis (single-shape tickets are rejected — use
/work-ticket) - Spawns the swarm-planner agent to produce N briefs (one per variation)
- Launches N github-ticket-worker agents in isolated worktrees, each working from a different brief
- Each worker produces a PR following the same branch + tests + CI discipline as
/work-ticket - The PRs land serially (to avoid CI thrash); you compare and pick a winner
- Losing PRs are closed (not merged); their branches can be saved as reference
Related commands
/work-ticket— the single-implementation sibling; the right choice when the ticket has only one reasonable shape/review-pr— each swarm PR goes through the same review gate
Canonical spec: .claude/commands/swarm.md