メニュー
当实现完成、所有测试通过且需要决定如何集成工作时必须使用——通过呈现结构化的本地合并、创建 PR 或清理工作树等选项，指导开发工作的收尾
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | finishing-a-development-branch |
| description | 当实现完成、所有测试通过且需要决定如何集成工作时必须使用——通过呈现结构化的本地合并、创建 PR 或清理工作树等选项，指导开发工作的收尾 |
通过呈现清晰的选项并处理所选工作流，指导开发工作的收尾。
核心原则： 验证测试 → 检测环境 → 呈现选项 → 执行选择 → 清理。
开始时声明： "我正在使用 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 个选项 | 无需清理工作树 |
GIT_DIR != GIT_COMMON，命名分支 | 标准 4 个选项 | 基于来源（见步骤 6） |
GIT_DIR != GIT_COMMON，分离头指针 | 精简 3 个选项（无合并） | 无需清理（外部管理） |
# 尝试常见的基础分支
git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
或询问："该分支从 main 分出——是否正确？"
普通仓库和命名分支工作树——准确呈现以下 4 个选项：
实现已完成。您希望如何操作？
1. 在本地合并回 <base-branch>
2. 推送并创建 Pull Request
3. 保持分支原样（稍后自行处理）
4. 丢弃此工作
选择哪个选项？
分离头指针——准确呈现以下 3 个选项：
实现已完成。您当前处于分离头指针状态（外部管理的工作区）。
1. 推送到新分支并创建 Pull Request
2. 保持原样（稍后自行处理）
3. 丢弃此工作
选择哪个选项？
不要添加解释——保持选项简洁。
# 获取主仓库根目录以确保当前工作目录安全
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>
# 仅在合并成功后：清理工作树（步骤 6），然后删除分支
然后：清理工作树（步骤 6），然后删除分支：
git branch -d <feature-branch>
# 推送分支
git push -u origin <feature-branch>
不要清理工作树——用户需要保留它来根据 PR 反馈迭代。
报告："保留分支 。工作树保留在 。"
不要清理工作树。
首先确认：
这将永久删除：
- 分支 <name>
- 所有提交：<commit-list>
- 位于 <path> 的工作树
输入 'discard' 以确认。
等待准确确认。
如果已确认：
MAIN_ROOT=$(git -C "$(git rev-parse --git-common-dir)/.." rev-parse --show-toplevel)
cd "$MAIN_ROOT"
然后：清理工作树（步骤 6），然后强制删除分支：
git branch -D <feature-branch>
仅在选项 1 和 4 中执行。 选项 2 和 3 始终保留工作树。
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： 普通仓库，无需清理工作树。完成。
如果工作树路径位于 .worktrees/ 或 worktrees/ 下： KimiCodeBoost 创建了该工作树——我们负责清理。
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 清理工作树
在移除工作树前删除分支
git branch -d 失败，因为工作树仍引用该分支在工作树内部运行 git worktree remove
git worktree remove 之前始终 cd 到主仓库根目录清理 harness 拥有的工作树
.worktrees/ 或 worktrees/ 下的工作树丢弃时没有确认
禁止：
git worktree remove必须：
cd 到主仓库根目录git worktree pruneUpdate Kimi Code CLI user documentation after meaningful code changes that affect product behavior or user experience.
Map systematic debugging onto Ganymede Code native Debug / 排障 surfaces (probes, user verification bar, TodoList).
Map KimiCodeBoost engineering workflows onto Ganymede Code native UI and host tools (AskUserQuestion, TodoList, Agent, Plans panel, GanymedeBrowser, Worktree, Review).
在开展任何创造性工作之前必须使用：创建功能、构建组件、添加能力或修改行为。在动手实现前，先探索用户意图、需求并制定设计。
当同时面对 2 个及以上相互独立、无共享状态且无顺序依赖的任务时必须使用本技能
当需要在一个独立会话中执行已撰写的实现计划，并通过检查点进行复核时必须使用