$npx -y skills add obra/superpowers --skill using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
| 1 | # Using Git Worktrees |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Ensure work happens in an isolated workspace. Prefer your platform's native worktree tools. Fall back to manual git worktrees only when no native tool is available. |
| 6 | |
| 7 | **Core principle:** Detect existing isolation first. Then use native tools. Then fall back to git. Never fight the harness. |
| 8 | |
| 9 | **Announce at start:** "I'm using the using-git-worktrees skill to set up an isolated workspace." |
| 10 | |
| 11 | ## Step 0: Detect Existing Isolation |
| 12 | |
| 13 | **Before creating anything, check if you are already in an isolated workspace.** |
| 14 | |
| 15 | ```bash |
| 16 | GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P) |
| 17 | GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P) |
| 18 | BRANCH=$(git branch --show-current) |
| 19 | ``` |
| 20 | |
| 21 | **Submodule guard:** `GIT_DIR != GIT_COMMON` is also true inside git submodules. Before concluding "already in a worktree," verify you are not in a submodule: |
| 22 | |
| 23 | ```bash |
| 24 | # If this returns a path, you're in a submodule, not a worktree — treat as normal repo |
| 25 | git rev-parse --show-superproject-working-tree 2>/dev/null |
| 26 | ``` |
| 27 | |
| 28 | **If `GIT_DIR != GIT_COMMON` (and not a submodule):** You are already in a linked worktree. Skip to Step 2 (Project Setup). Do NOT create another worktree. |
| 29 | |
| 30 | Report with branch state: |
| 31 | - On a branch: "Already in isolated workspace at `<path>` on branch `<name>`." |
| 32 | - Detached HEAD: "Already in isolated workspace at `<path>` (detached HEAD, externally managed). Branch creation needed at finish time." |
| 33 | |
| 34 | **If `GIT_DIR == GIT_COMMON` (or in a submodule):** You are in a normal repo checkout. |
| 35 | |
| 36 | Has the user already indicated their worktree preference in your instructions? If not, ask for consent before creating a worktree: |
| 37 | |
| 38 | > "Would you like me to set up an isolated worktree? It protects your current branch from changes." |
| 39 | |
| 40 | Honor any existing declared preference without asking. If the user declines consent, work in place and skip to Step 2. |
| 41 | |
| 42 | ## Step 1: Create Isolated Workspace |
| 43 | |
| 44 | **You have two mechanisms. Try them in this order.** |
| 45 | |
| 46 | ### 1a. Native Worktree Tools (preferred) |
| 47 | |
| 48 | The user has asked for an isolated workspace (Step 0 consent). Do you already have a way to create a worktree? It might be a tool with a name like `EnterWorktree`, `WorktreeCreate`, a `/worktree` command, or a `--worktree` flag. If you do, use it and skip to Step 2. |
| 49 | |
| 50 | Native tools handle directory placement, branch creation, and cleanup automatically. Using `git worktree add` when you have a native tool creates phantom state your harness can't see or manage. |
| 51 | |
| 52 | Only proceed to Step 1b if you have no native worktree tool available. |
| 53 | |
| 54 | ### 1b. Git Worktree Fallback |
| 55 | |
| 56 | **Only use this if Step 1a does not apply** — you have no native worktree tool available. Create a worktree manually using git. |
| 57 | |
| 58 | #### Directory Selection |
| 59 | |
| 60 | Follow this priority order. Explicit user preference always beats observed filesystem state. |
| 61 | |
| 62 | 1. **Check your instructions for a declared worktree directory preference.** If the user has already specified one, use it without asking. |
| 63 | |
| 64 | 2. **Check for an existing project-local worktree directory:** |
| 65 | ```bash |
| 66 | ls -d .worktrees 2>/dev/null # Preferred (hidden) |
| 67 | ls -d worktrees 2>/dev/null # Alternative |
| 68 | ``` |
| 69 | If found, use it. If both exist, `.worktrees` wins. |
| 70 | |
| 71 | 3. **If there is no other guidance available**, default to `.worktrees/` at the project root. |
| 72 | |
| 73 | #### Safety Verification (project-local directories only) |
| 74 | |
| 75 | **MUST verify directory is ignored before creating worktree:** |
| 76 | |
| 77 | ```bash |
| 78 | git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null |
| 79 | ``` |
| 80 | |
| 81 | **If NOT ignored:** Add to .gitignore, commit the change, then proceed. |
| 82 | |
| 83 | **Why critical:** Prevents accidentally committing worktree contents to repository. |
| 84 | |
| 85 | #### Create the Worktree |
| 86 | |
| 87 | ```bash |
| 88 | # Determine path based on chosen location |
| 89 | path="$LOCATION/$BRANCH_NAME" |
| 90 | |
| 91 | git worktree add "$path" -b "$BRANCH_NAME" |
| 92 | cd "$path" |
| 93 | ``` |
| 94 | |
| 95 | **Sandbox fallback:** If `git worktree add` fails with a permission error (sandbox denial), tell the user the sandbox blocked worktree creation and you're working in the current directory instead. Then run setup and baseline tests in place. |
| 96 | |
| 97 | ## Step 2: Project Setup |
| 98 | |
| 99 | Auto-detect and run appropriate setup: |
| 100 | |
| 101 | ```bash |
| 102 | # Node.js |
| 103 | if [ -f package.json ]; then npm install; fi |
| 104 | |
| 105 | # Rust |
| 106 | if [ -f Cargo.toml ]; then cargo build; fi |
| 107 | |
| 108 | # Python |
| 109 | if [ -f requirements.txt ]; then pip install -r requirements.txt; fi |
| 110 | if [ -f pyproject.toml ]; then poetry install; fi |
| 111 | |
| 112 | # Go |
| 113 | if [ -f go.mod ]; then go mod download; fi |
| 114 | ``` |
| 115 | |
| 116 | ## Step 3: Verify Clean Baseline |
| 117 | |
| 118 | Run tests to ensure workspace starts clean: |
| 119 | |
| 120 | ```bash |
| 121 | # Use project-appropriate command |
| 122 | npm test / cargo test / pytest / go test ./... |
| 123 | ``` |
| 124 | |
| 125 | **If tests fail:** Report failures, ask whether to proceed or investigate. |
| 126 | |
| 127 | **If tests pass:** Report rea |