Skip to main content
skill Claude Code CX Codex

using-git-worktrees — Claude Code skill: install and use

Prepares an isolated workspace before feature work or plan execution. It checks the repository first, then uses native worktree support or Git.

Install into Claude Code · Plugin marketplace All methods and platforms ↓
/plugin marketplace add obra/superpowers
/plugin install superpowers@superpowers-dev
Open on GitHub

What using-git-worktrees does

The skill first checks whether the agent already runs in a linked worktree and distinguishes that state from a submodule. When isolation already exists, it does not create another tree. In a normal checkout, it asks for consent unless a worktree preference is already set.

It uses a platform-native worktree tool when one exists. Otherwise, it looks for .worktrees or worktrees, verifies the directory with git check-ignore, then creates a branch with git worktree add. If sandbox permissions block creation, it continues in the current directory.

Next, the skill installs project dependencies for Node.js, Rust, Python, or Go, then runs the relevant test command. Failed baseline tests are reported for a decision before work continues. Install it when feature changes must stay off your current branch; skip it for edits meant for the current checkout.

What it helps with

  • create a separate worktree for a feature
  • detect an existing linked worktree
  • tell a submodule from a Git worktree
  • check whether .worktrees is ignored
  • run dependency setup and baseline tests

Example prompts for the agent

  • Set up an isolated worktree for this feature.
  • Check whether I am already in a worktree before executing the plan.
  • Create a worktree in `.worktrees` and run `npm test`.

How to install using-git-worktrees

1Plugin marketplace

/plugin marketplace add obra/superpowers
/plugin install superpowers@superpowers-dev

This installs the whole superpowers plugin with all its skills

2Skills CLI (Vercel)

npx skills add obra/superpowers --skill using-git-worktrees -a claude-code

3Manually: put the files in place

~/.claude/skills/using-git-worktrees/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/using-git-worktrees/

From the same set16

The whole set →
brainstorming Jesse Vincent This skill clarifies a task before implementation by asking questions, checking context, and comparing approaches. Use it for new features and other creative work. Claude Code CX Codex 404,045installs systematic-debugging Jesse Vincent Makes the agent investigate the cause of a failure before it suggests a patch. Use it for failing tests, build errors, and behaviour that does not match expectations. Claude Code CX Codex 306,118installs writing-plans Jesse Vincent This skill turns requirements for a multi-step task into an implementation plan before code changes begin. It helps when another engineer needs exact files, interfaces, and checks. Claude Code CX Codex 282,859installs using-superpowers Jesse Vincent Checks for relevant skills before an agent responds or takes action. Use it when you want a fixed workflow for handling tasks. Claude Code CX Codex 270,479installs requesting-code-review Jesse Vincent Sends completed work to a reviewer subagent after a task, major feature, or before merging to main. It keeps the review focused on the change and its requirements. Claude Code CX Codex 262,135installs test-driven-development Jesse Vincent This skill guides an agent through test-first development: verify a test fails, write the smallest passing change, then refactor. It covers features, bug fixes, and behavior changes. Claude Code CX Codex 259,292installs verification-before-completion Jesse Vincent This skill blocks completion claims until the agent runs a fresh check and reads the result. Use it before commits or PRs when an agent report is not enough. Claude Code CX Codex 251,313installs executing-plans Jesse Vincent Runs an implementation plan in the current session instead of assigning each task to a subagent. Use it for inline work with TDD, a decision ledger, and a final branch review. Claude Code CX Codex 242,988installs

Similar

implement-spec Matt Pocock Implements a prepared spec from its ticket graph on one integration branch, using parallel subagents. Use it when tickets have blocking dependencies. Claude Code 283,700installs orca-cli stablyai The skill lets an agent manage Orca worktrees, terminals, artifacts and the built-in browser through the orca CLI. Useful when your work already runs inside Orca. Claude Code CX Codex Cursor +1 353,000installs triage Matt Pocock This skill moves issues and external PRs through triage states, verification, and agent briefs. It fits maintainers managing an issue queue. Claude Code 990,453installs code-review Matt Pocock Reviews changes from a chosen reference point against repository standards and the originating spec. Use it for a branch, PR, or work in progress. Claude Code 789,521installs implement Matt Pocock Implements work from a specification or tickets, following a test-driven flow and ending with review and a commit. Use it when a coding task needs a defined delivery routine. Claude Code 774,700installs git-guardrails-claude-code Matt Pocock This skill adds a Claude Code hook that stops risky Git commands before they run. Use it when an agent must not push or discard working-tree changes. Claude Code 499,069installs setup-pre-commit Matt Pocock This skill configures pre-commit checks for a JavaScript repository, running Prettier, type checking, and tests before each commit. Claude Code 489,289installs scaffold-exercises Matt Pocock This skill builds course exercise directories with sections, problems, solutions, and explainers. Use it when starting a new course section or creating exercise stubs. Claude Code 480,196installs

Questions about using-git-worktrees

How do I install using-git-worktrees in Claude Code?

Install the skill with npx skills add obra/superpowers --skill using-git-worktrees -a claude-code. You can also use /plugin marketplace add obra/superpowers followed by /plugin install superpowers@superpowers-dev.

What does using-git-worktrees do?

It prepares an isolated Git workspace for development tasks. The skill prefers a platform-native worktree mechanism and falls back to git worktree when needed.

What happens if baseline tests fail?

The skill reports the failures and asks whether to continue or investigate them first.

Source text

SKILL.md · MIT
---
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.**

```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)
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:

```bash
# 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:**
   ```bash
   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:**

```bash
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

```bash
# 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:

```bash
# 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:

```bash
# 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. |

© Jesse Vincent · MIT · obra/superpowers

See also

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor