Ensures an isolated workspace exists via native tools or git

Using git worktrees

by obra · MIT license · ★ 289,792 on GitHub · updated Sep 20

Using git worktrees cover

Use 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

---
name: using-git-worktrees
description: Use 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
---

# Using Git Worktrees

## Overview

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.

**Core principle:** Detect existing isolation first. Then use native tools. Then fall back to git. Never fight the harness.

**Announce at start:** "I'm using the using-git-worktrees skill to set up an isolated workspace."

## Step 0: Detect Existing Isolation

**Before creating anything, check if you are already in an isolated workspace.**

Overview

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.

Manual install (npx, ZIP)
Claude Codenpx skills add obra/superpowers --skill using-git-worktrees -g -a claude-code
Claude Code (manual)mkdir -p ~/.claude/skills && curl -sL https://codeload.github.com/obra/superpowers/tar.gz/5bf4e7801107 \ | tar -xz -C ~/.claude/skills --strip-components=2 superpowers-5bf4e7801107/skills/using-git-worktrees
Windows (PowerShell)New-Item -ItemType Directory -Force "$HOME\.claude\skills" | Out-Null; Invoke-WebRequest "https://m.agentalley.io/zip/ad1aa92a97c5611d3fd1/using-git-worktrees.zip" -OutFile "$env:TEMP\using-git-worktrees.zip"; Expand-Archive "$env:TEMP\using-git-worktrees.zip" -DestinationPath "$HOME\.claude\skills" -Force
Claude.ai / desktopDownload the ZIP and upload it under Settings → Capabilities → Skills.
Codex, Cursor, other agentsPoint them at SKILL.md. The other files are plain text.

Connects with Agent Alley MCP · agentalley.io/mcp

Files included

  • SKILL.md6.7 KB
Read the files here
obra/5bf4e781 file
SKILL.md
Show the full text168 lines

Using Git Worktrees

Overview

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.

Core principle: Detect existing isolation first. Then use native tools. Then fall back to git. Never fight the harness.

Announce at start: "I'm using the using-git-worktrees skill to set up an isolated workspace."

Step 0: Detect Existing Isolation

Before creating anything, check if you are already in an isolated workspace.

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)
BRANCH=$(git branch --show-current)

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:

# If this returns a path, you're in a submodule, not a worktree — treat as normal repo
git rev-parse --show-superproject-working-tree 2>/dev/null

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.

Report with branch state:

  • On a branch: "Already in isolated workspace at <path> on branch <name>."
  • Detached HEAD: "Already in isolated workspace at <path> (detached HEAD, externally managed). Branch creation needed at finish time."

If GIT_DIR == GIT_COMMON (or in a submodule): You are in a normal repo checkout.

Has the user already indicated their worktree preference in your instructions? If not, ask for consent before creating a worktree:

"Would you like me to set up an isolated worktree? It protects your current branch from changes."

Honor any existing declared preference without asking. If the user declines consent, work in place and skip to Step 2.

Step 1: Create Isolated Workspace

You have two mechanisms. Try them in this order.

1a. Native Worktree Tools (preferred)

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.

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.

Only proceed to Step 1b if you have no native worktree tool available.

1b. Git Worktree Fallback

Only use this if Step 1a does not apply — you have no native worktree tool available. Create a worktree manually using git.

Directory Selection

Follow this priority order. Explicit user preference always beats observed filesystem state.

  1. Check your instructions for a declared worktree directory preference. If the user has already specified one, use it without asking.

  2. Check for an existing project-local worktree directory:

    ls -d .worktrees 2>/dev/null     # Preferred (hidden)
    ls -d worktrees 2>/dev/null      # Alternative
    

    If found, use it. If both exist, .worktrees wins.

  3. If there is no other guidance available, default to .worktrees/ at the project root.

Safety Verification (project-local directories only)

MUST verify directory is ignored before creating worktree:

git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null

If NOT ignored: Add to .gitignore, commit the change, then proceed.

Why critical: Prevents accidentally committing worktree contents to repository.

Create the Worktree
# Determine path based on chosen location
path="$LOCATION/$BRANCH_NAME"

git worktree add "$path" -b "$BRANCH_NAME"
cd "$path"

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.

Step 2: Project Setup

Auto-detect and run appropriate setup:

# Node.js
if [ -f package.json ]; then npm install; fi

# Rust
if [ -f Cargo.toml ]; then cargo build; fi

# Python
if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
if [ -f pyproject.toml ]; then poetry install; fi

# Go
if [ -f go.mod ]; then go mod download; fi

Step 3: Verify Clean Baseline

Run tests to ensure workspace starts clean:

# Use project-appropriate command
npm test / cargo test / pytest / go test ./...

If tests fail: Report failures, ask whether to proceed or investigate.

If tests pass: Report ready.

Report
Worktree ready at <full-path>
Tests passing (<N> tests, 0 failures)
Ready to implement <feature-name>

Quick Reference

Situation Action
Already in linked worktree Skip creation (Step 0)
In a submodule Treat as normal repo (Step 0 guard)
Native worktree tool available Use it (Step 1a)
No native tool Git worktree fallback (Step 1b)
.worktrees/ exists Use it (verify ignored)
worktrees/ exists Use it (verify ignored)
Both exist Use .worktrees/
Neither exists Check instruction file, then default .worktrees/
Directory not ignored Add to .gitignore + commit
Permission error on create Sandbox fallback, work in place
Tests fail during baseline Report failures + ask
No package.json/Cargo.toml Skip dependency install

Common Rationalizations

Excuse Reality
"I'm obviously not in a worktree — no need to check" Run Step 0. Harness-created isolation and submodules both fool eyeballing; the detection commands settle it.
"git worktree add is quicker than hunting for a native tool" A native tool (e.g. EnterWorktree) owns placement, branching, and cleanup. Bypassing it is the #1 mistake — it creates phantom state your harness can't see or manage.
"The worktree directory is surely ignored already" Run git check-ignore. An unignored worktree directory commits the whole tree into the repo.
"Any directory name works" Explicit instructions beat an existing project-local directory, which beats the .worktrees/ default.
"The workspace is fresh — baseline tests can wait" A dirty baseline makes every later failure ambiguous. Run the tests now; proceeding past failures is your human partner's call.
1---
2name: using-git-worktrees
3description: Use 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
4---
5 
6# Using Git Worktrees
7 
8## Overview
9 
10Ensure 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.
11 
12**Core principle:** Detect existing isolation first. Then use native tools. Then fall back to git. Never fight the harness.
13 
14**Announce at start:** "I'm using the using-git-worktrees skill to set up an isolated workspace."
15 
16## Step 0: Detect Existing Isolation
17 
18**Before creating anything, check if you are already in an isolated workspace.**
19 
20```bash
21GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
22GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
23BRANCH=$(git branch --show-current)
24```
25 
26**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:
27 
28```bash
29# If this returns a path, you're in a submodule, not a worktree — treat as normal repo
30git rev-parse --show-superproject-working-tree 2>/dev/null
31```
32 
33**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.
34 
35Report with branch state:
36- On a branch: "Already in isolated workspace at `<path>` on branch `<name>`."
37- Detached HEAD: "Already in isolated workspace at `<path>` (detached HEAD, externally managed). Branch creation needed at finish time."
38 
39**If `GIT_DIR == GIT_COMMON` (or in a submodule):** You are in a normal repo checkout.
40 
41Has the user already indicated their worktree preference in your instructions? If not, ask for consent before creating a worktree:
42 
43> "Would you like me to set up an isolated worktree? It protects your current branch from changes."
44 
45Honor any existing declared preference without asking. If the user declines consent, work in place and skip to Step 2.
46 
47## Step 1: Create Isolated Workspace
48 
49**You have two mechanisms. Try them in this order.**
50 
51### 1a. Native Worktree Tools (preferred)
52 
53The 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.
54 
55Native 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.
56 
57Only proceed to Step 1b if you have no native worktree tool available.
58 
59### 1b. Git Worktree Fallback
60 
61**Only use this if Step 1a does not apply** — you have no native worktree tool available. Create a worktree manually using git.
62 
63#### Directory Selection
64 
65Follow this priority order. Explicit user preference always beats observed filesystem state.
66 
671. **Check your instructions for a declared worktree directory preference.** If the user has already specified one, use it without asking.
68 
692. **Check for an existing project-local worktree directory:**
70 ```bash
71 ls -d .worktrees 2>/dev/null # Preferred (hidden)
72 ls -d worktrees 2>/dev/null # Alternative
73 ```
74 If found, use it. If both exist, `.worktrees` wins.
75 
763. **If there is no other guidance available**, default to `.worktrees/` at the project root.
77 
78#### Safety Verification (project-local directories only)
79 
80**MUST verify directory is ignored before creating worktree:**
81 
82```bash
83git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
84```
85 
86**If NOT ignored:** Add to .gitignore, commit the change, then proceed.
87 
88**Why critical:** Prevents accidentally committing worktree contents to repository.
89 
90#### Create the Worktree
91 
92```bash
93# Determine path based on chosen location
94path="$LOCATION/$BRANCH_NAME"
95 
96git worktree add "$path" -b "$BRANCH_NAME"
97cd "$path"
98```
99 
100**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.
101 
102## Step 2: Project Setup
103 
104Auto-detect and run appropriate setup:
105 
106```bash
107# Node.js
108if [ -f package.json ]; then npm install; fi
109 
110# Rust
111if [ -f Cargo.toml ]; then cargo build; fi
112 
113# Python
114if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
115if [ -f pyproject.toml ]; then poetry install; fi
116 
117# Go
118if [ -f go.mod ]; then go mod download; fi
119```
120 
121## Step 3: Verify Clean Baseline
122 
123Run tests to ensure workspace starts clean:
124 
125```bash
126# Use project-appropriate command
127npm test / cargo test / pytest / go test ./...
128```
129 
130**If tests fail:** Report failures, ask whether to proceed or investigate.
131 
132**If tests pass:** Report ready.
133 
134### Report
135 
136```
137Worktree ready at <full-path>
138Tests passing (<N> tests, 0 failures)
139Ready to implement <feature-name>
140```
141 
142## Quick Reference
143 
144| Situation | Action |
145|-----------|--------|
146| Already in linked worktree | Skip creation (Step 0) |
147| In a submodule | Treat as normal repo (Step 0 guard) |
148| Native worktree tool available | Use it (Step 1a) |
149| No native tool | Git worktree fallback (Step 1b) |
150| `.worktrees/` exists | Use it (verify ignored) |
151| `worktrees/` exists | Use it (verify ignored) |
152| Both exist | Use `.worktrees/` |
153| Neither exists | Check instruction file, then default `.worktrees/` |
154| Directory not ignored | Add to .gitignore + commit |
155| Permission error on create | Sandbox fallback, work in place |
156| Tests fail during baseline | Report failures + ask |
157| No package.json/Cargo.toml | Skip dependency install |
158 
159## Common Rationalizations
160 
161| Excuse | Reality |
162|--------|---------|
163| "I'm obviously not in a worktree — no need to check" | Run Step 0. Harness-created isolation and submodules both fool eyeballing; the detection commands settle it. |
164| "`git worktree add` is quicker than hunting for a native tool" | A native tool (e.g. `EnterWorktree`) owns placement, branching, and cleanup. Bypassing it is the #1 mistake — it creates phantom state your harness can't see or manage. |
165| "The worktree directory is surely ignored already" | Run `git check-ignore`. An unignored worktree directory commits the whole tree into the repo. |
166| "Any directory name works" | Explicit instructions beat an existing project-local directory, which beats the `.worktrees/` default. |
167| "The workspace is fresh — baseline tests can wait" | A dirty baseline makes every later failure ambiguous. Run the tests now; proceeding past failures is your human partner's call. |
168 
View all files on GitHub →

Details

Updated
Sep 20, 2026
License
MIT
Stars on the repo
★ 289,792
Checked
Source
obra/superpowers ↗
Creator
obra · 14 listings
View creator

Similar skills

See all →
SkillAutomates CI/CD pipeline setupCI/CD and Automationaddyosmani/agent-skills · by addyosmaniAutomates CI/CD pipeline setup. Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.★ 98.7k GitHub starsSkillAutomated semantic versioning and release workflowVersion Bump & Release Workflowthedotmack/claude-mem · by thedotmackAutomated semantic versioning and release workflow for Claude Code plugins. Handles version increments across package.json, marketplace.json, plugin.json manifests, build verification, git tagging, GitHub releases, and changelog generation. NPM publishing is the final human-required handoff because the maintainer raised npm security.★ 95.6k GitHub starsSkillOperate Orca-managed worktrees, folder contexts, terminalsOrca CLIstablyai/orca · by stablyaiOperate Orca-managed worktrees, folder contexts, terminals, repos, automations, artifacts, skill sharing, worktree comments, and Orca's embedded browser through the `orca` CLI. Use when the user says "$orca-cli", "Orca worktree", "child worktree", "spawn codex/claude in a worktree", "read/wait/send Orca terminal", "handoff" / "handover" / "give this to another agent", "Orca browser", "orca artifacts", or "share skills". Prefer it over raw git worktree, ad hoc PTYs, or Computer Use when Orca state is involved. Use Computer Use only when a visible window needs GUI control that a CLI, filesystem, or API cannot do.★ 84.5k GitHub starsSkillThreaded messages, blocking ask/reply, task dispatchOrca Orchestrationstablyai/orca · by stablyaiCoordinate supervised Orca workers: threaded messages, blocking ask/reply, task dispatch, worker_done/escalation waits, task DAGs, decision gates, coordinator loops, and decomposing work across agents. Use `orca-cli` for full ownership handoffs — "hand off", "handoff", "handover", "give this to another agent", "another worktree" — unless asked to supervise, monitor, or coordinate a DAG, and for terminal control, lightweight terminal prompts, shell commands, Orca worktree management, and reading or waiting on terminals.★ 84.5k GitHub starsSkillDeploy applications and websites to VercelVercel deploybytedance/deer-flow · by bytedanceDeploy applications and websites to Vercel. Use this skill when the user requests deployment actions such as "Deploy my app", "Deploy this to production", "Create a preview deployment", "Deploy and give me the link", or "Push this live". No authentication required - returns preview URL and claimable deployment link.★ 83.5k GitHub starsSkillOpen or update a pull request on pascalorg/editorOpen PRpascalorg/editor · by pascalorgOpen or update a pull request on pascalorg/editor from the current branch, describing only what the branch actually did. Use when the user asks to open/create a PR, push and PR, or ship a branch in the editor repo.★ 24.6k GitHub stars

More from obra

SkillBrainstorms ideas into designs before any creative workBrainstorming Ideas Into Designsobra/superpowers · by obraYou MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.★ 290k GitHub starsSkillRequires technical rigor and verificationCode Review Receptionobra/superpowers · by obraUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation★ 290k GitHub starsSkillDispatches parallel agentsDispatching parallel agentsobra/superpowers · by obraUse when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies★ 290k GitHub starsSkillExecutes plans with review checkpointsExecuting plansobra/superpowers · by obraUse when you have a written implementation plan to execute in a separate session with review checkpoints★ 290k GitHub starsSkillFinishes a development branchFinishing a development branchobra/superpowers · by obraUse when implementation is complete, all tests pass, and you need to decide how to integrate the work★ 290k GitHub starsSkillRequests code review before mergingRequesting code reviewobra/superpowers · by obraUse when completing tasks, implementing major features, or before merging to verify work meets requirements★ 290k GitHub stars