babysit-pr

看护 PR

许多仓库都有 AI 审查机器人。它们很有帮助，即使并非总是正确。

等待

绝不要编写自己的监视器、轮询循环或 sleep 循环。每个 PR 只使用一个监视器：在 T3 Code 中使用 watch_pull_request，其他地方使用 pr-wait。绝不要对同一个 PR 同时运行两者。一个 GitHub 账户上的所有监视器共享同一个速率限制。

在 T3 Code 中：watch_pull_request

先处理现有的检查和评论。然后调用 watch_pull_request 并结束本轮。检查失败、必需检查通过、有人评论或审查，或者分支发生冲突时，T3 Code 会通过消息唤醒你。

• 只有负责该 PR 的线程才会监视它。 如果你是受委派的子任务（审查员、Sol 轮次，或任何 delegate_task 子任务），绝不要调用 watch_pull_request。PR 由父任务负责。不要监视你未参与处理的 PR。
• 唤醒表示有新消息，不代表可以合并。 自行检查合并门槛。
• 交接时取消监视。 被监视的线程会保持在 Working 状态，不会出现在用户的收件箱中。停止处理时（已就绪、遇到阻塞，或需要向用户提问），先调用 unwatch_pull_request。合并或关闭 PR 时，监视会自动结束。
• “已停止监视，但无法读取” 通常表示 GitHub 速率限制已耗尽。再次监视前，运行 gh api rate_limit --jq .resources.graphql。如果 remaining 接近 0，使用一条后台命令等待至 reset，然后再监视。绝不要在紧密循环中再次监视。

在其他地方：pr-wait

使用此技能目录中的 scripts/pr-wait 等待（使用其绝对路径）。

pr-wait <pr> [--repo owner/name] [--until ready|green|any-change]

每发生一个实际事件，它就会输出一行。当满足 --until 条件或 PR 合并时，它以 0 退出；需要你处理时（必需检查失败、存在冲突、未解决的讨论串、PR 已关闭）以 1 退出；输入错误时以 2 退出。

• ready（默认）：必需检查全部通过，Greptile 或 Macroscope 已审查最新提交，且没有未解决的讨论串。看护 PR 时使用此选项。
• green：仅检查必需检查。仓库没有 Greptile 或 Macroscope 时使用此选项。
• any-change：在第一个事件发生时退出。

在 Claude Code 中，使用 Monitor 工具运行它（timeout_ms: 3600000），这样每一行都会唤醒你。没有监视器时，将其作为一条长命令运行。它会自行结束。

推送后、处理完退出代码 1 后，以及恢复处理后，都要重新启动它。它会记住已报告的内容，因此期间发生的事件不会丢失。如果它提示另一个 pid 已在监视该 PR，不要启动第二个。只有旧进程的事件无法传达到你这里时，才终止它。

使用任一监视器时：如果事件不需要采取行动，结束本轮，不要发送消息。绝不要发布或说“仍在等待”。

GitHub 速率限制

gh pr create、gh pr view 和 gh pr checks 使用 GraphQL。GraphQL 额度耗尽时，REST 限额是独立的，通常仍有余量。使用 gh api repos/<owner>/<repo>/pulls/<n> 读取 PR，并使用 gh api repos/<owner>/<repo>/commits/<sha>/check-runs 查看检查。

评审

仅处理最新一次推送之后的新检查结果和评论。修改代码前，先根据源代码核实每条机器人发现。修复确实存在的问题和 CI 失败，区分仓库问题与基础设施偶发故障；驳回误报时，写明理由。

如果仓库中有 .macroscope/check-run-agents/*.md，回复 Macroscope 发现之前，先阅读其中的规则。它的发现会引用这些规则。

CodeRabbit 仅提供建议。像对待其他发现一样处理它的发现，但绝不要等待它，也不要因此阻止合并。

如果评审机器人留下的反馈不值得处理，请写明理由并解决该评论。代表用户发布的每条评论都要使用 leaving-pr-comments 技能。

如果你有上传截图和视频的方式，也可以提供它们。

让 PR 保持满足用户目标所需的规模。评审往往会因为每次看似代价低的修复而不断扩大 PR。在预期场景中修复真正的 Bug。其余问题都应写明理由后拒绝，并列为后续事项： 不必要的测试、针对无关边缘情况的防护、额外的集成或兼容性处理，以及轻微的性能开销。优先选择能删除或缩小代码的修复方案。

基准分支与合并

密切关注 main 的变更，并在需要时进行变基。pr-wait 会报告新的基准提交是否涉及此 PR 的文件，以及 PR 是否变为 BEHIND 或 DIRTY。watch_pull_request 只会报告冲突，因此，在宣布 PR 已就绪之前，请自行检查是否为 BEHIND。 如果有重叠的 PR 使此 PR 失效，请停止监控，告知用户；除非用户明确授权关闭 PR，否则先征求其同意。

如果没有任何变化，请保持安静，不要发布凑数的评论。pr-wait 退出码为 0 时停止；在 T3 Code 中，则在最新提交通过合并门禁后停止。只有用户明确要求时才合并；否则报告 PR 已就绪。合并前，先运行 git fetch 并重新检查 PR。如果 PR 处于 BEHIND 或 DIRTY，或者上次成功运行后合入的基准提交涉及此 PR 的文件，则绝不要合并。先变基、推送，再等待检查重新通过。