前言¶
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
