worktree

# Worktree Isolation <!-- routing-eval reads this line; it lives in the BODY so the always-on skill LISTING stays inside Claude Code's budget (1% of the context window) — an overflowing listing gets descriptions truncated or dropped, which strips the very keywords a match depends on. --> Trigger phrases: "worktree", "git worktree", "isolate the changes", "sandbox this work", "parallel file edits" One rule: **never let risky or parallel work run on top of uncommitted changes in the shared tree.** A git worktree gives a second working copy of the same repo on its own branch — you experiment or fan out agents there, and the main tree (with your in-progress edits) is physically untouched. Throw the worktree away and nothing you cared about is lost. > **Kit adaptation (local, .claude/):** this exists because verification/fan-out subagents have discarded a session's > **uncommitted** work by running a destructive git command over the shared tree. Those commands (`reset --hard`, > `clean -f`, `checkout -- .`, `restore`) are §4.5-gated — but the real fix is to not put them near unsaved work. > The Agent tool's `isolation: "worktree"` does this automatically for parallel mutating agents; reach for it there. ## When to isolate - **Fan-out that writes files** — two+ agents editing the same repo in parallel would collide; give each its own worktree. - **A throwaway experiment** — you might keep it or bin it; a worktree makes "bin it" a one-liner, not a `reset --hard`. - **A...