using-git-worktreeslisted

# Using Git Worktrees ## Overview Ensure work happens in an isolated workspace. Detect existing isolation first, prefer the harness's native worktree tools, and fall back to manual git worktrees only when no native tool exists. Don't fight the harness. ## Detect before creating Compare the resolved paths of `git rev-parse --git-dir` and `git rev-parse --git-common-dir`. If they differ, you are in a linked worktree, unless `git rev-parse --show-superproject-working-tree` returns a path, which means you are in a submodule and should treat it as a normal repo. Never create a nested worktree. When already isolated, report the path and branch state (a detached HEAD is externally managed and needs a branch at finish time) and go straight to setup. In a normal checkout, honor any worktree preference the user has already expressed, without asking. Otherwise a worktree is reversible and protects the current branch, so set one up by default and say so, offering to work in place instead; do not block on sign-off. Ask first only when isolation would be surprising or costly here, such as a second checkout of a very large repo. If the user has declined isolation, work in place. ## Native tools first If the harness provides a worktree tool (a tool named like `EnterWorktree` or `WorktreeCreate`, a `/worktree` command, a `--worktree` flag), use it. It owns directory placement, branch creation, and cleanup; running `git worktree add` behind its back creates phantom state the harness can