بنقرة واحدة
finishing-a-development-branch
当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
当你有一份书面实现计划需要在单独的会话中执行,并设有审查检查点时使用
在开始任何对话时使用——确立如何查找和使用技能,要求在任何响应(包括澄清性问题)之前调用 Skill 工具
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。
当需要开始与当前工作区隔离的功能开发,或在执行实现计划之前使用——通过原生工具或 git worktree 回退机制确保隔离工作区存在
中文 review 沟通参考——话术模板、分级标注(必须修复/建议修改/仅供参考)、国内团队常见反模式应对。仅在用户显式 /chinese-code-review 时调用,不要根据上下文自动触发。
中文 commit 与 changelog 配置参考——Conventional Commits 中文适配、commitlint/husky/commitizen 中文模板、conventional-changelog 中文配置。仅在用户显式 /chinese-commit-conventions 时调用,不要根据上下文自动触发。
| 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被以下技能调用:
配合使用: