Parallel worktrees

Run independent slices of work concurrently, each in its own git worktree on its own branch, then integrate. The mechanism already exists in the harness (see the table below); this skill is the discipline that decides whether to parallelize and how to partition so it does not turn into merge hell.

Rung 0: should this even be parallel?

Parallel worktrees pay off only when all three hold. If any fails, work sequentially and say so:

1. The slices are genuinely independent (no slice needs another's output).
2. The slices touch disjoint files (see partitioning below). Overlap means conflicts at integration, which usually costs more than the parallelism saved.
3. The wall-clock saving is real (each slice is substantial, not a two-line edit).

Works with or without formal planning docs. When plans / PRDs / ADRs exist, read their files-touched sections to build the conflict graph; otherwise partition straight from the change surface.

Rung 1: partition the work

This is the step that makes or breaks it. Split the task so no two slices write the same file. Partition by directory, module, feature, or layer, whichever gives clean disjoint sets. Reads may overlap freely; only writes collide.