# Pr Babysit

> PR 提出後に CI を通すとき。「CI 見といて」「checks が落ちてたら直して」「PR を green にして」等で使う。PR の checks を監視し、失敗したらログから原因を特定してローカルで修正・push し、green になるまで繰り返す。create-pr の後段。

- Skill: `turntuptechnologies-ai/pr-babysit` (Agent Skill)
- Install (CLI): `npx skillmds@latest add turntuptechnologies-ai/pr-babysit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/turntuptechnologies-ai/pr-babysit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: turntuptechnologies-ai (https://skillmd.com/u/turntuptechnologies-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/turntuptechnologies-ai/pr-babysit

---


# PR CI 監視・修正（pr-babysit）

## このスキルがやること

提出済み PR の CI checks を green にするまで面倒を見る。失敗のたびにログを読み、根本原因を直して push する。基準を下げて通すことはしない。

## 手順

1. **対象 PR を特定する**: 引数の PR 番号、なければ現在ブランチの PR（`gh pr view --json number,url,headRefName`）。PR が無ければその旨を報告して終了する。
2. `gh pr checks <N> --watch` で checks の完了を待つ（watch が使えない環境では 1〜2 分間隔のポーリング）。
3. **全て pass** → 報告フォーマットで報告して終了。
4. **失敗がある** → `gh run view <run-id> --log-failed` でログを取得し、失敗の種類を判定する:
   - **自分の変更に起因** → ローカルで再現（pre-pr-checks を併用）→ 根本原因を修正 → Conventional Commits 形式で commit → PR ブランチへ push → 手順 2 に戻る
   - **変更と無関係の可能性（flaky・インフラ起因）** → `gh run rerun <run-id> --failed` で再実行。再実行で通ったら flaky として**テスト名と共に報告に明記**する。再実行でも落ちたら無関係と断定せず、自分の変更起因として再調査する
   - **判定不能** → ログの該当部分を提示してユーザーに確認する
5. **同一の失敗に対する修正が 3 回連続で失敗したら停止**し、試したこと・残っている失敗・次の仮説を報告する（無限ループ防止）。

## 報告フォーマット

必ずこの表で報告する:

```markdown
| check | 結果 | 対応 |
|---|---|---|
| test (ubuntu) | ✅ pass | `fix: 環境変数未設定時のテスト失敗を修正` で修正 |
| test (macos) | ✅ pass（再実行 1 回） | flaky: `test_timeout_retry`。変更とは無関係 |
| lint | ✅ pass | 初回から pass |
```

fail が残った状態で停止した場合は、表の下に「試したこと」「残る失敗のログ抜粋」「次の仮説」を書く。

## ルール・コツ

- **チェックを通すために基準を下げない**: テストの skip 化・アサーションの削除/緩和・lint ルールの無効化・リトライやタイムアウトを増やすだけの対処をしない。それが本当に必要だと判断した場合は、理由を添えてユーザーに確認してから行う。
- CI 設定ファイル（`.github/workflows` 等）は原則触らない。CI 設定自体のバグが原因と判断した場合は、根拠を報告してから最小の修正をする。
- 修正は必ず PR のブランチに push する（main へ直接 push しない）。
- ローカルで再現できない失敗（OS 差・CI 固有環境）は、ログの証拠に基づいて修正し、push 後の CI 結果で検証する。当てずっぽうの修正を連投しない。
- 監視が長時間になる場合は、待ち時間と確認間隔をユーザーに伝える。

## 完了条件

以下を全て満たしたら完了。**満たせない項目があれば、黙って省略せず理由を報告する。**

- [ ] 全 checks の最終状態（pass / fail）を報告フォーマットの表で報告した
- [ ] 失敗した check ごとに「原因」と「対応」を報告した（flaky 再実行はテスト名も明記）
- [ ] テスト skip・アサーション緩和・lint 無効化等の基準引き下げをしていない（した場合はユーザーの事前了承がある）
- [ ] 3 回ルールで停止した場合、試したこと・残る失敗・次の仮説を報告した

## 補足

- 社名・内部 URL・認証情報などの固有情報は扱わない。
- `gh` の認証が無い場合は `gh auth status` を確認し、ユーザーに案内する。