skills/worktree-cleanup/SKILL.md
Removes git worktrees safely, cleans up associated branches, and pulls latest mainline after removal. Use when finished with a worktree, done with a branch, cleaning up after a merge or PR, abandoning work in a worktree, or when "git worktree list" shows stale entries. Checks for uncommitted changes, verifies no open PRs before branch deletion, and handles force-removal of locked worktrees.
npx skillsauth add shousper/claude-kit worktree-cleanupInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Clean up a git worktree after work is complete (merged, PR created, or abandoned). Updates the mainline branch so local state is current.
Core principle: User-triggered only. Never automatic.
git worktree list
If multiple worktrees exist (beyond the main working tree), present the list and ask which to clean up.
If only one non-main worktree exists, confirm: "Remove worktree at <path>?"
git -C <worktree-path> status --porcelain
If dirty:
⚠️ CRITICAL — cd before removal: You MUST determine the main working tree path and cd to it BEFORE running any removal command. Always chain the cd and removal in the SAME Bash call using &&. Never run them as separate Bash tool calls — shell CWD persists between calls, but a deleted CWD will brick every subsequent command.
First, capture the main working tree path from Step 1's output (the first entry in git worktree list).
Then remove:
cd <main-working-tree> && git worktree remove <worktree-path>
If removal fails (e.g., locked or dirty), try with --force after informing your human partner:
cd <main-working-tree> && git worktree remove --force <worktree-path>
If the worktree directory was already manually deleted from disk, clean up stale metadata:
cd <main-working-tree> && git worktree prune
If any Bash command fails with Path "..." does not exist, your shell CWD has been deleted from disk. Do NOT retry the same command. You MUST prefix your next command with an absolute cd:
cd <main-working-tree> && git worktree prune && git worktree list
The main working tree path (first entry from Step 1) is always valid. Use that. Retrying without the cd prefix will fail infinitely.
If the worktree's branch has been merged or your human partner chose "discard":
git branch -d <branch-name> # safe delete (only if merged)
If not merged and user wants to delete:
git branch -D <branch-name> # force delete — confirm first
Check for open PRs before deleting:
gh pr list --head <branch-name> --state open --json number --jq 'length'
If the result is non-zero, skip branch deletion — the branch is still needed for the open PR.
Determine the mainline branch:
git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@'
Fallback: check for main then master.
If currently on mainline:
git pull --autostash
If --autostash fails or there are staged changes:
git stash
git pull --ff-only
git stash pop
If pull can't fast-forward: inform your human partner. Do not force-merge or rebase without asking.
If NOT on mainline: offer to switch.
Would you like to switch to <mainline> and pull latest?
Never:
git worktree remove without cd <main-tree> && prefix in the same commandcd-ing to a valid absolute path — if you get "Path does not exist", your CWD is goneAlways:
cd <main-working-tree> && before every removal/prune command| Command | Purpose |
|---|---|
| git worktree list | List all worktrees |
| git -C <path> status --porcelain | Check for uncommitted changes |
| git worktree remove <path> | Remove a worktree |
| git worktree remove --force <path> | Force-remove (locked/dirty worktree) |
| git worktree prune | Clean up stale worktree metadata |
| git branch -d <branch> | Safe-delete merged branch |
| git branch -D <branch> | Force-delete unmerged branch |
| gh pr list --head <branch> --state open --json number --jq 'length' | Check for open PRs on branch |
Pairs with:
development
Creates, edits, and tests Claude skill files (SKILL.md) using TDD methodology with baseline pressure testing and rationalization defense. Use when writing a new skill, modifying an existing skill, optimizing a skill description for discovery (CSO), testing whether a skill triggers correctly, or structuring skill documentation. Enforces RED-GREEN-REFACTOR for process documentation.
development
Creates detailed, bite-sized implementation plans with TDD structure, exact file paths, complete code, and test commands. Use when you have a spec, requirements, design doc, or feature request and need to plan before coding — especially for multi-step tasks, large features, or when handing off to another session. DO NOT TRIGGER when asked to write code directly or fix a simple bug.
development
Enforces fresh verification evidence before any completion or success claims. Use when about to say "done", "fixed", "tests pass", "build succeeds", or any synonym; before committing, creating PRs, or moving to the next task; before expressing satisfaction or positive statements about work state; and after agent delegation to independently verify results. Prevents unverified claims by requiring command execution, output inspection, and exit code confirmation.
development
Enforces skill discovery and invocation governance for every task. Use at the start of any conversation, before responding to any user message, when deciding whether a skill applies, when building or modifying features (triggers the brainstorming chain), or when operating within a team context. Defines the default workflow chain (brainstorming -> writing-plans -> team-dev -> finish-branch) and prevents rationalizing away skill usage.