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