using-git-worktrees
An agent skill by obra, from obra/superpowers. Tags: api, developer-tools, web.
What it does
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
Install
With the skills CLI, which installs into Claude Code, Codex, Cursor and other agents:
npx skills add obra/superpowers --skill using-git-worktrees
Or copy the skill folder into Claude Code's skills directory by hand (~/.claude/skills for every project, or .claude/skills inside one):
git clone --depth 1 https://github.com/obra/superpowers
cp -r superpowers/skills/using-git-worktrees ~/.claude/skills/using-git-worktrees
Safety box score
Grade B, low risk: 18 of 100 risk points, rated 2026-10-16. The grade rates what the skill and its scripts can reach on the machine of whoever installs it, across eight categories from shell execution to secrets access. How the score works.
This skill mainly manages Git worktrees and then auto-runs project setup/test commands. The main risks are local command execution, network fetches from package managers, and automatic repo state changes such as creating a worktree or editing `.gitignore`/committing it.
| Category | Level | Why |
|---|---|---|
| Code & shell execution | 2 (moderate) | It explicitly runs shell commands for setup and verification, including `npm install`, `cargo build`, `pip install -r requirements.txt`, `poetry install`, `go mod download`, and project tests. |
| Network access | 2 (moderate) | The setup commands can reach package registries and remote module sources, especially `npm install`, `pip install -r requirements.txt`, `poetry install`, and `go mod download`. |
| Filesystem reach | 1 (low) | It creates and changes into a new worktree directory with `git worktree add "$path" -b "$BRANCH_NAME"`, and may edit `.gitignore` and commit that change if the worktree directory is not ignored. |
| Secrets & credentials | 0 (none) | The skill does not request tokens, passwords, key files, `.env` files, or other credential stores. |
| Privilege & persistence | 0 (none) | It does not ask for sudo, global installs, services, shell startup edits, or other privilege changes. |
| Instruction hijack surface | 0 (none) | It contains operational guidance like “Never fight the harness,” but no instruction to ignore higher-priority rules, hide actions, or follow remote prompt text. |
| Irreversible actions | 0 (none) | It automates local workspace setup, but it does not push, deploy, publish, message, pay, or delete anything external. |
| Transparency | 0 (none) | The skill is plain markdown; there are no binaries, hidden payloads, or downloaded/unread code paths. |
Before installing
- Check whether you are comfortable with the skill automatically running `npm install`/`pip install`/`poetry install`/`go mod download` in this repo.
- Verify whether `.worktrees/` or `worktrees/` is already ignored; otherwise the skill may modify `.gitignore` and commit it.
- If you want a controlled trial, run it once in a throwaway clone or branch and watch the exact commands it executes.
Rated 2026-10-16 by an automated review of 1 file from the skill's repository.
Source
- Repository
- obra/superpowers (all skills from this repository)
- Path
- skills/using-git-worktrees/SKILL.md
- Branch
- main
- Updated
- 2026-09-19
Related skills
- executing-plans — Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution.
- finishing-a-development-branch — Use when implementation is complete, all tests pass, and you need to decide how to integrate the work
- receiving-code-review — Use when receiving code review feedback, before implementing suggestions.
- requesting-code-review — Use when completing tasks, implementing major features, or before merging to verify work meets requirements
- systematic-debugging — Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
- test-driven-development — Use when implementing any feature or bugfix, before writing implementation code