Babysit 是一个围绕 Pull Request（PR）维护流程设计的智能体技能。它的目标是：当用户打开一个 PR 后，能够在不频繁人工干预的情况下，持续将 PR 保持在“可合并”状态，直到它被合并、用户主动停止，或出现确实需要用户决策的情况。
用途与背景
用户提交 PR 后，往往希望它顺利合并，而不必每隔三十秒就手动查看一次。但两次检查之间，外部情况会不断变化：队友发表评论、目标分支前进、CI 重新运行、评审机器人（如 Bugbot、CodeRabbit 等）发布新的发现问题。一次性的检查在几分钟内就会过时。因此这个技能的职责，是以循环的节奏持续把 PR 保持在可合并状态。
循环机制
默认循环节奏为每 5 分钟一次，也接受覆盖设置，例如“babysit every 10m”或“babysit 2m”。在开始任何操作之前，需要先启动循环：如果用户的配置中存在 /loop 原语，则调用 /loop 5m babysit <PR ref>；否则使用唯一哨兵值和受监控的输出设置后台心跳，然后立即执行一次迭代。技能明确指出：只做一次迭代不算 babysitting；如果无法循环，应当说明并停止，而不是假装单次执行已经足够。
每次迭代的步骤
按顺序执行以下步骤，只有上一步产生硬性阻塞时才跳过某一步。
-
刷新状态：执行 git fetch、拉取 PR 分支、检查目标分支是否前进。绝不信任比上一次 tick 更旧的 PR 缓存数据。
-
合并冲突：以智能方式解决冲突，保留双方意图。如果意图真正冲突，则中止合并并向用户呈现具体的冲突片段，而不是猜测。
-
评论：只获取未解决的评审线程。对每条评论，只读取评论正文和采取行动所需的最小上下文。修改代码前先验证，因为评审机器人常常对意图判断错误。如果不同意，回复理由，而不是静默忽略。绝不批量标记线程为已解决。
-
CI：只修复由本 PR 差异导致的失败。绝不为了通过检查而编辑工作流 YAML 或无关代码。如果某个阻塞合并的检查看起来无关，先尝试合并最新的目标分支，因为可能是另一个 PR 修复了它。如果仍然失败且超出范围，则停止并报告。
-
推送有范围的修复，让下一个 tick 验证。
何时自行停止
以下情况应自行停止：PR 可合并、CI 变绿、无未解决线程时，宣布就绪并停止循环；某一步需要只有用户才能做出的产品、设计或安全决策时，停止循环并带着明确问题交还给用户；同一失败在连续 3 个 tick 中重复出现且没有进展时，停止并报告，因为此时只是在空转。停止时始终要终止循环进程，因为一个悄悄存活的心跳比没有 babysit 更糟。
两次 tick 之间的报告
保持 tick 报告简短。每次唤醒时，说明发生了什么变化（新评论、CI 变化、目标分支上的新提交）以及做了什么，不要重新打印整个 PR 状态。
该做与不该做
该做：如“Tick 3——CI 现在变绿，还剩一个 Bugbot 线程。它要求空值检查；代码已在第 42 行处理了该情况。已在线程中回复，未改动代码。”
不该做：因为评审机器人的请求不方便就静默标记为“已解决”。
该做：如“目标分支前进了 4 个提交，其中一个修复了不稳定的 api-integration 任务。已将目标分支合并进当前分支，检查重新运行中。”
不该做：编辑 .github/workflows/*.yml 以跳过失败的检查。
该做：如“连续两个 tick，db-migration 任务都因相同的超时失败。这不是我能从这里修复的代码问题。停止循环——你能检查迁移或调高超时吗？”
不该做：对一个明显无法修复的失败持续循环。