settle-effort

收尾工作

批准拉取请求是用户要做的最后一步。之后的所有事情都由你负责。

步骤

1. **找到这项工作：**拉取请求、其分支、规范、工单和交接内容，以及构建遗留的所有工作树和分支，包括委托任务留下的内容。
   • **如果当前检出不在这项工作的分支上：**使用 gh pr list --head 和 --state all 按头部分支列出拉取请求，因为不加 --state all 就不会显示已合并的拉取请求。
2. 检查通过后合并拉取请求，并确认合并后默认分支的 CI 通过。使用 gh pr merge 和项目常用的方法进行合并，不要加 --delete-branch：它会在确认合并之前删除分支，并将当前检出切换到默认分支。
   • **如果拉取请求是堆叠的，**其基分支是另一个拉取请求的分支：请在基拉取请求合并后再合并它，并在删除基分支前使用 gh pr edit --base 将其目标分支改为默认分支，因为删除基分支会永久关闭它。
   • **如果会话中有 session-status 工具：**合并前，按照 /settle-session > “Steps” > Nothing undecided 的说明，提出其中未处理的 before_settling 和 blocked 决策，因为答案可能会改变合并决定。
   • **如果规范写着 “QA: blocking”：**只有所有 QA 工单都已关闭后才能合并。在此之前，告知用户哪些工单仍未关闭，并在此处暂停收尾；待它们关闭后再继续。
   • **如果合并后默认分支的 CI 失败：**在第 5 步前停止，告知用户失败情况，并由用户决定提交工单还是修复。
   • **执行 squash 或 rebase 后：**检查任何固定到该分支某个提交的内容（例如带提交 SHA 的图片 URL）是否仍可访问，因为默认分支不包含这些提交。
   • **如果拉取请求已合并：**跳过合并，但仍需检查默认分支的 CI，以及 squash 或 rebase 后固定到提交的内容。
3. **阅读拉取请求说明和交接内容，**了解交付留下了哪些待处理事项：后续工作、跳过的检查，以及需要用户决定的事项。
4. **执行第 3 步中的所有后续工作和跳过的检查，**例如安装变更内容，或尝试只能在合并后进行的事项，并记录每项结果以便汇报。
   • **如果合并包含版本升级：**按照项目的 docs/agents/releasing.md，从合并后的步骤开始执行，直至完成检查，并在报告中注明每个环节的版本。将页面上要求用户完成的步骤（例如需要用户提供凭据才能发布）交给用户，并等待用户完成后再进行检查。如果项目没有发布说明页面，请告知用户并提供 /set-up-project，该命令会创建一个。
5. **将未完成的工作转到下一项工作中，**创建对应工单，标明所属工作并链接回各自的来源。gh issue create --label 在标签不存在时会失败，因此请先用 gh label create 创建缺失的 effort: 标签。然后关闭规范以及合并已完成的所有工单；如果某个工单未被任何 “closes” 关键词关闭，请手动关闭。
   • **如果不清楚下一项工作是什么：**询问用户。
   • **对于 QA 工单：**保持其未关闭，并评论说明如何访问构建版本。
6. **使用 /settle-session 收尾会话，**列出第 1 步中的所有工作树和分支，以便评估清理。保持调用方和终端拓扑不变；仅释放符合 /settle-session 条件且已确认合并、无人占用的工作树。还要让其报告说明合并了什么、关闭了什么、转交了什么，以及第 4 步中每项后续工作得出了什么结果。