SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场babysit-pr

babysit-pr

编程与开发

查看项目

更新于 10-27 16:22

技能介绍

用途

babysit-pr 用于在代码审查和 CI 过程中持续监控一个拉取请求（PR）。当用户要求监控、观察或照看某个 PR 时使用该技能。

主要能力

该技能围绕 PR 监控提供一套操作规范，包括：

  • 使用监控器等待 PR 状态变化，而不是自行编写 watcher、轮询循环或 sleep 循环。
  • 处理已有的检查（checks）和评论。
  • 处理审查机器人（如 Greptile、Macroscope、CodeRabbit）的反馈。
  • 关注基分支（main）变化并在需要时 rebase。
  • 在合并前进行合并门禁检查。

使用方式

等待机制

技能明确要求：永远不要自己编写 watcher、轮询循环或 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。合并或关闭会自动结束监控。

“Stopped watching, could not read it”通常意味着 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 已审查 head，且没有未解决线程。用于照看 PR。
  • green：仅必需检查。当仓库没有 Greptile 或 Macroscope 时使用。
  • any-change：在第一个事件时退出。

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

在你 push 之后、处理完退出码 1 之后、以及 resume 之后，重新启动它。它会记住已经报告过的内容，因此期间到达的事件不会丢失。如果它提示另一个 pid 已在监控该 PR，不要启动第二个。只有当旧监控器的事件无法到达你时才杀掉它。

使用任一监控器时：当某个事件无需操作时，不发消息直接结束当前回合。永远不要发布或说“still waiting”。

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 读取检查。

审查

只对最新 push 之后的检查和评论采取行动。在修改代码前，对照源码验证每一个机器人发现。修复真实发现和 CI 失败，区分仓库失败与基础设施抖动，并在驳回误报时附上书面理由。

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

CodeRabbit 是建议性的。像对待其他发现一样对待它的发现，但永远不要等待它，也永远不要为它推迟合并。

如果审查机器人留下的反馈你认为不值得处理，附上书面理由回复并解决该评论。对代表用户发布的每一条评论，使用 leaving-pr-comments 技能。

当你有上传方式时，截图和视频也有帮助。

保持 PR 在用户目标所需的规模。审查循环往往会让 PR 一次一个看似廉价的修复而不断增长。修复预期场景中的真实 bug。其余用书面理由拒绝，并列为后续事项：不需要的测试、对不重要边界情况的防护、额外的集成或兼容性、以及小的性能开销。优先选择删除或收窄代码的修复。

基分支与合并

留意 main 的变化并在需要时 rebase。pr-wait 会在新的基分支提交触及本 PR 的文件时，以及当 PR 变为 BEHIND 或 DIRTY 时报告。watch_pull_request 只报告冲突，因此在宣布 PR 就绪前需自行检查 BEHIND。

如果某个重叠的 PR 使本 PR 过时，停止监控，向用户报告，并在关闭 PR 前询问，除非关闭已被明确授权。

如果没有任何变化，保持安静，而不是发布填充性评论。当 pr-wait 退出码为 0 时停止，或在 T3 Code 中当最新 head 通过合并门禁时停止。仅当用户明确要求时才合并；否则报告 PR 已就绪。合并前，运行 git fetch 并再次检查 PR。当 PR 为 BEHIND 或 DIRTY，或在最后一次绿色运行之后落地的基分支提交触及本 PR 的文件时，永远不要合并。Rebase、push，并再次等待绿色。

适用场景

  • 用户要求监控、观察或照看某个 PR。
  • 需要持续跟进 PR 的 CI 检查、审查评论和分支冲突状态。
  • 需要处理 AI 审查机器人（Greptile、Macroscope、CodeRabbit）的反馈。

限制

  • 每个 PR 只能使用一个监控器，不能同时运行 watch_pull_request 和 pr-wait。
  • 只有拥有 PR 的线程可以监控，被委派的子任务不得调用 watch_pull_request。
  • 受 GitHub 速率限制影响，GraphQL 用尽时需改用 REST 接口。
  • 仅当用户明确要求时才合并 PR。
  • 关于收费、价格、平台支持范围等具体信息，资料中暂未提供。