git-worktreeslisted

<!-- Source: adapted from obra/superpowers `using-git-worktrees` + `finishing-a-development-branch` (MIT). SPECTER additions marked. --> # Git Worktrees — Setup and Finish ## Part 1: Setting Up an Isolated Workspace **Core principle:** Detect existing isolation first. Then use native tools. Then fall back to git. Never fight the harness. ### Step 0: Detect Existing Isolation Before creating anything, check if you are already in an isolated workspace: ```bash GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P) GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P) ``` **Submodule guard**: `GIT_DIR != GIT_COMMON` is also true inside git submodules. If `git rev-parse --show-superproject-working-tree` returns a path, you're in a submodule — treat as a normal repo. - `GIT_DIR != GIT_COMMON` (and not a submodule) → already in a linked worktree. Do NOT create another; skip to Step 2. - Otherwise → normal repo. If the user hasn't already declared a worktree preference, ask consent before creating one. ### Step 1: Create the Workspace **1a. Native tools first (preferred).** If a native worktree tool exists (e.g. the `EnterWorktree` tool, a `/worktree` command, an agent `isolation: "worktree"` option), use it and skip to Step 2. Using `git worktree add` when a native tool exists creates phantom state the harness can't see or manage — this is the #1 mistake. **1b. Git fallback (only when no native tool).** Directory priority: explicit use