parallel

parallel — fan out independent work, then reconcile

Parallelism is a property of the work, not a wish. Prove the pieces are disjoint, dispatch one subagent per piece with a self-contained brief, then gather and reconcile before anyone calls it done.

This is an on-demand process skill in the SDD chain. You reach it from implement (or any phase) when the work in front of you splits into pieces that could each be handed to a different person who never talks to the others. It owns one discipline: partition → dispatch → gather → reconcile. It does not own the work inside each piece — a subagent building a module still runs its own red → green → refactor loop from implement; this skill only orchestrates the fan-out. It also does not own the place the work runs: a clean branch or checkout to work in is worktrees. parallel decides what can run at the same time; worktrees provides the isolation it runs in.

The whole value is in the gate at the front. Run work in parallel only when it is actually independent. Forcing parallelism onto coupled work does not make it faster — it makes it a merge disaster, and the time you save dispatching you lose tenfold reconciling. Most of this skill is about earning the right to parallelize.

The independence test (run this before dispatching anything)

A set of tasks is safe to parallelize only when every answer below is yes. One no means serialize that pair.

INDEPENDENCE TEST — for every PAIR of candidate tasks
- [ ] Disjoint files       — they never write the same file (and don't both edit a shared barrel/index/registry)
- [ ] No shared state       — no shared in-memory object, DB row, migration, global config, or env they both mutate
- [ ] No ordering edge      — neither needs the other's OUTPUT to start or to assert against
- [ ] No hidden coupling     — not the same schema/contract/type that must agree, not the same external resource
- [ ] Self-containable brief — each can be described fully on its own, with its own done-check, without "see the other task"