| name | using-git-worktrees |
| description | Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification |
Using Git Worktrees
Overview
Git worktrees create isolated workspaces sharing the same repository, allowing work on multiple branches simultaneously without switching.
Core principle: Systematic directory selection + safety verification = reliable isolation.
Announce at start: "I'm using the using-git-worktrees skill to set up an isolated workspace."
In a mothership workspace
If a mothership.yaml is present at any ancestor directory, use mship spawn instead of the steps below — but every task needs a WorkItem first: mship item new "<title>" --kind <feature|bug|chore|question> (prints an id), then mship spawn '<description>' --work-item <id>. spawn refuses without --work-item (--hotfix overrides, logged). mship spawn creates the worktree, registers it in workspace state, runs per-repo task setup, and (where configured) symlinks heavy directories. The Directory Selection, Safety Verification, and Creation Steps sections below apply only when you're not spawning a mship task (e.g., quick read-only exploration or a non-mship repo).
Directory Selection Process
Follow this priority order:
1. Check Existing Directories
ls -d .worktrees 2>/dev/null
ls -d worktrees 2>/dev/null
If found: Use that directory. If both exist, .worktrees wins.
2. Check CLAUDE.md
grep -i "worktree.*director" CLAUDE.md 2>/dev/null
If preference specified: Use it without asking.
3. Ask User
If no directory exists and no CLAUDE.md preference:
No worktree directory found. Where should I create worktrees?
1. .worktrees/ (project-local, hidden) [default]
2. worktrees/ (project-local, visible)
Which would you prefer?
Safety Verification
For Project-Local Directories (.worktrees or worktrees)
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:
Per Jesse's rule "Fix broken things immediately":
- Add appropriate line to .gitignore
- Commit the change
- Proceed with worktree creation
Why critical: Prevents accidentally committing worktree contents to repository.
Creation Steps
1. Detect Project Name
project=$(basename "$(git rev-parse --show-toplevel)")
2. Create Worktree
For non-mship workflows, create the worktree directly:
LOCATION="${LOCATION:-.worktrees}"
path="$LOCATION/$BRANCH_NAME"
git worktree add "$path" -b "$BRANCH_NAME"
cd "$path"
3. Run Project Setup
Auto-detect and run appropriate setup:
if [ -f package.json ]; then npm install; fi
if [ -f Cargo.toml ]; then cargo build; fi
if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
if [ -f pyproject.toml ]; then poetry install; fi
if [ -f go.mod ]; then go mod download; fi
4. Verify Clean Baseline
Run tests to ensure worktree starts clean:
npm test
cargo test
pytest
go test ./...
If tests fail: Report failures, ask whether to proceed or investigate.
If tests pass: Report ready.
5. Report Location
Worktree ready at <full-path>
Tests passing (<N> tests, 0 failures)
Ready to implement <feature-name>
Quick Reference
| Situation | Action |
|---|
.worktrees/ exists | Use it (verify ignored) |
worktrees/ exists | Use it (verify ignored) |
| Both exist | Use .worktrees/ |
| Neither exists | Check CLAUDE.md → Ask user |
| Directory not ignored | Add to .gitignore + commit |
| Tests fail during baseline | Report failures + ask |
| No package.json/Cargo.toml | Skip dependency install |
Common Mistakes
Skipping ignore verification
- Problem: Worktree contents get tracked, pollute git status
- Fix: Always use
git check-ignore before creating project-local worktree
Assuming directory location
- Problem: Creates inconsistency, violates project conventions
- Fix: Follow priority: existing > CLAUDE.md > ask
Proceeding with failing tests
- Problem: Can't distinguish new bugs from pre-existing issues
- Fix: Report failures, get explicit permission to proceed
Hardcoding setup commands
- Problem: Breaks on projects using different tools
- Fix: Auto-detect from project files (package.json, etc.)
Example Workflow
You: I'm using the using-git-worktrees skill to set up an isolated workspace.
[Detect: mothership.yaml found at /abs/workspace — routing through mship spawn]
[Run: mship item new "auth middleware" --kind feature] # → wi-20260703-a1b2c3
[Run: mship spawn "implement auth middleware" --work-item wi-20260703-a1b2c3 --repos auth-service]
[mship creates worktree at .worktrees/implement-auth-middleware/auth-service, runs task setup]
[Run: mship test (baseline check)]
Worktree ready at /abs/workspace/.worktrees/implement-auth-middleware/auth-service
Tests passing (47 tests, 0 failures)
Ready to implement auth middleware
Red Flags
Never:
- Create worktree without verifying it's ignored (project-local)
- Skip baseline test verification
- Proceed with failing tests without asking
- Assume directory location when ambiguous
- Skip CLAUDE.md check
Always:
- Follow directory priority: existing > CLAUDE.md > ask
- Verify directory is ignored for project-local
- Auto-detect and run project setup
- Verify clean test baseline
Integration
Called by:
- brainstorming (Phase 4) - REQUIRED when design is approved and implementation follows
- subagent-driven-development - REQUIRED before executing any tasks
- executing-plans - REQUIRED before executing any tasks
- Any skill needing isolated workspace
Pairs with:
- finishing-a-development-branch - REQUIRED for cleanup after work complete (uses
mship close in mothership workspaces; manual git worktree remove otherwise)