メニュー
当撰写完成，所有逻辑检查通过，你需要决定如何整合工作时使用——通过展示清晰的合并、提交审阅或清理选项来指导完成开发工作
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
当面临 2+ 个独立任务，可以在没有共享状态或顺序依赖的情况下工作时使用
当在当前会话中执行具有独立任务的撰写计划时使用
当你有一个书面的撰写实施计划，需要在一个单独的会话中执行，并带有审查检查点时使用
当收到同行评审反馈时使用，在实施建议之前，特别是当反馈看起来不清楚或在学术上值得商榷时——需要学术严谨和验证，而不是表演性的同意或盲目实施
在进行任何创造性工作之前必须使用此技能——无论是撰写新章节、构建理论框架、增加论据还是修改论证逻辑。在撰写正文之前，先探索研究目标、要求和论证设计。
当开始撰写需要与当前工作区隔离的新章节，或在执行撰写计划之前使用——通过智能目录选择和安全验证创建隔离的草稿分支
| name | sa-finalization |
| description | 当撰写完成，所有逻辑检查通过，你需要决定如何整合工作时使用——通过展示清晰的合并、提交审阅或清理选项来指导完成开发工作 |
通过展示清晰的选项并处理所选工作流来指导完成撰写工作。
核心原则： 验证逻辑 → 展示选项 → 执行选择 → 清理。
开始时声明： “我正在使用 finalization 技能来完成这项工作。”
在展示选项之前，验证逻辑检查通过：
# 运行项目的验证套件
make verify / ./scripts/check_logic.sh
如果验证失败：
验证失败（<N> 个问题）。必须在完成前修复：
[展示失败]
在验证通过之前无法进行合并/提交审阅。
停止。不要进行到步骤 2。
如果验证通过： 继续步骤 2。
# 尝试常见基础分支
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. 丢弃此草稿
哪个选项？
不要添加解释 - 保持选项简洁。
# 切换到基础分支
git checkout <base-branch>
# 拉取最新
git pull
# 合并草稿分支
git merge <feature-branch>
# 在合并结果上验证逻辑
<verification command>
# 如果验证通过
git branch -d <feature-branch>
然后：清理工作树（步骤 5）
# 推送分支
git push -u origin <feature-branch>
# 创建 PR
gh pr create --title "<title>" --body "$(cat <<'EOF'
## 摘要
<2-3 点变更内容>
## 验证计划
- [ ] <验证步骤>
EOF
)"
然后：清理工作树（步骤 5）
报告：“保留分支 。工作树保留在 。”
不要清理工作树。
首先确认：
这将永久删除：
- 分支 <name>
- 所有提交：<commit-list>
- 位于 <path> 的工作树
输入 'discard' 以确认。
等待确切的确认。
如果已确认：
git checkout <base-branch>
git branch -D <feature-branch>
然后：清理工作树（步骤 5）
对于选项 1, 2, 4:
检查是否在工作树中：
git worktree list | grep $(git branch --show-current)
如果是：
git worktree remove <worktree-path>
对于选项 3: 保留工作树。
| 选项 | 合并 | 推送 | 保留工作树 | 清理分支 |
|---|---|---|---|---|
| 1. 本地合并 | ✓ | - | - | ✓ |
| 2. 创建 PR | - | ✓ | ✓ | - |
| 3. 保持原样 | - | - | ✓ | - |
| 4. 丢弃 | - | - | - | ✓ (强制) |
跳过逻辑验证
开放式问题
自动清理工作树
丢弃无确认
绝不：
始终：
调用者：
配对：