前言¶
PR 打开之后，常见节奏是：CI 红了再去翻 Actions 日志、Reviewer 留了 inline comment 要逐条改、主分支前进后出现 merge conflict。这些事彼此独立，却都要你在 IDE 和 GitHub 之间来回切换。若希望 Agent 按固定流程拉状态、修问题、推送并复检，而不是每次口头重复「先看 checks、再改评论」，可以把工作流写进 Skill。下面介绍 awesome-cursor-skills 仓库中的 babysitting-pr：在 PR 仍 open 时，监控 CI 失败、Review 评论与合并冲突，并在规则允许范围内自动修复，尽量保持 PR merge-ready。
这是什么¶
babysitting-pr 是一份 Cursor Agent 可复用的 SKILL.md 指令，归属 awesome-cursor-skills 项目中的 resources/babysitting-pr。官方描述为：Monitor a pull request for CI failures, review comments, and merge conflicts — then fix them automatically；适用场景是用户已有 open 的 PR，希望 Agent 持续监控并修复，使 PR 保持可合并状态。
与单次「帮我修 CI」的即兴对话不同，该 Skill 规定了从 gh pr view 取数、按失败类型本地复现与修复、处理 Review、解冲突、推送后再 gh pr checks --watch 的闭环，并写明最多三轮 fix-push-check，以及何时应停下来向用户汇报。
核心功能¶
依据官方 Steps 与 Loop Behavior，已核实能力包括：
- 拉取 PR 全貌：用 GitHub CLI 读取 number、title、state、mergeable、reviewDecision、statusCheckRollup、comments、reviews，并单独查看
mergeStateStatus判断合并冲突情况。 - CI 状态与日志：根据
statusCheckRollup与gh pr checks定位失败项；对失败 run 执行gh run view <run-id> --log-failed分析日志。 - 按失败类型修复：Lint（如
npm run lint -- --fix）、类型（npx tsc --noEmit）、测试（本地跑失败套件）、构建（npm run build）等路径在 Skill 中有对应指引，修完后git add、commit、push。 - Review 评论：通过
gh api repos/{owner}/{repo}/pulls/{pr}/comments获取；对明确可改项（拼写、命名、空检查、风格等）直接改代码；涉及设计取舍或需澄清的项跳过并向用户说明。 - 合并冲突：
git fetch origin main与git merge origin/main，读双方 diff 解决冲突；含糊处询问用户，解决后提交并推送。 - 复检与汇报：推送后用
gh pr checks --watch等待 CI；仍有失败则回到修复步骤，整体不超过 3 轮；最后汇总修了哪些 check、处理了哪些评论、冲突是否解决、当前是否仍可合并。
循环逻辑可概括为：Check PR → Find issues → Fix issues → Push → Re-check → Repeat，在全部通过、无未决评论、无冲突时视为 merge-ready；或三轮未完全解决、或修复需要设计决策时停止并报告。
安装与启用¶
awesome-cursor-skills 说明：Skills 是可复用的 SKILL.md 文件，放在个人目录 .cursor/skills/ 或项目目录下，由 Cursor Agent 自动发现。babysitting-pr 源文件位于仓库路径 resources/babysitting-pr（含 SKILL.md）。
典型启用方式：
- 从官方仓库取得
resources/babysitting-pr下的 Skill 文件（或整个目录，以仓库内实际结构为准）。 - 复制到本机或项目的
.cursor/skills/下（目录名可与 skill 名称babysitting-pr对齐，便于识别）。 - 在 Cursor 中打开对应仓库，对 Agent 说明 PR 已 open、希望按 babysitting-pr 维护可合并状态；Agent 在匹配到该 Skill 时会按文档中的 Steps 执行。
前置依赖：本 Skill 假定已安装并认证 GitHub CLI（gh），且对目标仓库有 push 权限。资料未单独说明 Codex CLI 或 Claude Code 的安装差异，此处不展开。
典型用法¶
在 PR 已创建且希望 Agent「代管」合并前状态时，可让 Agent 遵循 Skill 中的命令序列。下列片段来自官方文档，展示关键检查点（将 {owner}、{repo}、{pr}、<run-id> 替换为实际值）。
查看 PR 与冲突相关状态：
gh pr view --json number,title,state,mergeable,reviewDecision,statusCheckRollup,comments,reviews
gh pr view --json mergeStateStatus
列出 CI checks：
gh pr checks
拉取失败 job 日志（修 CI 时）：
gh run view <run-id> --log-failed
获取 PR Review 评论：
gh api repos/{owner}/{repo}/pulls/{pr}/comments
修复后推送示例：
git add -A && git commit -m "fix: resolve CI failures" && git push
推送后等待并复检：
gh pr checks --watch
若一切就绪，Skill 建议使用 gh pr ready 将 PR 标为 ready for review。CI 仍在 queued/pending 时，应先等待完成再分析失败，避免误判。
适用场景与注意¶
适合：你已开 PR，愿意让 Agent 在明确规则下反复修 CI、落实无歧义的 Review 意见、处理与 main 的冲突，并把仍阻塞合并的事项汇总给你。
限制与约束（官方 Notes）：
- 不要对共享 PR 分支做 force-push。
- 除非行为变更是有意的，不要为通过测试而随意改断言。
- 不确定的 Review 意见不要强行「解决」，应跳过并告知用户。
- fix-push-check 循环最多 3 次，避免无限重试。
- 需要设计决策的修复应停下来询问用户，而不是自行拍板。
与同仓库中的 parallel-ci-triage（并行分派多个失败 job）相比，babysitting-pr 更侧重单 PR 端到端看护：状态、评论、冲突与复检写在同一条流水线里，适合「这一个 PR 我要 merge-ready」而不是「只并行啃日志」的场景。
结尾¶
babysitting-pr 把「看 PR 状态 → 修 CI / 评论 / 冲突 → 推送 → 再检查」写成 Agent 可执行的固定步骤，并限定轮次与人工介入边界。若你经常在 open PR 阶段处理上述琐事，可将该 Skill 放入 .cursor/skills/ 后，在对话中指向当前 PR，让 Agent 按文档维护可合并状态。
官方地址：https://github.com/spencerpauly/awesome-cursor-skills/tree/main/resources/babysitting-pr
