Developer pack
Claude Skill
Git Worktree Workflow
Sets up an isolated git worktree so parallel feature work, reviews, and AI agents don't trample your main checkout.
What it does
Detects whether you're already isolated, then creates a properly-ignored git worktree for the task so a branch, a code review, or an AI agent runs in its own working directory — no stashing, no losing your place on the main checkout. Handles the submodule edge cases and the cleanup at the end.
When to use
- ✓Starting feature work while keeping your main checkout on another branch
- ✓Running an AI agent that edits files and you want it sandboxed
- ✓Reviewing a PR without stashing your in-progress work
When not to use
- ✗A tiny single-file change you'll commit in a minute
- ✗Your harness already provides native worktree isolation — use that instead
Install
Download the .zip, then unzip into your Claude skills folder.
mkdir -p ~/.claude/skills
unzip ~/Downloads/git-worktree-workflow.zip -d ~/.claude/skills/
# Restart Claude Code session.
# Skill is now available — Claude will use it when relevant.SKILL.md
SKILL.md
---
name: git-worktree-workflow
description: Use when starting work that needs isolation from the current checkout — parallel branches, reviewing a PR, or sandboxing an AI agent. Triggers on "git worktree", "isolated workspace", "without stashing", "work on two branches at once".
---
# Git Worktree Workflow
A worktree gives a branch its own directory backed by the same repo, so you can have main and a feature branch checked out at once — no stashing, no context loss. The failure mode is creating one when you're already isolated, or creating one your harness can't see.
## Step 0 — Detect existing isolation first
Before creating anything, check whether you're already in a linked worktree:
- Compare the git dir to the common git dir; if they differ you may already be in a worktree.
- **Submodule guard:** that same condition is true inside a submodule. Confirm you're not in one before concluding you're isolated.
- If you're already isolated, stop — don't nest a second worktree. Skip to project setup.
## Step 1 — Prefer native tooling
If your environment offers a native worktree mechanism (a dedicated tool, command, or `--worktree` flag), use it. It handles directory placement, branch creation, and cleanup, and stays visible to the harness. Hand-rolling `git worktree add` when a native tool exists creates phantom state the harness can't manage.
## Step 2 — Manual fallback (only if no native tool)
- **Get consent** before creating a worktree if the user hasn't already asked for one.
- **Pick a directory:** honor any declared preference; otherwise default to a project-local `.worktrees/` at the repo root.
- **Verify it's ignored** before creating the worktree, so you don't commit the worktree into the repo it lives in.
## Step 3 — Finish cleanly
When the work is done: merge or open the PR, then remove the worktree and prune. Don't leave orphaned worktrees accumulating.
## Anti-patterns
- Creating a worktree when you're already in one (check Step 0)
- Mistaking a submodule for a worktree
- `git worktree add` when a native tool was available
- A project-local worktree dir that isn't git-ignored
- Leaving stale worktrees behind after the branch merges
Example prompts
Once installed, try these prompts in Claude:
- Set up an isolated worktree for a refactor so my main checkout stays on the release branch.
- I keep stashing to review PRs. Set up a worktree workflow so I can check out branches side by side.