一键导入
nobody-uses-git-worktrees
Use when starting feature work that needs isolation from current workspace or before executing implementation plans
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when starting feature work that needs isolation from current workspace or before executing implementation plans
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | nobody-uses-git-worktrees |
| description | Use when starting feature work that needs isolation from current workspace or before executing implementation plans |
Git worktrees create isolated workspaces sharing the same repository. Work on multiple branches simultaneously without switching.
Announce at start: "I'm using the nobody-uses-git-worktrees skill to set up an isolated workspace."
Check in priority order:
ls -d .worktrees worktrees 2>/dev/nullFor project-local directories, verify they're gitignored:
git check-ignore -q .worktrees 2>/dev/null
If NOT ignored: add to .gitignore and commit before proceeding.
# 1. Create worktree with new branch
git worktree add .worktrees/feature-name -b feature/feature-name
# 2. Enter workspace
cd .worktrees/feature-name
# 3. Run project setup (auto-detect)
[ -f package.json ] && npm install
[ -f requirements.txt ] && pip install -r requirements.txt
[ -f Cargo.toml ] && cargo build
# 4. Verify clean baseline
# Run project-appropriate test command
Worktree ready at <full-path>
Tests passing (<N> tests, 0 failures)
Ready to implement <feature-name>
If tests fail: report failures, ask whether to proceed.
When done, use the nobody-finishes-a-development-branch skill, then:
git worktree remove .worktrees/feature-name
Use when doing any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when you have a written implementation plan to execute with review checkpoints
Use when implementation is complete and all tests pass — guides completion by presenting structured options for merge, PR, or cleanup
Use when receiving code review feedback, before implementing suggestions — requires technical rigor and verification, not performative agreement
Use when completing tasks, implementing major features, or before merging to verify work meets requirements