技能使用指南

finishing-a-development-branch（完成开发分支）Skill 是什么？如何下载安装？

完成开发分支（finishing-a-development-branch）Skill 帮你在功能开发收尾时先验证测试，再用本地合并、创建 PR、保留分支、确认丢弃这 4 个结构化选项完成整合，并自动清理 git worktree。本文详解安装思路、使用步骤、竞品对比与常见问题，让分支收尾从易错操作变成稳定流程，立即上手体验。

完成开发分支Skillfinishing-a-development-branch
8 个章节 约 12 分钟阅读 AI 智能生成

完成开发分支Skill：让每次功能收尾都自动走过“测试→决策→执行→清理”的标准化流程

  • 一句话理解：它是一套“开发收尾协议”，在功能写完、测试通过时，用固定的 4 个选项代替模糊的“接下来干啥”，避免半成品被合并或误删。
  • 核心机制：验证测试 → 呈现选项 → 执行选择 → 清理工作树，四步顺序固定，测试不过会直接停下。
  • 4 个结构化选项：本地合并回基础分支、推送并创建 PR、保持分支原样、确认后丢弃工作。
  • 安全设计：丢弃必须手动输入 discard 确认；合并后要重新跑测试；不验证测试不合并、不强制推送。
  • 最大价值：把最容易被“凭感觉”处理的收尾环节，变成可复用、可交接、可审计的标准动作。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

这个技能的中文名是「完成开发分支Skill」，英文名是 finishing-a-development-branch，技能 ID 为 12201。

它要解决的问题非常具体：在 AI 辅助编程已经很普及的今天，写代码这一段经常比较顺畅，但“代码写完了、测试过了，接下来怎么办”往往还是全靠人临时判断。合并到 main 还是先开 PR？本地的 git worktree 要不要删？这个实验性分支留还是丢？判断失误的成本很高——可能把没测过的代码合进主干，也可能把还要用的分支删掉。该技能把这段“收尾判断”固化成一条明确的流水线，让 AI 助手按流程执行，而不是临时自由发挥。

安装思路与步骤（一键式 AI 技能的通用路径）：

  1. 确认安装前提：你需要一个支持 AI 技能（Skill）机制的编程助手环境，且本地项目使用 Git 管理。技能内部依赖 git 命令，创建 PR 时会用到 GitHub CLI（gh），运行测试时需要项目自带的测试脚本。
  2. 找到技能入口：在助手提供的技能市场、技能目录或插件列表中搜索技能 ID 12201 或英文名 finishing-a-development-branch，具体入口与命令以官方说明为准。
  3. 执行安装：按官方提供的一键安装流程（通常是选择该技能并确认安装，或执行官方给出的安装指令）完成加载；安装后技能会以「完成开发分支」的名称出现在可用技能列表中。
  4. 验证是否生效：在一个测试分支上进入收尾状态，若助手主动声明“我正在使用完成开发分支技能来完成这项工作”，并随后运行测试套件、列出 4 个结构化选项，说明技能已正常工作。
  5. 异常排查：若没有触发，检查技能是否已启用、当前目录是否为 Git 仓库、测试命令是否可执行（npm test / cargo test / pytest / go test ./... 之一），具体限制以官方说明为准。

关于价格、下载链接与具体安装命令，技能详情中并未提供，请以官方说明为准，避免使用来路不明的第三方脚本。

该技能的主要功能和特点

  • 强制测试门禁：在给出任何选项之前，先运行项目测试套件；若失败，立刻输出“测试失败（N 个失败）。必须在完成前修复”，并停止流程，不允许继续合并或创建 PR。
  • 基础分支自动识别：通过 git merge-base HEAD main / master 推断分支来源，识别不出就用一句式确认问题问用户：“这个分支是从 main 分支分出来的 – 是否正确？”
  • 4 个固定选项，不添加解释：本地合并回基础分支、推送并创建拉取请求、保持分支原样、丢弃此工作。技能明确规定“不要添加解释”，保持选项简洁，避免用户被冗长说明干扰。
  • 分支与工作树联动处理：合并类操作会切回基础分支 → git pull → git merge → 合并后再跑一次测试 → 删除功能分支；丢弃操作要求用户键入 discard 确认后才执行 git branch -D。
  • 工作树清理有边界：只有确定不再需要时（本地合并、丢弃）才执行 git worktree remove，对“推送并创建 PR”“保持原样”则保留工作树，防止误删仍在使用的目录。
  • 危险操作护栏：技能明确列出“绝不”清单——测试失败不继续、不验证就合并、无确认删除工作、未经明确请求强制推送。
  • 可与其它技能串联：由 subagent-driven-development（步骤 7）与 executing-plans（步骤 5）在所有任务完成后调用，并与 using-git-worktrees 配对，负责清理该技能创建的工作树。

和普通工具比强在哪：普通 Git 工具只提供命令，不提供判断；通用 AI 助手会“帮你敲命令”，但顺序和护栏不稳定。这个技能的价值在于把顺序和护栏写死：先验证、再问、后执行、最后清理，且每个分支路径都有明确动作。

如何使用该技能？

第 1 步：进入收尾状态并触发技能 在功能分支上完成开发后，让 AI 助手使用「完成开发分支」技能收尾。技能会先声明自己的身份，然后开始流程。

第 2 步：等待测试验证结果 技能会自动执行项目测试命令（如 npm test、pytest、go test ./...）。

  • 若失败，你只会看到失败清单和“在测试通过之前，不能继续合并/PR”，此时先修测试，流程不会继续。
  • 若通过，进入下一步。

第 3 步：确认基础分支 典型输出示例：

这个分支是从 main 分支分出来的 – 是否正确？

回答“是”即继续；若分支来自其它基线，直接告知正确的分支名。

第 4 步：从 4 个选项中选择

实现完成。您想做什么？

1. 本地合并回 <base-branch>
2. 推送并创建拉取请求
3. 保持分支原样（我稍后处理）
4. 丢弃此工作

选择哪个选项？

第 5 步：按选择执行并核对结果

  • 选 1：技能执行 git checkout <base-branch> → git pull → git merge <feature-branch> → 再跑测试 → 测试通过后 git branch -d <feature-branch>，随后清理工作树。
  • 选 2：技能执行 git push -u origin <feature-branch>，再用 gh pr create 生成 PR，正文自动带上「## 摘要」（2-3 条改变要点）与「## 测试计划」（验证步骤清单），并保留工作树供后续迭代。
  • 选 3：技能只报告“保持分支 <name>。工作树保留在 <path>”，不执行任何删除。
  • 选 4：先显示将被永久删除的分支、提交列表与工作树路径，要求你输入 discard 才继续，之后切回基础分支并强制删除功能分支，再清理工作树。

输入输出小结：输入是“一个测试通过的功能分支 + 你的一个数字选择”；输出是“已合并的主干 / 已创建的 PR / 保留的分支 / 已删除的分支”以及一份干净的 worktree 状态。

同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
完成开发分支（finishing-a-development-branch，本技能） 开发收尾标准化流程 测试门禁 + 4 选项决策 + 分支/工作树清理 + 丢弃确认 需支持技能机制的助手环境，低门槛，一键加载 功能分支收尾、AI 协作开发、worktree 工作流 优势：顺序固定、护栏明确、可交接；不足：选项固定为 4 个，需人工决策
纯手工 Git 命令 通用版本控制操作 checkout / merge / push / branch -D 等 需要熟悉 Git，门槛中高 任何 Git 项目 优势：灵活完全可控；不足：依赖个人经验，容易漏跑测试或误删分支
通用 AI 编程助手（无专用技能） 对话式辅助 根据自然语言临时拼命令 门槛低 零散操作、临时问答 优势：自由度高；不足：流程不稳定，不同会话行为不一致，缺少强制测试门禁
GitHub CLI + 自研脚本 自动化脚本方案 批量创建 PR、按模板填正文 需编写与维护脚本 团队统一 PR 规范 优势：可定制、可集成 CI；不足：需要开发维护成本，缺少交互式决策与工作树治理

从对比看，本技能的位置很清晰：它不追求“什么都能干”，而是把收尾这一段做得比其他方案更稳、更一致。

该技能的典型应用场景与实际体验情况

场景一：独立开发者的特性分支收尾 独立开发者小陈同时开着两三个 worktree 做不同特性，常常忘记哪个目录对应哪个分支。痛点不是写代码，而是收尾时“要不要删、删了会不会丢”。使用该技能后，他只需回答一个数字，合并与工作树清理一步到位，丢弃前还必须键入 discard，心理负担明显下降。体验：上手几乎零成本，唯一要注意的是首次使用时确认基础分支识别是否正确。

场景二：团队开发者提交 PR 前的规范统一 团队要求 PR 正文必须包含变更摘要与测试计划。人工填写经常漏项。选择选项 2 后，技能自动推送分支并用模板生成 PR 正文，摘要与测试清单结构固定。体验：省去重复劳动，PR 质量一致性提升；注意 gh 需已登录，否则需先完成认证（以官方说明为准）。

场景三：AI 多任务编排中的最后一环 在使用 subagent-driven-development 或 executing-plans 批量推进任务时，所有任务完成后需要统一收口。该技能被显式调用（分别在其步骤 7 与步骤 5），把“任务完成”平滑转换为“分支合并或 PR”。体验：串联顺畅，减少人工在中途打断；注意测试耗时长时要有心理预期。

场景四：实验性分支的安全废弃 试验了半天的方案决定不做了，最怕误删还有用的提交。技能会先列出将被删除的分支、提交列表与工作树路径，只有明确输入 discard 才执行。体验：安全感强，但确认环节不能图快，务必看清提交列表。

整体上手难度：低。效果：收尾动作从“凭经验”变成“走流程”。注意事项：技能本身不生产测试，项目必须有可运行的测试命令；选项是固定的 4 个，若有特殊需求（如变基合并）需在流程外单独处理。

该技能能为用户带来的价值

  • 把易错环节变成不易错环节：测试门禁前置，杜绝“带着失败用例合并”和“造出红色 PR”，减少返工与主干污染。
  • 决策成本降到一次点击：不再纠结“接下来做什么”，4 个选项覆盖绝大多数收尾诉求，回答一个数字即可。
  • 误删风险显著下降：丢弃需键入确认，且工作树清理限定在安全路径内，避免“手快删掉三天工作量”。
  • 协作与交接更顺滑：PR 正文自动带上摘要与测试计划，评审者拿到的是结构完整的信息，而不是一句“改了点东西”。
  • 长期价值在于流程资产化：这套“验证→选项→执行→清理”的约定可以沉淀为团队规范，新成员接入 AI 协作时直接继承成熟做法，而不必重新踩坑。

常见问题 FAQ

Q1：这个技能怎么安装？我找不到安装命令怎么办？ 在支持 AI 技能机制的助手环境中，通过技能市场或技能目录搜索技能 ID 12201 或英文名 finishing-a-development-branch 即可加载。技能详情中没有提供具体安装命令与下载链接，请以官方说明为准，不要执行来源不明的脚本。

Q2：它是收费的吗？ 技能详情未涉及任何定价信息，是否收费取决于你使用的技能平台与账户方案，请以官方说明为准。

Q3：测试一直失败，能不能先合并再说？ 不能。技能的设计就是“测试失败即停止”，只会提示失败数量并要求在完成前修复，不会进入选项环节。这是它的核心护栏之一，也是它相比手工操作最值得保留的部分。

Q4：它和直接让 AI 助手帮我执行 git 命令有什么区别？ 直接对话式操作每次行为可能不同，顺序和检查项不稳定；本技能固定了“先验证测试、再给 4 个选项、按选项执行、最后按规则清理”的顺序，并对丢弃操作强制确认、对工作树清理设边界，一致性更强。

Q5：适合谁用？ 适合使用 Git 分支开发、并且有可运行测试的开发者与团队，尤其是配合 worktree 或多任务并行开发的场景。若项目没有测试命令，或收尾流程高度定制（如固定走变基、固定多级评审），该技能的固定 4 选项可能不够用，需要额外人工处理。