القائمة
在实现完成、测试通过后，引导决定如何集成工作——提供合并、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 merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
或询问："这个分支是从 main 分出来的——对吗？"
展示以下 4 个选项：
实现已完成。你想怎么处理？
1. 本地合并回 <基础分支>
2. 推送并创建 Pull Request
3. 保持分支现状（稍后自行处理）
4. 丢弃本次工作
选哪个？
不要添加解释 —— 保持选项简洁。
# 切换到基础分支
git checkout <基础分支>
# 拉取最新
git pull
# 合并功能分支
git merge <功能分支>
# 在合并结果上验证测试
<测试命令>
# 如果测试通过
git branch -d <功能分支>
然后：清理 worktree（步骤 5）
# 推送分支
git push -u origin <功能分支>
# 创建 PR
gh pr create --title "<标题>" --body "$(cat <<'EOF'
## Summary
<2-3 条变更摘要>
## Test Plan
- [ ] <验证步骤>
EOF
)"
然后：清理 worktree（步骤 5）
报告："保持分支 <名称>。Worktree 保留在 <路径>。"
不要清理 worktree。
先确认：
这将永久删除：
- 分支 <名称>
- 所有提交：<提交列表>
- Worktree：<路径>
输入 'discard' 确认。
等待精确确认。
确认后：
git checkout <基础分支>
git branch -D <功能分支>
然后：清理 worktree（步骤 5）
选项 1、2、4：
检查是否在 worktree 中：
git worktree list | grep $(git branch --show-current)
如果是：
git worktree remove <worktree路径>
选项 3： 保留 worktree。
| 选项 | 合并 | 推送 | 保留 Worktree | 清理分支 |
|---|---|---|---|---|
| 1. 本地合并 | ✓ | - | - | ✓ |
| 2. 创建 PR | - | ✓ | ✓ | - |
| 3. 保持现状 | - | - | ✓ | - |
| 4. 丢弃 | - | - | - | ✓（强制） |
跳过测试验证
开放式提问
自动清理 worktree
丢弃时不确认
绝不：
始终：
被以下技能调用：
搭配使用：
在进行任何创造性工作前必须使用——创建功能、构建组件、添加新功能或修改行为。在实现之前先探索用户意图、需求和设计。
TypeScript 和 React 开发的编码标准与最佳实践。在编写或审查代码时激活。提供命名、类型、组件设计、Hook 提取、状态管理等规范。
在用户确认要提交代码变更时使用——安全检查 diff 中的敏感数据后执行 git commit
在面对 2 个以上互不依赖、无共享状态的独立任务时使用
当有已编写的实现计划需要在独立会话中执行时使用，包含评审检查点
收到代码评审反馈后、实现建议之前使用，尤其当反馈不清楚或技术上存疑时——要求技术严谨性和验证，而非表演性附和或盲目实现