when-not-to-orchestrate
Installation
SKILL.md
When NOT to Orchestrate
Overview
Fanning out is a bet that the work divides. When it doesn't, parallelism does not just fail to help — it manufactures a class of bug that a single pass cannot produce, because each agent edits a world the others are simultaneously changing.
The instruction to parallelize is not the decision. "Throw this at a bunch of agents so it goes fast" is a request for a result, and the fastest route to it is often one pass.
The Three Gates
Fan out only if all three are yes. One "no" means a single pass, or one agent.
| Gate | The question | A "no" looks like |
|---|---|---|
| Divisible | Can each piece be finished without seeing another piece's edits? | Rename, signature change, schema migration, dependency bump — the pieces are the same change in different files |
| Closable | Can each piece's spec be closed — schema, path, success criterion — before dispatch? | "Clean this up", "make it consistent", anything you'd have to answer questions about |
| Checkable | Can you verify each result without re-reading everything the others produced? | Correctness only visible in the whole, e.g. "no caller is left on the old name" |
Divisible is the one that gets skipped. Twelve files mentioning one config key look like twelve tasks. They are one task with twelve locations.