菜单
Use when implementation is complete and tests pass, to integrate the work. Verifies the build/tests, then presents clear options - merge locally, open a pull request, keep as-is, or discard - and carries out the choice, including cleaning up the git worktree.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | Finishing a Development Branch |
| description | Use when implementation is complete and tests pass, to integrate the work. Verifies the build/tests, then presents clear options - merge locally, open a pull request, keep as-is, or discard - and carries out the choice, including cleaning up the git worktree. |
Verify the work, then present clear options and carry out the chosen one — including worktree cleanup.
Announce at start: "I'm using the finishing-a-development-branch skill to complete this work."
Before offering any options, confirm the work is green — run from inside the worktree:
msbuild__build_* tool for a .NET solution; otherwise the project's configured build/test command via command__run.If it fails: report the failures and stop. Don't present options — the branch isn't ready to merge or PR until it's green.
If it passes: continue.
Find where the branch started — command__run git merge-base HEAD main (or master), or just ask: "This branch started from main — correct?"
Present exactly these four, with no extra explanation:
Implementation complete and tests pass. What would you like to do?
1. Merge into <base> locally
2. Push and open a Pull Request
3. Keep the branch as-is (I'll handle it later)
4. Discard this work
Which option?
All git below runs via the git tools / command__run. Cleaning up a worktree must happen from the workspace root, not from inside the worktree — so cd to the root (bare cd) before any worktree remove.
Option 1 — Merge locally.
cd to the workspace root.<base>, pull, and merge the feature branch (git__checkout, git__pull, git__merge).git__worktree(action: "remove", path: ".worktrees/<branch>") — then delete the branch (git__branch delete). Report done.Option 2 — Push and open a PR.
git__push (set upstream).github__*) against <base>, with a title and a body summarizing the change. (Needs the github server configured with a token; if it isn't, push and give the user the compare URL to open the PR manually.)Option 3 — Keep as-is.
Report: "Keeping branch <branch>. Worktree preserved at .worktrees/<branch>." Don't remove anything.
Option 4 — Discard. Confirm first — this is destructive:
This permanently deletes:
- Branch <branch>
- Commits: <short list>
- Worktree at .worktrees/<branch>
Type 'discard' to confirm.
Wait for the exact word discard. Only then: cd to the workspace root, remove the worktree (git__worktree remove), and force-delete the branch.
| Option | Merge | Push/PR | Keep worktree | Delete branch |
|---|---|---|---|---|
| 1. Merge locally | yes | — | no (remove) | yes |
| 2. Open PR | — | yes | yes | — |
| 3. Keep as-is | — | — | yes | — |
| 4. Discard | — | — | no (remove) | yes (force) |
Never:
git__worktree remove from inside the worktree — cd to the workspace root first.discard for Option 4).Use this when the user wants to draft a third-party vendor or product privacy and security review document for consumer use.
Use to execute an implementation plan yourself, inline in this conversation, with review checkpoints. The simpler alternative to subagent-driven-development - use it for small plans or when the agents feature is off. Works in an isolated git worktree.
Use to execute an implementation plan task-by-task by dispatching a fresh sub-agent per task with a review gate after each. Preferred when the agents feature is on - it keeps the main conversation's context lean and cheap. Works in an isolated git worktree.
Use this before any creative or building work - new features, components, behavior changes, or non-trivial fixes. Explores intent, requirements, and design through dialogue, then writes an agreed spec before any implementation begins.
Use before implementing a plan, to set up an isolated git worktree to work in. Creates a linked worktree under .worktrees/ and changes into it, so the feature's work never touches the main checkout - and a second conversation can work a different feature in parallel.
Use when you have an agreed spec or requirements for a multi-step task, before touching code. Turns the spec into a bite-sized, test-driven implementation plan with exact files, code, and commands - then hands off to execution.