用途
melech-babysit 用于在 PR 合并前持续照看它，避免用户每隔几十秒手动检查一次。PR 在迭代之间会发生变化：队友评论、base 分支前进、CI 重新运行、评审机器人（Bugbot、CodeRabbit 等）发布新发现。一次性检查几分钟内就会过时。该技能的目标是让 PR 在反复的节奏中保持“可合并”状态，直到它合并、用户停止，或确实需要用户介入。
主要能力
- 按默认 5 分钟节奏循环，也接受覆盖，例如
melech-babysit every 10m或melech-babysit 2m。 - 每次迭代按顺序执行：刷新状态、解决合并冲突、处理未解决评论、修复 CI 失败、推送范围受限的修复。
- 刷新状态：
git fetch、拉取 PR 分支、检查 base 是否前进；不信任比上一次 tick 更旧的缓存 PR 数据。 - 合并冲突：智能解决，保留双方意图；若意图真正冲突，中止合并并向用户展示具体 hunk，不猜测。
- 评论：只获取未解决的评审线程；只读评论正文和采取行动所需的最小位置；改代码前先验证，因为评审机器人经常在意图上出错；若不同意，回复理由而不是静默忽略；绝不批量解决线程。
- CI：只修复由本 PR diff 导致的失败；绝不为让检查变绿而编辑工作流 YAML 或无关代码；若阻塞性检查看起来无关，先尝试合并最新 base（可能已被其他 PR 修复）；若仍红且超出范围，停止并报告。
- 推送范围受限的修复，让下一次 tick 验证。
使用方式
先武装循环，再做其他事。如果用户环境中有 /loop 原语，调用它：/loop 5m melech-babysit <PR ref>。否则用唯一哨兵和受监控输出武装后台心跳，然后立即运行一次迭代。一次迭代不算 babysitting；如果无法循环，应说明并停止，不要假装单次通过就足够。
适用场景
适用于用户已打开 PR、希望无需频繁手动干预即可推进合并的场景，尤其是需要持续应对评审评论、base 分支前进、CI 重跑和评审机器人新发现的 PR。
限制
- 无法循环时应停止，不应假装单次检查足够。
- 遇到需要产品/设计/安全决策的问题，应停止循环并带着明确问题交还用户。
- 同一失败连续 3 次 tick 无进展时，应停止并报告。
- 停止时始终杀死循环进程；静默存活的心跳比没有 babysit 更糟。
- 不得静默将评审机器人的请求标记为“已解决”。
- 不得编辑
.github/workflows/*.yml来跳过失败检查。 - 不得持续循环于明显无法修复的失败。
迭代间报告
保持 tick 报告简短。每次唤醒时说明变化（新评论、CI 差异、base 新提交）和所做操作，不要重印整个 PR 状态。