plugins/dev-tools/skills-pi/using-git-worktrees/SKILL.md
Creates isolated git worktrees for parallel development. Use when starting feature work needing isolation or working on multiple branches simultaneously. Not for simple branch switching or basic git operations.
npx skillsauth add alexei-led/claude-code-config using-git-worktreesInstall 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.
Main repo stays on main/master — never edit directly. Every branch gets its own worktree (a sibling folder). Delete the worktree after the branch merges.
Think of a worktree as a disposable branch folder, not a long-lived parallel environment.
Exception: Trivial one-liner commits on a solo project can go directly on main to avoid ceremony overhead.
Check repo state before creating a worktree. Any worktree workflow description must name this dirty-state check before git worktree add:
git status --short
git branch --show-current
git worktree list
If the current worktree is dirty, ask whether to commit, stash, or create the new worktree anyway before proceeding. Confirm before running cleanup commands that remove worktrees or delete branches.
# 1. Create worktree for new work (from main repo)
git worktree add ../myproject-fix-cron -b fix-cron
# 2. Work there (open editor/Claude Code in that folder)
cd ../myproject-fix-cron
# 3. After PR is merged — confirm cleanup, then run from main repo
cd ../myproject
git worktree remove ../myproject-fix-cron
git branch -d fix-cron
git pull
Worktrees are sibling directories (not nested inside the repo):
~/projects/
├── myproject/ # main worktree — always on main, always clean
├── myproject-fix-cron/ # worktree for fix-cron branch
└── myproject-add-model/ # worktree for add-model branch
Why siblings: no .gitignore pollution, clean git status, independent build artifacts.
<project>-<branch-slug> — slashes become dashes, self-documenting.
| Branch | Worktree Directory |
| ------------------ | --------------------------- |
| fix-cron | ../myproject-fix-cron |
| feature/auth | ../myproject-feature-auth |
| bugfix/issue-123 | ../myproject-bugfix-123 |
tools
Use when planning, executing, checkpointing, finishing, or inspecting lightweight spec-driven work. Runs one task at a time using `.spec/` markdown files and the bundled `specctl` helper. NOT for broad product discovery beyond a short requirement interview. NOT for generic implementation planning that does not read or write `.spec/` files.
development
Simple web development with HTML, CSS, JS, and HTMX. Use when working with .html, .css, or .htmx files, web templates, stylesheets, or vanilla JS scripts. NOT for React/Vue/Angular (use writing-typescript) or Node.js backends.
tools
Idiomatic TypeScript development. Use when writing TypeScript code, Node.js services, React apps, or TypeScript design advice. Emphasizes strict typing, boundary validation, composition, fast feedback, behavior tests, and project-configured tooling. NOT for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates (use writing-web).
tools
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, CI `run:` shell bodies, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, Rust, TypeScript, Go, web code, or GitHub Actions workflow/job/permissions semantics; use operating-infra.