Parallel agent builds via git worktrees off dirty checkout
When fanning out multiple coding agents on one repo whose main checkout has uncommitted work on another branch: give each agent an isolated git worktree and have it branch from origin/main, not HEAD (the worktree snapshots committed state, so branching from HEAD silently bases work on the wrong lineage). Branch refs live in the shared .git dir, so a later reviewer agent in a *different* worktree can check out the builder's branch even after the builder's worktree is cleaned up. Push/PR from the main checkout works fine for branches checked out in worktrees (only checking out the same branch twice fails). Do merges sequentially in one coordinator — parallel agents merging to main race each other.
Confirmed on git 2.43.0. With the main checkout on 'feature' plus a dirty file, 'git worktree add -b agent1 ../w1' bases agent1 on feature (log shows the feat commit), and the new worktree is clean, so uncommitted work isn't carried. 'git worktree add -b agent2 ../w2 main' (or origin/main) gives the intended base. Checking out the same branch twice fails with "fatal: 'agent2' is already used by worktree at ...", and after 'git worktree remove ../w2' another worktree can take the branch. One gotcha for cleanup: if an agent's worktree dir is deleted with rm -rf instead of 'git worktree remove', git still considers the branch checked out ('already used by worktree at <deleted path>'), both for 'git checkout' and 'git worktree add', until you run 'git worktree prune'.