done

完成

发布当前分支——可以更新现有 PR、在本地合并到 main，或在 main 受保护时创建 PR。

确定性的流程（检查 PR → 检查保护状态 → 快进合并 → 推送）位于 scripts/ship.sh 中，因此常见的本地合并路径可以一次完成，而不必经过多轮模型交互。判断要发布什么需要审慎，因此脚本绝不会暂存或提交——由你有意提交；脚本要求工作树干净且所有更改均已提交，然后才会合并并推送。脚本只会自动完成明确无误的顺利流程；遇到任何特殊情况时，它会打印 HANDOFF（其中已收集完整状态），由你接手处理。

工作流

0. 发布前检查——验证仓库要求

查找并阅读适用于此仓库和运行环境的约定／说明文件（例如 AGENTS.md、CLAUDE.md、CONTRIBUTING.md、.cursor/rules/*、.github/copilot-instructions.md、.clinerules 等，并遵循所有 @ 引用文件）。验证分支是否符合规则；继续之前先修复或指出缺漏。如果仓库要求发布前运行检查（例如 just ci），现在就运行。

1. 检查并提交

查看 git status／差异，确认工作树中只有你打算发布的更改——留意无关编辑或意外的未跟踪文件。谨慎暂存（只有确认工作树中没有不该发布的内容后，才使用 git add -A；否则只暂存特定路径），然后撰写合适的提交说明并提交。确保工作树保持干净。

2. 运行发布脚本

在分支的工作树中运行：

skills/done/scripts/ship.sh

脚本会先打印 === SHIP: STATE === 区块，然后显示以下结果之一：

• === SHIP: DONE ===——本地合并的顺利流程已完成（默认分支已快进到你的提交，已推送到 origin，工作树保持不变）。前往步骤 3。
• === SHIP: HANDOFF ===——脚本按预期停止；查看 suggested_path: 和 reason: 行，然后按下文继续。STATE 区块信息完整，因此无需重新收集。
• === SHIP: ERROR ===——某个步骤失败；查看 step:／detail:，调查原因并手动解决。

suggested_path 路由：

suggested_path	含义	操作
update-pr	已有一个开放的 PR	步骤 2a
create-pr	默认分支受保护	步骤 2b
commit	工作树中有未提交的更改	检查这些更改（步骤 1）——排除无关内容——提交后重新运行步骤 2
resolve	正在进行合并／变基／冲突处理	解决后重新运行步骤 2
manual	HEAD 分离、当前位于默认分支、落后于 origin，或分支已分叉	处理指出的情况后重新运行步骤 2
nothing	没有需要发布的内容	向用户确认；很可能已经发布

2a. 更新现有 PR

将当前分支推送到其远程仓库，以更新 PR：

wt step push

然后在 PR 上发表评论，概述所做更改。

2b. 创建 PR（main 受保护）

推送当前分支并创建 PR：

wt step push
gh pr create --fill

3. 更新相关工单

如果已知有相关工单（Jira、Linear、GitHub issue 等，可从分支名称、提交说明、PR 正文或对话上下文中获知），请更新其状态以反映发布情况：

• PR 已更新 → 如果工单尚未处于相应状态，将其移至“In Review”（或同等状态）
• 已合并到 main（通过本地合并或合并 PR）→ 将工单移至“Done”／“Closed”／“Shipped”

如果没有明显关联的工单，则跳过此步骤——不要猜测。

4. 确认

根据脚本输出（或你采用的 PR 流程）报告实际结果：

• 本地合并（SHIP: DONE）：打印默认分支上 old → new 的提交范围以及更改摘要
• PR 已更新：打印 PR URL
• PR 已创建：打印 PR URL
• 工单已更新：打印工单 ID 和新状态（如适用）

参考

• scripts/ship.sh——确定性的本地合并流程；其中的决策树是权威依据。
• wt 命令的详细信息请参阅 references/worktrunk.md。