Worktrees and parallel agentsCapability

A git worktree is a second working copy of the same repo on a different branch, in its own folder, sharing one history. You can run several at once — which is exactly how you test three versions of an idea side by side without them stepping on each other.

Normally a git repo is one folder on one branch. To work on something else you switch branches in place — which forces you to put away whatever you were doing first. That serial bottleneck is the enemy of cheap experimentation: trying a second idea means abandoning the first.

A worktree breaks that. `git worktree add` creates a SECOND folder, checked out to its own branch, but sharing the same underlying repo and history. Edits in folder A don't touch folder B. Commits made in either show up in the shared history. It's like having two desks for the same project — same filing cabinet behind both, but two surfaces you can spread work across simultaneously.

This is why your superpowers bundle ships `using-git-worktrees` and `dispatching-parallel-agents` together: the worktree is the isolation, and a separate Claude agent in each worktree is the parallelism. You give agent A 'build the lesson card with a sidebar', agent B 'build it with a top strip', let both run, then open the two pages and pick. Same move as `design-shotgun` generating variants — but for whole working code, not just mockups.

Worked example

Two parallel variations of one small change, from your real PDB repo. Run these in /Users/tom/Claude/PDB:

git worktree add ../PDB-variantA -b try/sidebar-layout
git worktree add ../PDB-variantB -b try/topstrip-layout

git worktree list

# ...make the sidebar change in PDB-variantA, the top-strip change in PDB-variantB...

# when done comparing, throw the losers away cleanly:
git worktree remove ../PDB-variantA
git worktree remove ../PDB-variantB
git branch -D try/sidebar-layout try/topstrip-layout

• Creates a sibling folder PDB-variantA next to your repo, checked out to a brand-new branch try/sidebar-layout. The `-b` makes the branch on the spot.
• Same again for variant B on its own branch. Now you have two independent working copies of PDB, each on its own branch, both backed by the one repo.
• `git worktree list` shows all live worktrees and which branch each is on — this is your map. You should see PDB (main), PDB-variantA, and PDB-variantB.
• `git worktree remove` deletes the folder AND deregisters it cleanly — never just `rm -rf` a worktree, that leaves git's bookkeeping pointing at a ghost.
• `git branch -D` discards the experimental branches once you've picked a winner (or merged it). Cheap to create, cheap to throw away — that's the whole point.

Gotchas

• You can't check out the same branch in two worktrees at once — git refuses. Each worktree needs its own branch (that's why the examples use `-b` for a fresh one each time).
• Never delete a worktree folder with `rm -rf` — use `git worktree remove`. A raw delete leaves a stale registration; you then need `git worktree prune` to clean up the dangling reference.
• Worktrees share the repo, so a `git push` from any of them pushes to the same remote. Keep experimental branches local (don't push) until one wins — exactly your 'bootstrap to validation, then invest' rule applied to branches.
• Untracked files (node_modules, .env, build output) are NOT copied into a new worktree — only tracked files come over. If a variant needs an install step, run it inside that worktree.