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).

If you already have formal plans / PRDs / ADRs to run concurrently, use /maestro instead: it builds the conflict graph from the plans' files-touched data and judges worthwhileness for you. This skill is for the lighter, plan-optional case.

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.