swarm

Use the swarm workflow: frame a done predicate, choose a partition or race shape, then spawn all N workers in one message as background cloud subagents. Each worker gets a standalone brief with goal, scope, verification, and reporting format, and the parent aggregates results into one report.

Slices partition the work so each worker covers a distinct scope, while races give N workers identical briefs and select a winner. For races you must declare first pass, rank all, or best-of before spawning so the selection rule is fixed up front.

No. Each worker that writes needs its own writable output, such as a worktree, branch, or a /tmp/swarm-<slug>/worker-<n>/ directory. This prevents parallel workers from clobbering each other's changes.

The workflow proceeds with N-1 workers and notes the dropout. The final report includes an explicit gaps or dropouts section so missing coverage is visible rather than silently omitted.

Avoid swarming when the task is small, strictly sequential, or when steps depend on each other's output. Swarm adds coordination overhead, so it pays off only for parallelizable coverage, races, or broad exploration.