babysit

跟进 PR

在 Codex 中，使用此技能前请先阅读平台映射，包括其中针对各技能的说明。

在 GitHub Copilot 中，使用此技能前请先阅读平台映射，包括其中针对各技能的说明。

在 Muse 中，使用此技能前请先阅读平台映射，包括其中针对各技能的说明。

这是 Claude Code 对应于 Cursor 内置 /babysit 的功能。实现方式是循环调用 gh CLI，并使用 Claude Code 的 loop 技能控制节奏。

在 poteto-mode 中，Babysit 操作手册优先于此技能：它负责模式声明、合并边界、堆栈安全以及 watch-pr 监视器。此技能仍作为 poteto-mode 运行之外针对单个 PR 的独立 /babysit 入口。

使用时机

• 有一个已打开的 PR，且用户明确要求保持其检查通过，同时当前不在 poteto-mode 运行中（此情形由操作手册负责）。
• 用户直接调用 /babysit。
• 打开 PR 的子 Agent 不负责跟进 PR——应返回父 Agent，由父 Agent 决定。

步骤

1. 获取 PR 状态。

   gh pr view <number> --json number,title,state,mergeable,reviewDecision,statusCheckRollup,mergeStateStatus,comments,reviews
   

2. 按优先级进行分类处理。

   • 合并冲突（mergeStateStatus == DIRTY）：运行 fix-merge-conflicts 技能。仅当分支属于你且未共享时才强制推送。
   • 检查失败（statusCheckRollup 中 conclusion: FAILURE 的条目）：运行 fix-ci 技能。找出失败根因；修复底层代码或测试；提交并推送。
   • 审查评论：先运行 get-pr-comments 技能获取摘要，然后只处理你确实认同的反馈。如果评论只有一个机械性的处理方式——例如重命名、添加守卫子句或修正格式——就进行修改，并在提交消息中引用该评论。如果涉及判断，或你无法确定对方的要求，不要猜测：暂不处理，并回复说明你原本会如何处理。
   • 审查机器人评论（Bugbot 及类似自动化工具）：按照 bugbot-triage.md 的说明，先判断是修复、忽略还是询问，再采取行动。对于安全、数据和高严重性问题，默认先询问。

3. 循环检查。 使用 Claude Code 的 loop 技能安排复查节奏。根据监视对象选择间隔：

   • CI 正在运行：轮询 gh pr checks --watch（该命令会阻塞直到检查完成，因此无需单独设置循环间隔）。
   • 等待审查者回复：每 20–30 分钟检查一次。
   • 当前无事要做，但想留意新评论：每小时检查一次。

4. 停止时机。

   • 构建通过、所有评论均已处理且分支可干净合并 → 标记为就绪。
   • 已完成三轮“修复 → 推送 → 复查”，但检查仍未全部通过 → 停止、总结尚未解决的问题，并交还控制权。
   • 下一步修复需要做出设计选择 → 暂停，并使用 AskUserQuestion 询问用户。

5. 报告。 总结已应用的修复、已处理的评论、暂缓处理的评论（并说明原因）以及当前 PR 状态。引用每个提交的 SHA。

硬性规则

• 不要改写其他人可能已拉取的分支历史。如果看起来需要变基或强制推送，必须先征得用户同意。
• 不要为了让测试通过而随意修改预期值。只有当行为确实发生变化，且断言固定的是旧行为时，才修改断言。
• 绝不跳过钩子（--no-verify）。
• 绝不通过将检查标记为非必需来绕过失败的检查。
• 只有在所有检查均通过且没有未解决的审查评论时，才能运行 gh pr ready。

交叉引用

• 打开 PR 并不会自动开始跟进；在 poteto-mode 中，Babysit 操作手册负责处理此请求，并且只有在用户提出要求时才会启动。
• 如果 diff 存在争议，应在打开 PR 前使用 interrogate；PR 打开后，由 babysit 接手。
• 对你在此处撰写的所有文本（PR 评论、提交消息、状态报告）使用 unslop。

来源

这是 Cursor /babysit 的 Claude Code 类似实现，而非移植版本——Cursor 的实现是闭源的。此技能由作者独立编写，拥有自己的文案和结构；其工作流参考了 Cursor 公开的 /babysit 行为。它与其他 PR 工具唯一的重合之处，是运行的 gh CLI 命令；这些命令是功能性调用，并非复制的文本。