babysit-pr

PR 保姆

目标

持续跟进 PR，直到出现以下任一最终结果：

• PR 已合并或关闭。
• 出现需要用户帮助的情况（例如 CI 基础设施问题、重试次数耗尽后仍反复出现的间歇性失败、权限问题，或无法安全解决的歧义）。
• 可选交接里程碑：PR 当前检查通过、可合并且没有待处理的审查意见。将此视为进度状态，而不是停止监控的条件，以便在 PR 仍处于开放状态时及时发现之后出现的审查意见。

如果检查仍在进行中，不要仅仅因为某次快照返回 idle 就停止。

输入

接受以下任意一种输入：

• 未提供 PR 参数：根据当前分支推断 PR（--pr auto）
• PR 编号
• PR URL

核心工作流

1. 当用户要求“监控”“关注”或“持续跟进”某个 PR 时，使用监控器的持续模式（--watch）启动，除非你有意只进行一次诊断快照。
2. 运行监控器脚本，获取 PR／审查／CI 状态快照（或使用 --watch 流式输出的每个快照）。
3. 检查 JSON 响应中的 actions 列表。
4. 如果出现 diagnose_ci_failure，检查失败运行的日志并对失败进行分类。
5. 如果失败很可能由当前分支导致，在本地修补代码、提交并推送。不要修补随机出现的间歇性测试故障、CI 基础设施问题、依赖服务中断、运行器问题或其他与该分支无关的故障。
6. 如果出现 process_review_comment，检查已显示的已发布审查项，并判断是否需要处理。
7. 如果审查项确实有效且可处理，在本地修补代码、提交并推送，然后仅在下文的 GitHub 状态变更政策允许时，才解决关联的审查讨论串。
8. 除非用户明确确认确切回复内容，否则不要回复由人撰写的审查评论／讨论串。如果某个人工审查项无需处理、已处理或无效，应向用户说明该审查项及建议的回复，而不是在 GitHub 上回复。
9. 如果失败很可能是间歇性或无关的，且出现 retry_failed_checks，使用 --retry-failed-now 重新运行失败的任务。
10. 如果同时出现可处理的审查反馈和 retry_failed_checks，优先处理审查反馈；新提交会重新触发 CI，因此除非你有意延后审查变更，否则不要对旧 SHA 重新运行间歇性失败的检查。
11. 每轮都先查找新出现的审查反馈，再处理 CI 失败或可合并状态；同时检查可合并状态／合并冲突状态（例如通过 gh pr view），并查看 CI 状态。
12. 每次推送或重新运行后，立即返回第 1 步，并针对更新后的 SHA／状态继续轮询。
13. 如果暂停前一直在使用 --watch，则在推送后必须在同一轮中立即自行重新启动 --watch（不要等用户再次调用该技能）。
14. 持续轮询，直到出现 stop_pr_closed 或遇到必须由用户协助解决的阻塞问题。检查通过、没有待处理审查意见且可合并的 PR 是一个进度里程碑，而不是 PR 仍开放时停止监控的理由。
15. 保持终端／会话所有权：持续跟进期间，在同一轮中持续读取监控器输出；不要让分离运行的 --watch 进程继续运行，然后结束本轮并假装监控已完成。

命令

单次快照

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --once

持续监控（JSONL）

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --watch

触发间歇性失败的重试周期（仅当监控器提示时）

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --retry-failed-now

明确指定 PR 目标

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr <number-or-url> --once

CI 故障分类

决定是否重新运行前，使用 gh 命令检查失败的运行。

• gh run view <run-id> --json jobs,name,workflowName,conclusion,status,url,headSha
• gh api repos/<owner>/<repo>/actions/runs/<run-id>/jobs -X GET -f per_page=100
• gh api repos/<owner>/<repo>/actions/jobs/<job-id>/logs > /tmp/codex-gh-job-<job-id>-logs.zip
• 整个工作流运行完成后，可将 gh run view <run-id> --log-failed 用作备用方案

gh run view --log-failed 的作用范围是整个工作流运行，且在整个运行完成前可能无法显示失败作业的日志。为更快诊断，请先轮询运行中的作业；一旦某个具体作业失败，就直接从 Actions 作业日志端点获取该作业的日志。GitHub 提供相关信息时，监视器会在 failed_jobs 列表中包含每个失败作业的 job_id 和 logs_endpoint。

如果失败作业的日志指向已更改的代码（例如，受影响区域中的编译、测试、lint、类型检查、快照或静态分析），优先将失败归类为与分支相关。

如果日志显示是暂时性的基础设施或外部问题（例如，超时、Runner 配置失败、注册表或网络中断、GitHub Actions 基础设施错误），优先将失败归类为暂时性或无关问题。

除非日志明确表明失败与 PR 分支有关，否则不要通过更改测试、构建脚本、CI 配置、依赖项固定版本或与基础设施相关的代码来尝试修复暂时性或无关的失败。对于暂时性或无关的失败，只有在监视器建议使用 retry_failed_checks 时才重新运行；否则请等待或停止并寻求用户帮助。

如果分类不明确，请先手动诊断一次，再决定是否重新运行。

阅读 .codex/skills/babysit-pr/references/heuristics.md，查看简明检查清单。

处理评审评论

监视器会显示以下来源的评审条目：

• PR 问题评论
• 行内评审评论
• 评审提交（COMMENT / APPROVED / CHANGES_REQUESTED）

仅处理已发布的反馈。忽略处于 GitHub PENDING 状态的评审提交，以及附加到这些待处理评审的行内评论。不要将待处理评审中的反馈标记为已查看；评审者提交评审后，这些反馈仍应符合显示条件。

除了人工评审者的反馈外，监视器还会有意显示 Codex 评审机器人提供的反馈（例如来自 chatgpt-codex-connector[bot] 的评论/评审）。大多数无关的机器人噪声仍应忽略。 出于安全考虑，监视器只会自动显示受信任的人工评审者（例如仓库 OWNER/MEMBER/COLLABORATOR，以及已通过身份验证的操作者）和获准的评审机器人（例如 Codex）的反馈。 对于全新的监视器状态文件，现有未处理的已发布评审反馈可能会立即显示（而不只是监控开始后新收到的评论）。这是有意为之，以免遗漏已经存在的未关闭评审评论。

当你同意某条评论且该评论需要采取行动时：

1. 在本地修改代码。
2. 使用 codex: address PR review feedback (#<n>) 提交更改。
3. 推送到 PR 头部分支。
4. 推送成功后，仅在符合下文 GitHub 状态更改政策的情况下，解决关联的 GitHub 评审讨论线程。
5. 立即在新的 SHA 上恢复监视（不要在报告推送后停止）。
6. 如果监控以 --watch 模式运行，则在同一轮对话中，推送后立即重新启动 --watch；不要等用户再次提出要求。

不要自动回复人工撰写的 GitHub 评审评论/讨论线程。如果你不同意人工评论、认为其无需处理/已处理，或需要回答问题，请向用户报告该条目并提供建议回复，然后等待明确确认后再在 GitHub 上发布任何内容。如果用户批准了回复，请在回复前加上 [codex]，以明确说明该回复是自动生成的，而非来自人工用户。 如果监视器之后显示了你自己获准发布的回复（因为已通过身份验证的操作者会被视为受信任的评审者），则将这条自我撰写的条目视为已处理，不要再次回复。 如果某条代码评审评论/讨论线程已在 GitHub 上标记为已解决，则将其视为无需处理并安全忽略，除非之后出现新的未解决后续反馈。

GitHub 状态更改政策

你可以读取监控所需的任何 PR 状态。写入操作必须遵守此政策。

你可以按上述说明推送 PR，以更新正在评审的代码或强制重新运行 CI。

你可以解决来自要求你监控 PR 的用户或 Codex 评审机器人的评审评论讨论线程。解决时，留下以 [from Codex]: 开头的评论，说明你做了哪些更改以及这些更改包含在哪个提交中。如果其他人类用户（要求监控 PR 的用户除外）参与过讨论线程，则不要处理该线程。

执行任何更改前，请自行获取 PR 状态，不要依赖 PR 监视器脚本的输出。

除非得到明确要求，否则不要：

• 评论其他人的评审讨论线程；请改为在聊天中与用户沟通
• 解决用户以外其他人的评审讨论线程
• 与用户以外的其他人互动
• 将 PR 标记为草稿或准备评审
• 关闭或重新打开 PR

总的来说，绝不要以让其他人难以判断某项可见操作究竟由你还是用户执行的方式在 GitHub 上采取行动。如有疑问，请在聊天中向用户澄清。

Git 安全规则

• 仅在 PR 头部分支上工作。
• 避免使用破坏性 Git 命令。
• 除非有必要恢复上下文，否则不要切换分支。
• 编辑前，检查是否存在无关的未提交更改。如果存在，请停止并询问用户。
• 每次成功修复后，都要提交并执行 git push，然后重新运行监控程序。
• 如果为了修复问题而中断了正在运行的 --watch 会话，请在同一轮中推送后立即重新启动 --watch。
• 不要为同一个 PR／状态文件同时运行多个 --watch 进程；保持一个监控会话运行，并重复使用，直到它停止或你有意重启它。
• 推送并不代表任务结束；除非满足严格的停止条件，否则请继续监控循环。

默认提交消息：

• codex: fix CI failure on PR #<n>
• codex: address PR review feedback (#<n>)

监控循环模式

在 Codex 实时会话中使用此循环：

1. 运行 --once。
2. 查看 actions。
3. 首先检查 PR 是否已合并或以其他方式关闭；如果是，报告此终止状态并立即停止轮询。
4. 检查 CI 摘要、新的审查项以及可合并状态／冲突状态。
5. 诊断 CI 失败，并将其归类为与分支相关或偶发／无关。如果整体运行仍在等待，但 failed_jobs 已包含失败的任务，请立即获取该任务的日志并进行诊断，而不要等待整个工作流运行结束。只有失败与分支相关时才进行修复。
6. 对于其他作者提出的每条新审查项，如果可以采取行动，则修复、提交并推送，然后仅在上述 GitHub 状态变更策略允许时将其标记为已解决。如果该项无法采取行动、已处理，或需要书面答复，请向用户说明并建议回复内容，而不要自动发布。如果后续快照显示你自己已获批准的回复，将其视为参考信息并继续，不要再次回复。
7. 如果可处理的审查评论与偶发失败重跑同时出现，先处理审查评论；如果审查修复需要提交，请推送修复并跳过对旧 SHA 上失败检查的重跑。
8. 仅当出现 retry_failed_checks 且你不会立即用审查／CI 修复提交替换当前 SHA 时，才重试失败的检查。不要为了让 CI 变绿而针对无关的偶发问题或基础设施故障修改代码。
9. 如果你推送了提交、将符合条件的审查线程标记为已解决，或触发了重跑，请简要报告该操作并继续轮询（不要停止）。如果需要针对人工审查评论在 GitHub 上作出书面回复，请停止并在发布前征求确认。
10. 推送审查修复后，除非已达到严格停止条件，否则应在同一轮操作中主动重新启动持续监控（--watch）。
11. 如果所有检查均通过、可合并、未受必须获得审查批准的条件阻挡，并且没有尚未处理的审查项，请报告 PR 当前已可合并，但继续运行监控器，以便在 PR 仍处于打开状态时快速发现新的审查评论。
12. 如果因需要用户协助的问题（基础设施中断、偶发失败重试次数已用尽、审查者请求不明确、权限问题）而受阻，请报告阻碍并停止。
13. 否则，按照下方的轮询间隔休眠，然后重复操作。

当用户明确要求监控／关注／持续照看 PR 时，优先使用 --watch，让轮询通过单条命令自主持续运行。仅在调试、本地测试或用户明确要求单次检查时，才重复使用 --once 快照。 不要停下来询问用户是否继续轮询；应自主继续，直到达到严格停止条件或用户明确中断。 推送审查修复后，不要仅因生成了新的 SHA 就将控制权交还给用户；重新启动监控器并重新进入轮询循环，是同一持续照看任务的一部分。 如果 --watch 进程仍在运行，且尚未达到严格停止条件，则持续照看任务仍在进行中；继续接收／读取监控器输出，而不要结束本轮操作。

轮询间隔

保持频繁的审查轮询，即使 CI 已转绿也要继续监控：

• CI 尚未转绿（等待中／运行中／排队中或失败）：每 1 分钟轮询一次。
• CI 转绿后：只要 PR 仍处于打开状态，就继续按基本间隔轮询，及时发现新发布的审查评论，而不要因绿色状态而延长轮询间隔。
• 任何内容发生变化时（新提交／SHA、检查状态变化、新审查评论、可合并状态变化、审查结论变化），立即重置轮询间隔。
• 如果 CI 再次变为非绿色（新提交、重跑或回归），则保持基本轮询间隔。
• 如果任何一次轮询显示 PR 已合并或以其他方式关闭，请立即停止轮询并报告终止状态。

停止条件（严格）

仅在满足以下任一条件时停止：

• PR 已合并或关闭（轮询/快照一旦确认，立即停止）。
• 需要用户介入，且 Codex 无法安全地独自继续。

以下情况继续轮询：

• actions 仅包含 idle，但检查仍在等待中。
• CI 仍在运行或排队。
• 审查状态没有变化，但 CI 尚未进入终态。
• CI 已通过，但是否可合并仍未知或待确认。
• CI 已通过且可合并，但 PR 仍处于打开状态，并且你正在等待可能出现的新审查评论或合并冲突变更。
• PR 的 CI 已通过，但仍因等待审查批准而受阻（REVIEW_REQUIRED / 类似状态）；继续按基本轮询频率轮询，并在有新审查评论时及时告知，不要询问是否继续监控。

输出要求

监控期间提供简洁的进度更新，并在最终摘要中包含：

• 长时间监控且状态未变时，避免每次轮询都发送完整更新；仅总结状态变化，并偶尔发送心跳更新。

• 推送确认、中间 CI 快照、已可合并快照和审查操作更新都只作为进度更新；只有满足严格停止条件后，才发送最终摘要或结束持续监控。

• 用户要求“监控”时，不能只进行几次示例轮询；持续循环，直到满足严格停止条件或用户明确中断。

• 审查修复提交并推送不代表任务完成；应立即在同一轮中恢复实时监控（--watch），并继续报告进度更新。

• 当前 SHA 的 CI 首次全部通过时，发送一次庆祝性进度更新（后续绿色轮询中不要重复）。推荐格式：🚀 CI is all green! 33/33 passed. Still on watch for review approval.

• 只要监控器仍在运行，就不要发送最终摘要，除非监控器已发出/确认严格停止条件；否则继续发送进度更新。

• 最终 PR SHA

• CI 状态摘要

• 可合并状态 / 冲突状态

• 已推送的修复

• 使用的易失败测试重试轮次

• 尚未解决的失败或审查评论

参考资料

• 启发式规则与决策树：.codex/skills/babysit-pr/references/heuristics.md
• 监控器使用的 GitHub CLI/API 详细信息：.codex/skills/babysit-pr/references/github-api-notes.md