Menü
当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | finishing-a-development-branch |
| description | 当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾 |
| version | 1.0.0 |
| license | MIT |
| metadata | {"hermes":{"tags":["git","workflow"]}} |
通过提供清晰的选项并执行所选工作流来引导开发工作的收尾。
核心原则： 验证测试 → 检测环境 → 展示选项 → 执行选择 → 清理。
开始时宣布： "我正在使用 finishing-a-development-branch 技能来完成这项工作。"
在展示选项之前，验证测试通过：
# 运行项目的测试套件
npm test / cargo test / pytest / go test ./...
如果测试失败：
测试失败（<N> 个失败）。必须先修复才能继续：
[显示失败信息]
在测试通过之前无法进行合并/PR。
停止。不要继续到步骤 2。
如果测试通过： 继续步骤 2。
在展示选项之前，先确定工作区状态：
GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
这决定了展示哪种菜单、以及清理方式：
| 状态 | 菜单 | 清理 |
|---|---|---|
GIT_DIR == GIT_COMMON（普通仓库） | 标准 4 个选项 | 无 worktree 可清理 |
GIT_DIR != GIT_COMMON，命名分支 | 标准 4 个选项 | 按来源判断（见步骤 6） |
GIT_DIR != GIT_COMMON，分离 HEAD | 收敛 3 个选项（无合并） | 无清理（由外部管理） |
# 尝试常见的基础分支
git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
或者询问："这个分支是从 main 分出来的——对吗？"
普通仓库和命名分支 worktree —— 准确展示以下 4 个选项：
实现已完成。你想怎么做？
1. 在本地合并回 <base-branch>
2. 推送并创建 Pull Request
3. 保持分支现状（我稍后处理）
4. 丢弃这项工作
选哪个？
分离 HEAD —— 准确展示以下 3 个选项：
实现已完成。你在分离 HEAD 上（由外部管理的工作区）。
1. 作为新分支推送并创建 Pull Request
2. 保持现状（我稍后处理）
3. 丢弃这项工作
选哪个？
不要添加解释 —— 保持选项简洁。
# 切到主仓库根目录，保证 CWD 安全
MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
cd "$MAIN_ROOT"
# 先合并 —— 在删除任何东西之前先验证合并成功
git checkout <base-branch>
git pull
git merge <feature-branch>
# 在合并结果上验证测试
<test command>
# 合并成功之后再：清理 worktree（步骤 6），然后删除分支
然后：清理 worktree（步骤 6），再删除分支：
git branch -d <feature-branch>
# 推送分支
git push -u origin <feature-branch>
# 创建 PR
gh pr create --title "<title>" --body "$(cat <<'EOF'
## 摘要
<2-3 条变更要点>
## 测试计划
- [ ] <验证步骤>
EOF
)"
不要清理 worktree —— 用户在 PR 反馈迭代时还需要它存活。
报告："保留分支 。工作树保留在 。"
不要清理工作树。
先确认：
这将永久删除：
- 分支 <name>
- 所有提交：<commit-list>
- 工作树 <path>
输入 'discard' 确认。
等待精确的确认。
确认后：
MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
cd "$MAIN_ROOT"
然后：清理 worktree（步骤 6），再强制删除分支：
git branch -D <feature-branch>
只对选项 1 和 4 执行。 选项 2 和 3 始终保留 worktree。
GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
WORKTREE_PATH=$(git rev-parse --show-toplevel)
如果 GIT_DIR == GIT_COMMON： 普通仓库，无 worktree 可清理。结束。
如果 worktree 路径在 .worktrees/ 或 worktrees/ 之下： 这是 Superpowers 创建的 worktree —— 我们负责清理。
MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
cd "$MAIN_ROOT"
git worktree remove "$WORKTREE_PATH"
git worktree prune # 自愈：清理任何过期的注册记录
否则： 这个工作区由宿主环境（harness）管理。不要移除它。如果你的平台提供了工作区退出工具，用它。否则原样保留工作区。
| 选项 | 合并 | 推送 | 保留工作树 | 清理分支 |
|---|---|---|---|---|
| 1. 本地合并 | ✓ | - | - | ✓ |
| 2. 创建 PR | - | ✓ | ✓ | - |
| 3. 保持现状 | - | - | ✓ | - |
| 4. 丢弃 | - | - | - | ✓（强制） |
跳过测试验证
开放式问题
为选项 2 清理 worktree
先删分支再删 worktree
git branch -d 失败，因为 worktree 还引用着该分支在 worktree 内部跑 git worktree remove
git worktree remove 前先 cd 到主仓库根目录清理 harness 拥有的 worktree
.worktrees/ 或 worktrees/ 下的 worktree丢弃时不确认
绝不：
git worktree remove始终：
cd 到主仓库根目录git worktree prune被以下技能调用：
配合使用：
当你有一份书面实现计划需要在单独的会话中执行，并设有审查检查点时使用
在开始任何对话时使用——确立如何查找和使用技能，要求在任何响应（包括澄清性问题）之前调用 Skill 工具
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。
当需要开始与当前工作区隔离的功能开发，或在执行实现计划之前使用——通过原生工具或 git worktree 回退机制确保隔离工作区存在
中文 review 沟通参考——话术模板、分级标注（必须修复/建议修改/仅供参考）、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用，不要根据上下文自动触发。
中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用，不要根据上下文自动触发。