--- name: swarm description: "Fan out N parallel workers, drain them, and return one report. Use for /swarm, 'swarm this', or parallel coverage, races, gauntlets, and exploration." --- # Swarm ## Host compatibility Follow [pstack host compatibility](../poteto-mode/compatibility.md) throughout this workflow. Use host-native tools and available subagents, inheriting model settings unless the user has explicitly configured supported overrides. A missing independent reviewer is a coverage gap, not a successful review. Work only within the requested scope; external messages, PRs, pushes, merges, deployments, deletion, and schedules require applicable user authorization. Preserve unrelated changes and required legal, safety, and API-contract information. Fan out N parallel cloud workers. They may cover separate slices, race the same brief, or mix both. The parent waits, aggregates, and returns one report. ## Start Open a todolist with one entry per phase before launching anything. 1. Frame 2. Fan out 3. Aggregate 4. Report ## Phase A: Frame 1. State the done predicate and the artifact or report the swarm must return. 2. Choose the shape. Partition into slices, race N workers on identical briefs, or mix both. For a race or mixed shape, declare `first pass`, `rank all`, or `best-of` before spawning. 3. Set N from the user or derive it from the shape. N is total workers, not the cloud concurrency limit. 4. Inherit the parent model, or use explicitly requested supported role preferences. For an authorized model comparison, name the actual available models before starting. 5. Give each worker its own writable output when it writes. When workers verify or measure commits, each brief names the exact SHAs. A measurement brief also names the method (sample count, what one sample is, order). The worker records both in its result. ## Phase B: Fan out Use available host-native workers, batching within concurrency limits. Use isolated writable locations and tell workers they share the codebase and must preserve other edits. Do not assume cloud-worker or cloud-base-branch APIs exist. If delegation is unavailable, execute the slices sequentially and report that limitation. Every brief stands alone. Include the goal, scope, exact slice or race arm, how to verify, and what to report. Reports use `PASS`, `ISSUES`, or `BLOCKED` with evidence. A worker that can prove a defect reports `ISSUES` and lists every issue it can prove, not only the first. If a worker drops out, proceed with N-1 and note it. ## Phase C: Aggregate Read the terminal results. Drop a result that does not record the SHAs and method its brief names, and respawn that worker once. After a second miss, record a gap. A gap does not count as a pass. For coverage, every required slice needs a result. For a race, apply the selection rule declared up front. Use first pass, rank all, or best-of. Do not paste raw worker dumps. Keep a compact result table, one-line evidenced issues, and explicit gaps or dropouts. ## Phase D: Report Return one consolidated in-chat report with the table, issue one-liners, gaps or dropouts, and the race rule when used.