Back to Details

babysit-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Babysit PR

看守 PR

Many repos have AI review bots. They're helpful, even if they are not always right.
许多仓库都有 AI review bot。它们很有帮助，尽管并不总是正确。

Waiting

等待

Never write your own watcher, polling loop, or 
sleep
loop. Use one watcher per PR: 
watch_pull_request
in T3 Code, 
pr-wait
everywhere else. Never run both on the same PR. Every watcher on a GitHub account shares one rate limit.
绝不要自行编写 watcher、轮询循环或 
sleep
循环。每个 PR 只能使用一个 watcher：在 T3 Code 中使用 
watch_pull_request
，在其他地方使用 
pr-wait
。绝不要对同一个 PR 同时运行两者。同一 GitHub 账户上的所有 watcher 共享一个速率限制。

In T3 Code: 
watch_pull_request

在 T3 Code 中：
watch_pull_request

Handle the existing checks and comments first. Then call 
watch_pull_request
and end your turn. T3 Code wakes you with a message when a check fails, the required checks pass, someone comments or reviews, or the branch conflicts.
  • Only the thread that owns the PR watches it. If you are a delegated child task (a reviewer, a Sol round, any 
    delegate_task
    child), never call 
    watch_pull_request
    . The parent owns the PR. Do not watch PRs you are not working on.
  • A wake is news, not a merge decision. Check the merge gate yourself.
  • Unwatch when you hand off. A watched thread stays in Working and out of the user's inbox. When you stop (ready, blocked, or asking the user a question), call 
    unwatch_pull_request
    first. A merge or close ends the watch on its own.
  • "Stopped watching, could not read it" usually means GitHub's rate limit is used up. Run 
    gh api rate_limit --jq .resources.graphql
    before you watch again. If 
    remaining
    is near 0, wait for 
    reset
    with one background command, then watch again. Never watch again in a tight loop.
先处理现有的检查项和评论。然后调用 
watch_pull_request
并结束当前回合。T3 Code 会在以下情况下通过消息唤醒你：某个检查失败、required checks 通过、有人发表评论或提交 review，或者 branch 出现冲突。
  • 只有拥有该 PR 的 thread 才能监控它。 如果你是 delegated child task（reviewer、Sol round 或任何 
    delegate_task
    child），绝不要调用 
    watch_pull_request
    。父任务负责该 PR。不要监控你未参与处理的 PR。
  • 唤醒代表有新动态，而不是合并决定。 请自行检查 merge gate。
  • 交接时取消监控。 被监控的 thread 会保持在 Working 状态，不会进入用户的 inbox。当你停止工作（ready、blocked，或准备向用户提问）时，先调用 
    unwatch_pull_request
    。合并或关闭 PR 会自动结束监控。
  • "Stopped watching, could not read it" 通常表示 GitHub 的速率限制已耗尽。再次监控前先运行 
    gh api rate_limit --jq .resources.graphql
    。如果 
    remaining
    接近 0，用一个后台命令等待至 
    reset
    ，然后再次监控。绝不要在紧密循环中反复监控。

Everywhere else: 
pr-wait

在其他环境中：
pr-wait

Wait with 
scripts/pr-wait
from this skill's directory (use its absolute path).
bash
pr-wait <pr> [--repo owner/name] [--until ready|green|any-change]
It prints one line per real event. It exits 0 when the 
--until
condition is met or the PR merges, 1 when it needs you (a required check failed, conflicts, unresolved threads, PR closed), and 2 on bad input.
  • ready
    (default): required checks green, Greptile or Macroscope reviewed the head, and no unresolved threads. Use this to babysit.
  • green
    : required checks only. Use it when the repo has no Greptile or Macroscope.
  • any-change
    : exit on the first event.
In Claude Code, run it with the Monitor tool (
timeout_ms: 3600000
), so each line wakes you. Without a monitor, run it as one long command. It ends on its own.
Start it again after you push, after you handle an exit 1, and after a resume. It remembers what it already reported, so nothing that arrived in between is lost. If it says another pid already watches the PR, do not start a second one. Kill the old one only if its events do not reach you.
With either watcher: when an event needs no action, end your turn without a message. Never post or say "still waiting".
使用此 skill 目录中的 
scripts/pr-wait
等待（使用其绝对路径）。
bash
pr-wait <pr> [--repo owner/name] [--until ready|green|any-change]
每个实际事件会打印一行。当 
--until
条件满足或 PR 合并时，退出码为 0；需要你介入时（required check 失败、冲突、存在未解决的 thread、PR 已关闭），退出码为 1；输入无效时，退出码为 2。
  • ready
    （默认）：required checks 全部为 green，Greptile 或 Macroscope 已审查 head，且没有未解决的 thread。看守 PR 时使用此模式。
  • green
    ：仅检查 required checks。当仓库没有 Greptile 或 Macroscope 时使用。
  • any-change
    ：在第一个事件发生时退出。
在 Claude Code 中，使用 Monitor 工具运行它（
timeout_ms: 3600000
），这样每一行都会唤醒你。未使用 monitor 时，将其作为一条长时间运行的命令执行。它会自行结束。
推送后、处理退出码 1 后以及恢复会话后，再次启动它。它会记住已经报告过的内容，因此不会遗漏期间到达的事件。如果它提示另一个 pid 已在监控该 PR，不要启动第二个。只有当旧进程的事件无法传达到你时，才将其终止。
使用任一 watcher 时，如果某个事件不需要采取行动，请直接结束回合，不要发送消息。绝不要发布或说 "still waiting"。

GitHub rate limits

GitHub 速率限制

gh pr create
, 
gh pr view
, and 
gh pr checks
use GraphQL. When GraphQL is used up, the REST limit is separate and usually still has room. Use 
gh api repos/<owner>/<repo>/pulls/<n>
to read a PR, and 
gh api repos/<owner>/<repo>/commits/<sha>/check-runs
for checks.
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
检查状态。

Reviews

审查

Only act on checks and comments newer than the latest push. Verify every bot finding against the source before changing code. Fix real findings and CI failures, distinguish repository failures from infrastructure flakes, and reply with a written reason when dismissing false positives.
If the repo has 
.macroscope/check-run-agents/*.md
, read those rules before you reply to a Macroscope finding. Its findings cite them.
CodeRabbit is advisory. Treat its findings like any other finding, but never wait for it and never hold a merge for it.
If a review bot leaves feedback you believe is not worth addressing, reply with a written reason and resolve the comment. Use the 
leaving-pr-comments
skill for every comment posted on the user's behalf.
Screenshots and videos help as well, when you have a way to upload them.
Keep the PR at the size the user's goal needs. Review loops tend to grow a PR one cheap-looking fix at a time. Fix real bugs in the intended case. Decline the rest with a written reason, and list them as follow-ups: unneeded tests, guards for edge cases that do not matter, extra integration or compatibility, and small performance costs. Prefer the fix that deletes or narrows code.
只处理晚于最近一次 push 的检查项和评论。修改代码前，应结合源代码核实每个 bot finding。修复真实存在的问题和 CI 失败，区分仓库自身的问题与基础设施偶发故障，并在驳回误报时给出书面理由。
如果仓库中存在 
.macroscope/check-run-agents/*.md
，请在回复 Macroscope finding 前阅读其中的规则。相关 finding 会引用这些规则。
CodeRabbit 的意见仅供参考。像处理其他 finding 一样处理它的意见，但绝不要等待它，也绝不要因此推迟合并。
如果 review bot 留下了你认为不值得处理的反馈，请给出书面理由并解决该评论。凡是以用户名义发布的评论，都应使用 
leaving-pr-comments
skill。
如果有上传途径，截图和视频也能提供帮助。
将 PR 控制在用户目标所需的规模。审查循环往往会每次为 PR 增加一个看似代价很低的修复。只修复目标场景中的真实 bug。对于其余建议，应给出书面理由并将其列为后续事项：不必要的测试、与无关紧要边界情况相关的 guard、额外的集成或兼容性工作，以及小幅性能开销。优先采用能够删除或收窄代码的修复方案。

Base branch and merging

基础分支与合并

Keep an eye on changes to 
main
and rebase when needed. 
pr-wait
reports when new base commits touch this PR's files, and when the PR becomes BEHIND or DIRTY. 
watch_pull_request
reports conflicts only, so check for BEHIND yourself before you call the PR ready. If an overlapping PR makes this one obsolete, stop monitoring, report it to the user, and ask before closing the PR unless closure was explicitly authorized.
If nothing has changed, stay quiet rather than posting filler comments. Stop when 
pr-wait
exits 0, or in T3 Code when the merge gate passes on the latest head. Merge only when the user explicitly requested it; otherwise report that the PR is ready. Right before a merge, run 
git fetch
and check the PR again. Never merge when it is BEHIND or DIRTY, or when base commits that landed after the last green run touch this PR's files. Rebase, push, and wait for green again.
持续关注对 
main
的改动，并在必要时进行 rebase。
pr-wait
会报告新的 base commit 是否触及该 PR 的文件，以及 PR 是否变为 BEHIND 或 DIRTY。
watch_pull_request
只报告冲突，因此在将 PR 判定为 ready 前，请自行检查其是否为 BEHIND。
如果另一个重叠的 PR 使当前 PR 失去必要性，请停止监控，向用户报告，并在关闭 PR 前征求同意，除非已明确授权关闭。
如果没有变化，请保持安静，不要发布填充性评论。当 
pr-wait
退出码为 0 时停止监控；在 T3 Code 中，则在最新 head 通过 merge gate 后停止。只有用户明确要求时才能合并；否则应报告 PR 已 ready。合并前，应先运行 
git fetch
并再次检查 PR。当 PR 为 BEHIND 或 DIRTY 时，绝不要合并；如果最后一次 green 运行之后落地的 base commit 触及了该 PR 的文件，也绝不要合并。此时应执行 rebase、push，然后等待再次变为 green。