菜单
Git worktree management best practices for git worktree, bare repo layouts, parallel branches, stale base sync, branch cleanup, wrong-path recovery, fork remotes, and PR review worktrees. Use when creating, moving, removing, repairing, listing, pruning, or troubleshooting Git worktrees.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
GitHub Actions CI/CD best practices for .github/workflows/*.yml, workflow_call, release, deploy, test, build, and pipeline automation. Use when writing, reviewing, or fixing GitHub Actions workflows. Enforce thin workflows: GitHub Actions only orchestrates checkout, setup, auth, cache, artifacts, env, and calls Taskfile tasks; real pipeline logic belongs in Taskfile.yml or specific Taskfile.*.yml files. Load taskfile skill when creating or editing those tasks.
Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Focuses on recently modified code unless instructed otherwise. Trigger on requests like "simplify this code", "clean up", "refactor for clarity", "make this more readable", or after writing significant code that could benefit from refinement.
Build dagger.io-inspired project landing pages and documentation sites using pure CSS (CSS Layers, OKLCH colors, BEM naming). Use when creating marketing websites, project homepages, docs sites, or landing pages that follow the dagger.io aesthetic: warm cream canvas, navy ink, generous whitespace, rounded white cards. Triggers: "landing page", "project site", "docs site", "dagger style", "marketing page", "product page", "harbor satellite site", or building any static site with this visual language. Works with Hugo or standalone HTML. Do NOT use for dashboard/app UI.
Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.
Write idiomatic, production-grade Go code following Google's Go Style Guide. Use when writing, reviewing, or refactoring any Go (.go) code including libraries, CLI tools, servers, and tests. Triggers: any Go code generation, "write Go", "Go function", "Go package", "Go test", "refactor Go", "review Go code", "fix Go style", "idiomatic Go", or producing .go files. Do NOT use for non-Go languages.
Compact the current conversation into a handoff document for another agent to pick up.
| name | git-worktree-management |
| description | Git worktree management best practices for git worktree, bare repo layouts, parallel branches, stale base sync, branch cleanup, wrong-path recovery, fork remotes, and PR review worktrees. Use when creating, moving, removing, repairing, listing, pruning, or troubleshooting Git worktrees. |
Goal: one branch, one folder. No branch switching in busy repos.
Prefer bare repo with sibling worktrees:
~/code/repo/
.bare/
main/
feature-x/
bugfix-y/
Why: parallel work, clean IDE indexes, no stash dance, fast hotfix/review folders.
mkdir -p ~/code/repo
git clone --bare git@github.com:owner/repo.git ~/code/repo/.bare
git -C ~/code/repo/.bare config remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
git -C ~/code/repo/.bare fetch origin
git -C ~/code/repo/.bare worktree add ~/code/repo/main origin/main
Use real default branch. Do not assume main:
gh repo view owner/repo --json defaultBranchRef --jq '.defaultBranchRef.name'
Always sync base first:
git -C ~/code/repo/.bare fetch origin main:refs/remotes/origin/main
git -C ~/code/repo/.bare worktree add -b feature-x ~/code/repo/feature-x origin/main
Use absolute paths when an agent/script runs command. Relative paths with git -C .bare resolve relative to .bare, not shell cwd.
Wrong:
git -C .bare worktree add -b feature-x feature-x main
Right:
git -C ~/code/repo/.bare worktree add -b feature-x ~/code/repo/feature-x origin/main
Existing branch:
git -C ~/code/repo/.bare fetch origin feature-x
git -C ~/code/repo/.bare worktree add ~/code/repo/feature-x origin/feature-x
Detached review worktree:
git -C ~/code/repo/.bare worktree add --detach ~/code/repo/review-pr origin/feature-x
git worktree list before adding/removing.--force unless command explains why..bare/.git fetch origin
git rebase origin/main
task ci
Replace task ci with repo check command. Real command must fail loud.
After PR merged:
git -C ~/code/repo/.bare worktree remove ~/code/repo/feature-x
git -C ~/code/repo/main branch -D feature-x
git -C ~/code/repo/main fetch --prune origin
git -C ~/code/repo/.bare worktree prune
If directory was deleted manually:
git -C ~/code/repo/.bare worktree prune
If worktree moved manually:
git -C ~/code/repo/.bare worktree repair ~/code/repo/new-path
If worktree got created inside .bare/:
git -C ~/code/repo/.bare worktree move ~/code/repo/.bare/feature-x ~/code/repo/feature-x
Use absolute source and dest.
When pushing to non-tracking remote, use explicit refspec:
git push fork HEAD:main
Do not trust:
git push fork main
It can be a silent no-op when local branch tracks origin/main.
git worktree list --porcelain
git worktree remove <path>
git worktree prune
git worktree repair <path>
git -C <worktree> status -sb