parallel-agent-fan-outlisted

# Fan Out on Independence, Re-Run Every Gate Yourself When a large build decomposes into many genuinely independent units, one write-capable sub-agent per unit lands them in parallel wall-clock time. The throughput is real — and so is the new failure surface: agents collide on shared files, clobber each other's state on a shared backend, and report "done" over work that was never proven. The coordinator's job is to design the independence in up front and to trust none of the reports at the end. ## When to use Reach for this when you are the coordinator about to spawn more than a couple of write-capable agents against one repository or one shared provisioned substrate (a dev database, a containerized live server — never the production estate) — implementing N modules of a large surface, migrating N call-sites, covering N endpoints, porting N files — and the units are independent enough to build in parallel. Red-flag thoughts — if you catch yourself thinking any of these, STOP and apply this skill: - "I'll let each agent wire itself into the registry / index / router." - "They're all hitting the same dev database, it'll be fine." - "The agent said its tests pass, so that unit is done." - "I'll split this into ten 'independent' units" — but two of them edit the same file. - "The live tests are each agent's job; I'll just merge what they hand back." - "Every unit's review came back clean, so the merged whole is clean." ## The rule 1. **Pre-wire the shared seams before you