babysit-pr

PR 代管助手

自主 PR 监控器。从当前分支检测 PR，并每 2 分钟开始轮询。无需回答设置问题——自动检测所有内容并采用合理的默认值。

范围

• 持续检查 PR 状况：合并冲突、CI 检查、评审评论、合并就绪状态
• 评论分类会在监控周期内自主运行——无需审批计划
• 跳过：已关闭或已合并的 PR，以及未明确要求处理的草稿 PR

参考文件

文件	读取时机
references/github-api.md	默认：用于获取、回复和解决讨论串的 GraphQL 查询
references/bot-patterns.md	评论分类：机器人检测、严重程度解析、去重、误报规则
references/fix-plan-template.md	评论分类：生成修复计划文档
references/monitoring-setup.md	默认：CronCreate 配置、状态文件、默认值
references/ci-platforms.md	CI/CD 检查：GitHub 使用 gh，Buildkite 身份验证回退链，使用 vercel/flyctl 查看平台日志
references/merge-conflicts.md	冲突检查：检测并解决合并冲突

---

监控工作流

复制此清单以跟踪进度：

PR babysit progress:
- [ ] Phase 1: Initialize — auto-detect PR, snapshot state, start cron
- [ ] Phase 2: Conflict check — detect and resolve merge conflicts
- [ ] Phase 3: CI/CD check — poll checks, diagnose failures, fix and push
- [ ] Phase 4: Comment check — detect new comments, triage autonomously
- [ ] Phase 5: Readiness check — evaluate merge readiness, notify user

阶段 1：初始化

加载 references/monitoring-setup.md，了解 CronCreate 配置和默认值。

1. 自动检测 PR — 在当前分支上运行 gh pr view --json number,url,title,headRefName,baseRefName,mergeable,mergeStateStatus,reviewDecision。如果未找到 PR，告知用户并停止。如果传入了 PR 编号参数，则直接使用该编号
2. 提取所有者/仓库 — gh repo view --json owner,name
3. 记录当前状态快照 — 写入 .claude/scratchpad/babysit-pr-{N}.md：当前 HEAD SHA、可合并状态、检查状态、未解决的讨论串数量、评审决定
4. 检测 CI 平台 — 扫描 gh pr checks 中的检查名称，识别正在使用的平台（GitHub Actions、Buildkite、Vercel、Fly.io）
5. 创建定时任务 — 使用 */2 * * * * 计划运行第 2–5 阶段的 CronCreate。打印一条确认信息：

Monitoring PR #{N}: {title}
Polling every 2 minutes | Auto-resolve noise: yes | Auto-merge: no
Detected CI: {platforms}
Current state: {mergeable} | {reviewDecision} | {check_summary}

阶段 2：冲突检查

加载 references/merge-conflicts.md，了解解决策略。

1. 检查可合并状态 — gh pr view --json mergeable,mergeStateStatus
   • MERGEABLE → 跳到阶段 3
   • CONFLICTING → 继续解决冲突
   • UNKNOWN → 等待，在下一轮重新检查
2. 尝试变基 — git fetch origin {base_branch} && git rebase origin/{base_branch}
   • 变基成功且无冲突 → git push --force-with-lease → 通知用户
   • 安全文件（锁文件、生成的文件）存在冲突 → 自动解决并推送
   • 复杂冲突 → git rebase --abort → 向用户说明详情

切勿在未使用 --force-with-lease 的情况下强制推送。 如果租约检查失败，说明其他人已推送——中止操作并通知用户。

第 3 阶段：CI/CD 检查

加载 references/ci-platforms.md，查看特定平台的命令和 Buildkite 身份验证回退链。

1. 轮询检查状态 — gh pr checks --json name,state,conclusion,detailsUrl
2. 对每项检查分类 — 通过、待处理（等待）或失败
3. 如果全部通过 → 继续第 4 阶段
4. 如果有任何失败 → 诊断：
   • 根据检查名称识别平台（参见参考文档中的模式）
   • 获取日志：GitHub Actions 使用 gh run view --log-failed，Buildkite 使用身份验证回退链，Vercel 使用 vercel logs，Fly.io 使用 flyctl logs
   • 对失败分类：不稳定的测试（重新运行）、代码错误（修复并推送）、基础设施问题（通知用户）、依赖问题（更新 lockfile）
   • 如有可能，修复并推送
5. 与先前状态比较 — 标记回归（先前通过，现在失败）

第 4 阶段：评论检查

1. 统计未解决的讨论串 — 快速使用 GraphQL 计数或 gh pr view --json
2. 与状态文件比较 — 如果自上次轮询后出现新的未解决讨论串：
   • 通知用户：“PR #{N} 有 N 条新的审查评论”
   • 自主执行评论分类处理（获取 → 分类 → 修复 → 解决，无需计划审批）
3. 自动解决无关内容 — 以简短理由解决明确属于无关内容的机器人评论（vercel、linear、changeset）。绝不自动解决人工评论或关键／主要问题

第 5 阶段：就绪状态检查

1. 评估合并就绪状态 — 以下条件必须全部满足：
   • mergeable == MERGEABLE（无冲突）
   • 所有必需检查均已通过
   • reviewDecision == APPROVED
   • 没有未解决的阻塞讨论串
2. 如果已就绪 → 通知用户：“PR #{N} 已可合并。所有检查均已通过，审查已批准，没有冲突。”
3. 如果未就绪 → 报告阻塞项：“正在等待：2 项检查待处理”／“受阻于：合并冲突”
4. 仅在状态变化时通知 — 与上次轮询比较：
   • 检查转为通过 → “构建已通过”
   • 检查失败 → “构建失败：{check_name}”
   • 收到新的审查 → “来自 @{reviewer} 的新审查：{state}”
   • 检测到冲突 → “与 {base_branch} 存在合并冲突”
   • 全部就绪 → “PR #{N} 已通过所有检查，可以合并”
5. 更新状态文件，供下一轮轮询使用

评论分类处理工作流

第 4 阶段检测到新评论时，直接在此处执行，无需单独调用。

加载 references/github-api.md 获取查询模板，并加载 references/bot-patterns.md 获取检测规则。

获取

1. 获取所有审查讨论串 — 使用 GraphQL reviewThreads 查询并进行分页。筛选 isResolved == false
2. 获取 PR 审查 — REST 审查端点。收集所有审查的状态、正文和作者
3. 获取议题级评论 — 获取 PR 对话评论的 REST 端点
4. 提前退出 — 如果未解决的讨论串、可处理的审查和可处理的议题评论均为零，则跳过分类处理

分类

对每项内容：

1. 识别作者类型 — 人工或机器人。对于机器人，先按内容分类，再看用户名
2. 跳过无关内容 — 按 bot-patterns 参考文档自动将无关内容分类
3. 解析严重程度 — 根据特定机器人的格式提取。人工评论：CHANGES_REQUESTED 为主要问题，APPROVED + 提问为次要问题
4. 去重 — 将同一文件中 3 行范围内的行内评论归为一组。保留严重程度最高的一条
5. 分类 — 类别（错误／安全／性能／风格／正确性／文档／测试覆盖率）、严重程度（关键／主要／次要／吹毛求疵）、置信度（高／中／低）、处理方式（修复或说明原因后忽略）

绝不自动忽略人工评论。 始终将其分类为需要修复，除非问题显然已经解决，或审查者明确标记为可选。

修复

1. 编写计划文件到 .claude/scratchpad/pr-{N}-review-plan.md，作为审计记录
2. 报告摘要——打印数量（N 项待修复、K 项对话内容、M 项忽略项）并立即继续
3. 处理忽略的讨论串——发布简短回复，通过 GraphQL 将其标记为已解决
4. 修复实际问题——按提交组归类，并行修复互不相关的文件
5. 提交并推送——如果有 lint/test 可运行，则运行；每个逻辑修复组提交一次
6. 解决并回复——在已修复的讨论串中发布回复，通过 GraphQL 将其标记为已解决
7. 验证——重新获取讨论串，确认没有未解决项，并检查 CI 状态

停止监控

• “别再盯着了” / “取消 PR 监控” → 使用 CronDelete 移除任务
• 会话退出 → 任务会自动清理（按会话范围）
• PR 已合并或关闭 → 下次轮询时自动检测并自行取消

停止时，报告最终摘要：轮询总次数、已应用的修复、已解决的冲突、当前状态。

反模式

• 开始前询问设置问题——自动检测所有内容，使用默认值，立即开始
• 不带 --force-with-lease 强制推送——可能覆盖队友的提交
• 自动解决人工评论——绝不自动解决人工反馈
• 未发布回复就解决讨论串——审阅者需要了解处理理由
• 修复分类时标记为忽略的项目——遵循分类结果
• 每条评论单独提交一次——按提交组标签归类相关修复
• 未在本地确认 lint/test 通过就推送
• 检查仍在运行时重新诊断失败——等待检查完成
• 轮询间隔短于每 2 分钟一次——最短间隔为 2 分钟
• 状态未变化时每次轮询都发送通知——仅在状态转换时通知
• 未经用户明确选择就自动合并——合并是一项不可逆操作
• 一概将 github-actions[bot] 归类为噪声——它是 DangerJS、架构检查器和其他活跃工具共用的身份，应根据内容分类
• 未先检查身份验证就使用 bk CLI——通过 bk auth status 测试，并在必要时改用 REST API 或 gh pr checks

相关技能

• 推送修复前进行本地自查，请使用 review-pr