完成开发分支Skill：测试通过后，用四步把功能分支安全收尾
- 它是什么：一个专注"收尾"环节的 AI 技能，在代码实现完成、测试通过之后，把"接下来怎么办"从模糊的开放问题，变成 4 个结构化选项。
- 核心流程：验证测试 → 确定基础分支 → 提供 4 个选项（本地合并 / 推送并创建 PR / 保持分支不变 / 丢弃工作）→ 执行选择 → 清理工作树。
- 最大亮点：默认拦截"测试没通过就想合并"的冲动，丢弃分支必须手打
discard确认，把高风险操作变成不可误触的动作。 - 适合谁用：使用 AI 编程助手、按批次执行开发计划、习惯用 Git worktree 做隔离开发的团队与个人开发者。
- 一句话价值：让"分支怎么收尾"这件小事有标准答案，减少误合并、误删除和残留工作树。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 完成开发分支Skill |
| 技能英文名 | finishing-a-development-branch |
| 技能 ID | 13652 |
| 技能定位 | 开发生命周期的"收尾与集成决策"环节 |
| 依赖工具 | Git，以及可选的 GitHub CLI（用于创建拉取请求） |
它解决什么问题
写代码的阶段往往很热闹，收尾阶段却很容易出问题：测试还没跑通就急着合并、合并前没有验证合并后的结果、创建了拉取请求却忘了说明测试计划、临时工作树（worktree）留在磁盘上没人清理、一个"要不要丢弃这个分支"的提问被误解后永久删掉了提交记录。这个技能把收尾动作固化成一条不可跳步的流水线：验证测试 → 提供选项 → 执行选择 → 清理。
它的设计有两条很"硬"的约束：一是"提供 exactly 4 个选项"，不允许用"下一步该做什么？“这种开放式提问；二是"测试不通过就停止，不进入第 2 步”。这类约束正是把 AI 助手从"热心但随意"拉回"可靠工程伙伴"的关键。
一键安装的思路与步骤
AI 技能的安装入口通常由承载它的平台（技能市场、插件市场或 IDE 扩展）提供，具体命令、地址与是否需要登录，请以官方说明为准。通用步骤如下：
- 确认前置条件：本地已安装 Git，并能正常执行
git status、git merge-base；如果希望使用"推送并创建拉取请求"选项，还需要在本地配置好 GitHub CLI（gh）并完成登录授权。 - 确认运行环境：确认你的 AI 助手/Agent 平台已开启"技能"或"工具调用"能力，因为该技能需要读取仓库状态、执行命令并向你提问。
- 获取并安装技能：在技能市场或插件市场中按技能名
finishing-a-development-branch或技能 ID13652检索并添加；若是文件式技能，则将其放入平台的技能目录。具体安装方式以官方说明为准。 - 确认授权范围：该技能会执行
git checkout、git merge、git push、git branch -D、git worktree remove等命令，请确保授权范围覆盖当前仓库目录。 - 验证是否生效：向助手发起一次收尾类请求，例如"实现完成了，帮我收个尾"。若技能生效，它会先宣告"我正在使用完成开发分支技能来完成这项工作"，然后运行项目测试套件——看到这句宣告，就说明技能已被正确加载。
该技能的主要功能和特点
- 测试闸门（强制前置验证）：在抛出任何选项之前，先运行项目测试套件（如
npm test、cargo test、pytest、go test ./...，按项目实际命令）。失败则输出失败清单并停止，明确告知"测试通过前无法继续合并/拉取请求"。 - 自动识别基础分支：通过
git merge-base HEAD main/git merge-base HEAD master推断分支从哪里分离，或直接向你确认"此分支从 main 分离出来 - 正确吗？"。 - 固定 4 选项菜单：本地合并回基础分支、推送并创建拉取请求、保持分支不变、丢弃此工作。选项呈现刻意保持简洁，不附加冗长解释，降低选择成本。
- 一键执行所选工作流：选项 1 执行"切基础分支 → pull → merge → 复跑测试 → 删除功能分支"；选项 2 执行"推送分支 → 用
gh pr create生成带总结与测试清单的 PR 描述"。 - 危险操作二次确认：丢弃分支前必须看到"这将永久删除：分支、所有提交、工作树路径"的清单，并手动输入
discard才执行git branch -D。 - 精准的工作树清理：只在选项 1、2、4 之后清理工作树，选项 3 保留工作树——避免"顺手清理"把你可能还要用的环境删掉。
- 清晰的边界意识：红线写得很明确——测试失败绝不继续、合并后必须复跑测试、未经确认不得删除工作、无明确请求不强制推送。
和普通 Git 工具相比，它的差异不在"能不能执行命令"，而在于它先替你把关，再让你选：普通工具等你输入命令，它先跑测试；普通助手会问"你想怎么做"，它只给 4 个有边界的选择；普通脚本可能直接删分支，它要求你亲手输入确认词。
如何使用该技能？
第 1 步：触发技能
在实现完成、测试基本就绪时，向 AI 助手说："这个功能做完了，帮我完成这个开发分支。"技能会先宣告自己正在使用"完成开发分支"技能。
第 2 步：让技能验证测试
助手会运行项目的测试命令（如 npm test）。输入示例：
- 你说：“实现已经完成，所有测试通过了，帮我收尾。”
- 技能行为：仍会自己再跑一遍测试，不依赖你的口头声明——这是它的核心原则。
若测试失败，你会看到类似输出：
测试失败（3 个失败）。完成前必须修复：
[失败用例列表]
测试通过前无法继续合并/拉取请求。
此时流程停止，你修完再回来。
第 3 步：确认基础分支
技能会尝试自动识别，或询问："此分支从 main 分离出来 - 正确吗？"确认即可，避免合错目标分支。
第 4 步：在 4 个选项中做选择
你会看到类似这样的菜单：
实现完成。您想做什么？
1. 本地合并回 main
2. 推送并创建拉取请求
3. 保持分支不变（稍后处理）
4. 丢弃此工作
选择哪个选项？
回复 1、2、3 或 4 即可。
第 5 步：执行与清理
- 选 1：切回基础分支、拉取最新、合并、复跑测试，通过后删除功能分支，再清理工作树。
- 选 2：推送分支并创建 PR，PR 描述里自动带上"总结（2-3 个改变要点）"与"测试计划"清单，方便评审人按清单验收。
- 选 3：只报告"保持分支 <name>，工作树保留在 <path>"，不做任何删除。
- 选 4：先展示将被永久删除的分支、提交列表与工作树路径，等你输入
discard后才执行。
第 6 步：复核结果
合并后建议自己再 git log --oneline -5 看一眼历史，确认 PR 描述中的测试计划确实可勾选、可复现。
调用时机参考
该技能通常在 subagent-driven-development（步骤 7，所有任务完成后）与 executing-plans（步骤 5，所有批次完成后）被自动调用；如果你使用 using-git-worktrees 创建隔离工作区，它也会负责清理对应工作树。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| 完成开发分支Skill（finishing-a-development-branch） | 开发收尾环节的流程型 AI 技能 | 测试闸门、基础分支识别、4 选项决策、PR 生成、工作树清理、危险操作确认 | 需 AI 助手支持技能调用 + Git 环境；创建 PR 需 GitHub CLI，具体以官方说明为准 | AI 辅助开发后的分支收尾、多批次任务收口 | 优势：把"该不该合并"变成有闸门的流程，误操作风险低；不足：只覆盖收尾，不涉及编码与评审细节 |
| GitHub CLI（gh） | 命令行 GitHub 操作工具 | 创建 PR、查看状态、合并、发布 | 需安装并登录授权 | 熟悉命令行的开发者手动操作 | 优势：能力全面、可脚本化；不足：不做测试验证，不会阻止你在测试失败时开 PR |
| Git 图形客户端（如 GitKraken、Sourcetree 等） | 可视化 Git 操作界面 | 分支图、提交、合并、冲突可视化解 | 安装桌面客户端并配置仓库 | 需要看分支拓扑、手动解冲突 | 优势：直观、易上手；不足：收尾决策仍靠人，缺少"先验证再选项"的约束 |
| git-flow 类分支模型工具 | 分支规范与流程脚手架 | 按模型创建/结束 feature、release 分支 | 需额外初始化与团队约定 | 团队统一分支模型 | 优势：规范统一；不足：偏规范化，不替你做测试把关与工作树清理 |
一句话选型：需要"有闸门、有边界、有确认"的 AI 收尾流程，选本技能；需要完全手动掌控每一步，用 Git CLI 或图形客户端即可。
该技能的典型应用场景与实际体验情况
场景一：AI 多任务开发后的统一收口（后端工程师）
用 subagent-driven-development 把一个大需求拆成多个子任务并行推进，全部完成后最烦的是"每个分支怎么处理"。技能会在所有任务完成后被调用，先跑测试，再一次性给出 4 个选项。实际体验：上手几乎零成本，因为选项就是四个数字；效果上最明显的是不再出现"测试挂了但 PR 已经开出去"的尴尬。注意：不同语言的测试命令要能被正确识别，建议先在项目里确认测试入口。
场景二：开源贡献者的 PR 规范（外部贡献者）
给开源项目提 PR 时，维护者最在意"有没有测试计划"。选择选项 2 后，PR 描述会自动包含变更总结与测试清单。实际体验：省去手写 PR 模板的时间，评审沟通更顺。注意：需要 gh 已登录，且目标仓库有推送权限；具体授权方式以官方说明为准。
场景三：实验性分支的"止损"（技术预研）
预研失败时，最怕迷迷糊糊删掉还想留的提交。技能选择 4 会先列出将删除的分支、提交列表与工作树路径，并要求输入 discard。实际体验：这个确认步骤看起来啰嗦，但恰恰是它最有价值的地方——多打一个词的代价，换的是不会误删一天的工作。
场景四：worktree 隔离开发后的环境清理（多需求并行）
配合 using-git-worktrees，每个需求一个工作树，收尾时容易留下一堆目录。技能只在选项 1、2、4 后清理，选项 3 明确保留。实际体验：磁盘不再被"上一个需求的半成品环境"占满；注意事项是清理前确认没有其他进程正在该目录下运行。
整体评价：上手难度低（主要是选择数字），效果取决于你的测试命令是否真实可跑；最需要留意的是"它不会替你修测试"——闸门拦住了，问题还得自己解决。
该技能能为用户带来的价值
- 把风险前移：测试验证被固定在收尾流程的最前面，避免把失败代码合进主干或推进评审队列，减少返工。
- 把决策变简单：开放式提问换成 4 个结构化选项，"下一步做什么"从 10 分钟纠结变成 10 秒选择。
- 把误操作变昂贵：丢弃分支需要手打确认词，删除动作从"一键"变成"两步"，长期看能避免难以估量的工作损失。
- 把残留变干净：明确的工作树清理策略，让并行开发不再堆出无人认领的目录，仓库长期保持可维护状态。
- 把流程变可复用：将个人经验固化为可调用的技能，团队中每个人（包括 AI 助手）收尾时都走同一条路径，评审与交接成本同步下降。
- 长期价值：分支历史更干净、PR 描述更规范、提交可追溯，这些"小事"累积起来就是工程效率与代码可信度的提升。
常见问题 FAQ
Q1：怎么安装这个技能？需要付费吗？
A：在承载它的技能市场或插件市场中按名称 finishing-a-development-branch 或技能 ID 13652 检索添加即可，也可按平台规则把技能文件放入对应目录。是否收费、是否需要登录，取决于平台本身，具体以官方说明为准。安装前请确保本地 Git 可用。
Q2：它会不会自己乱执行 git 命令，把我的代码搞坏？
A：从技能描述看，它的设计偏向保守：测试失败即停止、丢弃分支必须输入 discard 确认、不在选项 3 时清理工作树、没有明确请求不做强制推送。但命令仍会真实执行，建议在干净的工作区状态下使用，并保留远端备份。
Q3：为什么它非要自己再跑一遍测试，我说通过了不行吗？
A：这正是它的核心原则——“在提供选项之前验证测试通过”。人工声明可能过期或遗漏，复跑一次是对合并结果负责。如果项目测试耗时很长，可以先本地跑完再触发技能，避免重复等待。
Q4：我不用 GitHub，选"创建拉取请求"还能用吗？
A：该选项依赖 gh pr create，属于 GitHub 工作流。使用 GitLab、Gitee 等平台时，更稳妥的是选择选项 1（本地合并）或选项 3（保持分支），再在对应平台手动发起合并请求。
Q5：它和直接用 Git 命令、GitHub CLI 有什么区别，该怎么选？
A：Git CLI 与 gh 是"执行器"，能力全但不管流程；本技能是"流程把关者"，先验证测试、再给 4 个有边界的选项、最后按选择清理。如果你经常在 AI 辅助开发后纠结分支怎么收尾，选本技能；如果你需要完全手动掌控每一步，Git CLI 更合适。两者也可以组合使用。