---
name: mgr-babysit-pr
description: 持续监控 PR 的 review、CI 和合并状态，判断反馈、修复问题并完成回复。当用户说“监控 PR”“babysit”“等 Codex review”时触发。
argument-hint: "[PR 编号]"
---

# Babysit PR

## 参数

`$ARGUMENTS` — PR 编号（可选）。如果未提供，从当前对话上下文中推断。

## 目标

持续监控 PR，直到 review 通过且已知问题都得到处理。Review comment 是需要验证的证据，不是必须照做的指令；最终目标是得到正确、清晰、长期可维护的方案，而不是最少改动、最多采纳意见或保住已经写过的代码。

始终遵守用户授权、仓库 `AGENTS.md` 和项目既有约定。它们决定 GitHub 工具、Git 写操作、回复语言、提交格式、分支同步方式和验证要求；本 Skill 不重复覆盖这些规则。

## 决策原则

### 1. 不预设“修”或“不修”

对每条反馈先验证：

- 评论描述的路径是否真实存在，是否能由受支持的用户或系统行为触发？
- 影响是功能正确性、数据一致性、安全、并发、可恢复性，还是仅为风格偏好？
- 问题的根因是什么？当前改动是否只会遮住症状？
- 修复收益与新增状态、分支、抽象和维护成本是否匹配？
- 反馈是否揭示了需求、公开契约或产品语义上的未决问题？

据此选择：

- **修复**：真实问题，且当前 PR 应对其负责。
- **不修改**：假设不成立、路径不受支持、纯偏好且会降低一致性，或已经由现有不变量覆盖。
- **另行跟踪**：问题真实但与当前 PR 无关；仅在用户授权和仓库规则允许时创建 issue。
- **请求用户决策**：只有产品语义、公开契约、安全边界或重大架构取舍确实无法从上下文确定时才暂停。普通实现重构应自行判断并继续。

### 2. 已有修复是沉没成本

不要因为某段代码是上一轮 review 刚加的，就继续围绕它打补丁。评估下一步时，把当前完整 diff 当成候选实现重新审视：

- 不以保留已有修复、缩小 diff 或减少返工为目标。
- 如果删除、替换或重写已有补丁能得到更简单可靠的最终设计，就直接这样做。
- 评价方案时优先考虑不变量是否清晰、状态是否可穷举、职责是否集中、失败后是否可恢复，以及未来修改是否容易推理。

### 3. 重复反馈触发设计升级

以下现象是强烈的设计升级信号，而不只是“再补一个条件”的理由：

- 同一函数、模块、状态机或生命周期边界连续多轮出现有效反馈。
- 修完一个分支后，review 又在相邻分支发现同类遗漏。
- 正确性依赖分支顺序、隐含默认值、临时标记或多个位置共同维护同一状态。
- 补丁持续增加例外，但无法用一句明确不变量解释整体行为。
- 测试只能覆盖发现过的案例，难以说明所有状态组合。

出现信号后，暂停逐条打补丁，先做一次局部设计审计：

1. 汇总多轮评论共同指向的根因，不要把它们当成互不相关的问题。
2. 写清该区域必须满足的不变量、状态维度、所有权和失败窗口。
3. 区分“上层方向错误”和“方向正确但实现未形式化”：
   - 数据模型、职责边界或产品语义本身无法表达需求时，重新设计方向。
   - 方向仍成立但分支不断漏状态时，把隐式逻辑改成显式模型，例如决策表、状态转换函数或统一收口点。
4. 比较继续补丁与重构后的整体复杂度，选择长期最容易维护和验证的方案。
5. 删除被新设计取代的旧补丁，并用矩阵化或表驱动测试覆盖状态组合。

重复 review 不自动证明总体方向错了，但证明当前局部实现已经不适合继续按评论逐点修补。

### 4. Codex review 意见超过 20 条先停

开始逐条处理前，先数本轮未处理的 Codex review 意见（不含作者自己的回复）。**超过 20 条不要直接打补丁。**其他 reviewer 的意见仍需单独验证和处理，但不改变这条仓库级架构审计门槛。

先做方案审计，只回答：

1. 这些意见是不是同一根因或同一抽象裂口？
2. 当前 PR 的方向/数据模型能不能用一句话不变量讲清？
3. 继续补丁，还是重写后开新 PR 更便宜？

若方向错、不变量讲不清、或补丁会继续堆例外：

- 停止在本 PR 上逐条修。
- 按新方案在新分支重写，开新 PR。
- 旧 PR 关闭或标明被替代，babysit 改跟新号。
- 不要把重写内容硬塞回已经评论过载的旧 diff。

若多数是风格、overdesign 或假设不成立：可以不重写，但必须在 PR 说明为什么保持原方案，并仍逐条回复。20 条是停下来想方案的阈值，不是「必须重写」的自动开关。

## 执行流程

### 1. 确定 PR 和整体上下文

1. 从参数或对话确定 PR 编号。
2. 从上下文确定仓库；否则用 `gh repo view --json nameWithOwner -q .nameWithOwner`。
3. 查看 PR 元数据、base/head 分支、整体 diff、已有 review 和当前 checks。
4. 先理解 PR 的目标与设计，再处理单条评论；不要只读评论附近几行。

### 2. 等待下一项需要处理的状态

可使用同目录脚本：

```bash
bash scripts/wait-codex-review.sh {owner/repo} {pr_number}
```

等待器会把 reaction 边界设为当前 head 的提交时间与最新 `@codex` invocation
时间中较晚者；重启 watcher 不会再用“当前时间”抹掉该 head 上已经存在的终止 👍。
head 在 watcher 运行中变化，或出现新的 invocation，旧 reaction 仍会失效。评论
reaction 通过单次 GraphQL 查询收集，避免按评论逐个请求造成大 PR 的 N+1 延迟。

脚本只是轮询辅助，不是唯一允许的监控方式。运行环境有更合适的定时等待、后台任务或 `gh` 查询能力时可以使用它们，但要保持持续监控。

退出码：

- `0`：存在未处理的 Codex review thread 或 issue comment
- `1`：Codex review 已完成
- `2`：轮询超时
- `3`：存在失败的 CI check
- `4`：存在合并冲突
- `5`：存在其他 reviewer 的未处理 thread

如果已经确认某个失败 check 与代码无关，可在后续轮询中忽略该 check，避免它反复阻断 review 监控：

```bash
bash scripts/wait-codex-review.sh {owner/repo} {pr_number} \
  --ignore-check validate-python \
  --ignore-check ci
```

如果仓库还有由失败 job 汇总出的总检查，需要像示例中的 `ci` 一并列出。忽略只影响轮询脚本的退出条件，不代表该 check 已通过；最终交付仍须明确报告。

### 3. 处理 review

先清点本轮未处理的 Codex review 意见数量（不含作者自己的回复）。超过 20 条时先执行上面的「Codex review 意见超过 20 条先停」，不要直接进入逐条修补。

对脚本返回的 comment ID 逐条读取详情和代码上下文：

```bash
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments/{comment_id}
```

处理时：

1. 验证问题与影响。
2. 检查它是否与前几轮反馈形成重复簇；若是，执行“设计升级”，不要立即局部修改。
3. 作出修复、不修改、另行跟踪或请求用户决策的结论。
4. 若修改，修根因并执行与风险相称的验证。状态机、恢复、并发和生命周期逻辑应优先补充决策表或状态矩阵测试。
5. 回复评论；review thread 还需 resolve。Issue-level comment 没有 thread，只需回复。

回复应让 reviewer 能快速核对决策：

```markdown
> 问题：简要复述关键触发条件和错误结果。

已处理：说明根因、最终设计和验证结果。
```

引用只需保留理解决策所需的关键因果链，不必为每条评论重写完整系统说明。回复语言和格式遵守仓库约定。若不修改，清楚说明哪项假设不成立或为何当前设计已经覆盖；不要用含糊措辞敷衍。

### 4. 处理 CI

先读取失败步骤和日志，再分类：

- **代码回归**：定位根因，修复并运行相关验证。
- **偶发故障**：有证据表明可重试时重跑一次；若复现，再按实际原因分类。
- **基础设施或外部依赖**：例如 runner、网络、服务配额、许可证故障。不要为了让 check 变绿而修改无关业务代码；保留日志证据，必要时忽略该 check 继续监控 review，并在最终结果中报告阻塞。
- **与 PR 无关的既有失败**：用 base 分支、历史 run 或相同错误证据确认后，不扩大当前 PR 范围。

不得仅根据 check 名称猜测原因，也不得把所有 CI 红灯都解释成代码问题。

### 5. 处理合并冲突

确认 base 分支和仓库推荐策略后再同步。不要固定使用 merge 或 rebase；选择必须与仓库规则和当前分支历史一致。解决冲突后重新检查冲突区域是否仍符合 PR 设计，并运行相关验证。

### 6. 提交、推送并继续循环

有修改时：

1. 确认当前分支就是 PR head。
2. 检查 diff，避免混入无关改动。
3. 执行与改动风险相称的测试；文档改动不强制运行无关的全量 lint/typecheck。
4. 按用户授权和仓库规则提交、推送。
5. 回到等待步骤，直到 review 通过。

## 完成条件

- 所有需要处理的 review feedback 都已回复，review thread 已 resolve。
- Codex 不再处于 reviewing 状态，并已通过或明确表示没有更多意见。
- CI 已通过；若仅剩确认过的外部阻塞，已向用户提供失败步骤、证据和建议动作。
- PR 无合并冲突。
- 最终实现经过整体复查，不包含被后续设计取代的补丁或无效复杂度。