bundles/github/skills/worktree/SKILL.md
Create an isolated git worktree from the correct base branch and check it out into a clean, gitignored directory. Use when the user asks to make a worktree, spin up a parallel/isolated workspace, work on something without disturbing the current checkout, branch off the current work, or run multiple agents on the same repo at once. Picks the base branch smartly — the current feature branch when you are on one, otherwise the develop integration branch — so worktrees continue your in-progress work by default instead of forking from the wrong place.
npx skillsauth add shipshitdev/library worktreeInstall 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.
Create a git worktree off the right base branch, in a clean gitignored
directory, with the safety checks that keep the main checkout and .gitignore
correct. This skill only creates and lists worktrees. Removing and
pruning merged worktrees is release-cleanup's job — do not delete here.
Inputs:
from <base> / --base <base>)--fetch flag to refresh the base from origin before branchingOutputs:
.worktrees/<name> checked out on a new branchcd into, ready for a parallel sessionCreates/Modifies:
.worktrees/ to .gitignore and commits that change if not already ignoredExternal Side Effects:
--fetch: a single git fetch origin <base> to refresh the base refConfirmation Required:
.gitignore and committing it (one-time, only if .worktrees/ is not yet ignored)Delegates To:
release-cleanup to verify promotion and prune merged worktrees and branchesgit-safety if a branch about to live in a worktree may contain secretsThe base is resolved in this order. Local tips only — no automatic fetch.
/worktree fix-auth from develop
or --base release/1.4), use it verbatim.develop. If the
current branch is master, main, develop, or staging, or HEAD is
detached, fork from the integration branch instead of an integration branch's
tip-as-feature. Prefer local develop; if no develop exists, fall back to
the repository's default branch.current branch -> base the worktree forks from
---------------------- ----------------------------
feat/foo (feature) -> feat/foo (continue current work)
bugfix/x (feature) -> bugfix/x (continue current work)
master / main -> develop (or default branch if no develop)
develop / staging -> develop
detached HEAD -> develop (or default branch if no develop)
explicit "from <base>" -> <base> (always wins)
Protected/integration set (never used as a "feature" base in step 2):
master main develop staging
git rev-parse --is-inside-work-tree # must be true; else STOP
TOPLEVEL="$(git rev-parse --show-toplevel)"
CURRENT="$(git symbolic-ref --quiet --short HEAD || echo DETACHED)"
git worktree list # show what already exists
Resolve the new branch name:
feat/foo
becomes directory .worktrees/feat-foo while the branch stays feat/foo).PROTECTED='master|main|develop|staging'
# Integration fallback, resolved to a ref that actually exists locally.
# Prefer local develop, then the remote-tracking origin/develop (still local,
# no fetch), then the repo's default branch.
if git show-ref --verify --quiet refs/heads/develop; then
FALLBACK=develop
elif git show-ref --verify --quiet refs/remotes/origin/develop; then
FALLBACK=origin/develop # new branch will fork from and track origin/develop
else
DEF="$(git symbolic-ref --quiet --short refs/remotes/origin/HEAD | sed 's#^origin/##')"
DEF="${DEF:-master}"
git show-ref --verify --quiet "refs/heads/$DEF" && FALLBACK="$DEF" || FALLBACK="origin/$DEF"
fi
# Apply the precedence. BASE is the start-point ref passed to `git worktree add`.
if [ -n "$EXPLICIT_BASE" ]; then
BASE="$EXPLICIT_BASE"
elif printf '%s\n' "$CURRENT" | grep -qxE "$PROTECTED" || [ "$CURRENT" = DETACHED ]; then
BASE="$FALLBACK" # on a protected/detached ref -> integration branch
else
BASE="$CURRENT" # on a feature branch -> continue current work
fi
echo "Base: $BASE (current: $CURRENT)"
BASE is always a concrete start-point (a local branch like develop, a
remote-tracking ref like origin/develop, or the user's explicit base). Report
the resolved base and the reason before creating anything.
Local mode is the default: branch from the local tip of $BASE. If the base has
an upstream and is behind it, warn — do not silently fetch.
if git rev-parse --verify --quiet "$BASE@{upstream}" >/dev/null; then
BEHIND="$(git rev-list --count "$BASE..$BASE@{upstream}" 2>/dev/null || echo 0)"
[ "$BEHIND" -gt 0 ] && echo "WARNING: local $BASE is $BEHIND commit(s) behind its remote. Using local tip. Pass --fetch to update first."
fi
Only if the user passed --fetch:
git fetch origin "$BASE"
git update-ref "refs/heads/$BASE" "origin/$BASE" # only when safe / fast-forward
Do not fetch by default. Do not rewrite a base branch that has local commits not on the remote — warn and use the local tip instead.
.worktrees/ Is GitignoredThe worktree directory must never be tracked. Verify, and fix once if needed.
if ! git -C "$TOPLEVEL" check-ignore -q .worktrees; then
# .worktrees/ is not ignored yet — confirm, then add and commit
printf '\n# Local git worktrees (created by the worktree skill)\n.worktrees/\n' >> "$TOPLEVEL/.gitignore"
git -C "$TOPLEVEL" add .gitignore
git -C "$TOPLEVEL" commit -m "chore: ignore .worktrees/ directory"
fi
This is the only commit the skill makes, and only the first time in a repo. Confirm before committing in a shared repo.
NAME="<sanitized-name>"
BRANCH="<new-branch-name>"
DEST="$TOPLEVEL/.worktrees/$NAME"
# Guard: destination must not already exist
[ -e "$DEST" ] && { echo "Path exists: $DEST — choose another name or remove it first."; exit 1; }
if git show-ref --verify --quiet "refs/heads/$BRANCH"; then
# Branch already exists: confirm, then attach it (no -b, no new branch)
git worktree add "$DEST" "$BRANCH"
else
# New branch off the resolved local base tip
git worktree add -b "$BRANCH" "$DEST" "$BASE"
fi
git worktree list
Rules:
-b only when creating a new branch. If the branch exists, attach it and
say so — never silently reset an existing branch.$BRANCH is
already checked out elsewhere, report where and stop.--force. If git refuses, surface the reason and let the user decide.Report:
.worktrees/<name>cd .worktrees/<name> and open a parallel session in
that directory. Each worktree is an independent checkout sharing one .git.node_modules).worktree <name> — create a worktree named <name> on a new branch <name>,
base resolved by the smart rules above. (Default.)worktree <name> from <base> / worktree <name> --base <base> — force the base.worktree <name> --fetch — refresh the base from origin before branching.worktree list — list existing worktrees and their branches; create nothing.When the user scopes it differently ("off master", "use my current branch", "don't touch gitignore"), honor the scope but keep the safety checks that prevent tracking the worktree dir or clobbering an existing branch/path.
.worktrees/ is verified ignored first.--fetch.--force, never reset an existing branch, never overwrite an existing
path. On conflict, report and stop.release-cleanup.development
Verify a release was fully promoted through develop, staging, and master/main, then prune merged local and remote branches and stale git worktrees. Squash-merge aware — uses GitHub PR merge state as the merge oracle, not commit ancestry. Use when the user asks to clean up branches after a deploy, prune worktrees, remove merged branches, tidy up after promoting develop to staging to master, or confirm nothing stale was left behind before pruning.
development
Structured "done coding, now what?" workflow: verify tests pass, detect the repository environment (normal repo vs worktree, named branch vs detached HEAD), present exactly the right merge / PR / keep / discard options, and execute the chosen path including safe worktree cleanup. Use when implementation is complete and the branch needs to be integrated, published, or abandoned.
tools
Capture a client or stakeholder feature request, turn it into a planner-ready PRD epic with scoped sub-issues, check for duplicate work, and place approved issues on a GitHub Projects kanban. Use when a user invokes feature intake, asks to turn a rough client requirement into GitHub issues, or wants an idea written as a PRD and pushed to a board.
tools
Provides Tailwind CSS v4 performance optimization and best practices guidelines. Triggers when writing, reviewing, or refactoring Tailwind CSS v4 code; when working with Tailwind configuration, @theme directive, utility classes, responsive design, dark mode, container queries, or CSS generation optimization.