babysit-pr

PR ベビーシッター

自律型の PR モニターです。現在のブランチから PR を検出し、2 分ごとにポーリングを開始します。セットアップに関する質問はなく、すべてを自動検出して適切なデフォルトを適用します。

対象範囲

• PR の継続的な健全性確認：マージの競合、CI チェック、レビューコメント、マージ可能かどうか
• コメントのトリアージはモニターのサイクル内で自律的に実行され、計画の承認は不要です
• 対象外：クローズ済みまたはマージ済みの PR、明示的に依頼された場合を除くドラフト PR

参照ファイル

ファイル	読み込むタイミング
references/github-api.md	デフォルト：スレッドの取得、返信、解決に使用する GraphQL クエリ
references/bot-patterns.md	コメントのトリアージ：ボットの検出、重要度の解析、重複排除、誤検出のルール
references/fix-plan-template.md	コメントのトリアージ：修正計画ドキュメントの生成
references/monitoring-setup.md	デフォルト：CronCreate の設定、状態ファイル、デフォルト値
references/ci-platforms.md	CI/CD チェック：GitHub には gh、Buildkite 認証のフォールバック順、プラットフォームログには vercel／flyctl
references/merge-conflicts.md	競合チェック：マージの競合の検出と解決

---

モニターのワークフロー

進捗を記録するため、このチェックリストをコピーします。

PR babysit progress:
- [ ] Phase 1: Initialize — auto-detect PR, snapshot state, start cron
- [ ] Phase 2: Conflict check — detect and resolve merge conflicts
- [ ] Phase 3: CI/CD check — poll checks, diagnose failures, fix and push
- [ ] Phase 4: Comment check — detect new comments, triage autonomously
- [ ] Phase 5: Readiness check — evaluate merge readiness, notify user

フェーズ 1：初期化

CronCreate の設定とデフォルト値について、references/monitoring-setup.md を読み込みます。

1. PR を自動検出する — 現在のブランチで gh pr view --json number,url,title,headRefName,baseRefName,mergeable,mergeStateStatus,reviewDecision を実行します。PR が見つからない場合はユーザーに伝え、停止します。引数として PR 番号が渡された場合は、その番号を直接使用します
2. オーナーとリポジトリを取得する — gh repo view --json owner,name
3. 現在の状態を記録する — .claude/scratchpad/babysit-pr-{N}.md に、現在の HEAD SHA、マージ可能かどうか、チェックのステータス、未解決のスレッド数、レビュー判定を書き込みます
4. CI プラットフォームを検出する — gh pr checks からチェック名を調べ、有効なプラットフォーム（GitHub Actions、Buildkite、Vercel、Fly.io）を特定します
5. cron ジョブを作成する — */2 * * * * のスケジュールでフェーズ 2～5 を実行する CronCreate を設定します。確認メッセージを 1 件だけ表示します。

Monitoring PR #{N}: {title}
Polling every 2 minutes | Auto-resolve noise: yes | Auto-merge: no
Detected CI: {platforms}
Current state: {mergeable} | {reviewDecision} | {check_summary}

フェーズ 2：競合チェック

解決方法について、references/merge-conflicts.md を読み込みます。

1. マージ可能かどうかを確認する — gh pr view --json mergeable,mergeStateStatus
   • MERGEABLE → フェーズ 3 に進みます
   • CONFLICTING → 解決に進みます
   • UNKNOWN → 待機し、次のサイクルで再確認します
2. リベースを試みる — git fetch origin {base_branch} && git rebase origin/{base_branch}
   • 競合なくリベースできた場合 → git push --force-with-lease → ユーザーに通知します
   • 安全なファイル（ロックファイル、生成ファイル）での競合 → 自動的に解決してプッシュします
   • 複雑な競合 → git rebase --abort → 詳細を添えてユーザーに通知します

--force-with-lease を付けずに強制プッシュしてはいけません。 リースに失敗した場合は、他のユーザーがプッシュしています。中止して通知してください。

Phase 3：CI/CD チェック

プラットフォーム固有のコマンドと Buildkite の認証フォールバックチェーンについては、references/ci-platforms.md を読み込みます。

1. チェック状況をポーリングする — gh pr checks --json name,state,conclusion,detailsUrl
2. 各チェックを分類する — 成功、保留中（待機）、失敗
3. すべて成功している場合 → Phase 4 に進みます
4. 失敗しているものがある場合 → 原因を診断します。
   • チェック名からプラットフォームを特定します（パターンについてはリファレンスを参照）
   • gh run view --log-failed（GitHub Actions）、Buildkite の認証フォールバックチェーン（Buildkite）、vercel logs（Vercel）、flyctl logs（Fly.io）を使ってログを取得します
   • 失敗を分類します：不安定なテスト（再実行）、コードエラー（修正してプッシュ）、インフラストラクチャ（ユーザーに通知）、依存関係の問題（ロックファイルを更新）
   • 可能であれば修正してプッシュします
5. 以前の状態と比較する — リグレッション（以前は成功していたが、現在は失敗）にフラグを立てます

Phase 4：コメントの確認

1. 未解決スレッドの数を確認する — GraphQL による簡易カウントまたは gh pr view --json
2. 状態ファイルと比較する — 前回のポーリング以降に新しい未解決スレッドがある場合：
   • ユーザーに通知します：「PR #{N} に新しいレビューコメントが N 件あります」
   • コメントのトリアージを自律的に実行します（取得 → 分類 → 修正 → 解決。計画の承認は不要）
3. ノイズを自動解決する — 明らかにノイズであるボット（vercel、linear、changeset）は、簡潔な理由を添えて解決します。人間からのコメントや重大／主要な指摘は決して自動解決しません

Phase 5：マージ準備の確認

1. マージ可能かどうかを評価する — 以下のすべてを確認します。
   • mergeable == MERGEABLE（コンフリクトなし）
   • 必須のチェックがすべて成功している
   • reviewDecision == APPROVED
   • マージを妨げる未解決スレッドがない
2. 準備ができている場合 → ユーザーに通知します：「PR #{N} はマージ可能です。すべてのチェックが成功し、レビューも承認済みで、コンフリクトもありません。」
3. 準備ができていない場合 → ブロッカーを報告します：「待機中：保留中のチェックが 2 件あります」／「ブロック要因：マージコンフリクト」
4. 状態が変化した場合のみ通知する — 前回のポーリング結果と比較します。
   • チェックが成功した → 「ビルドが成功しました」
   • チェックが失敗した → 「ビルドが失敗しました：{check_name}」
   • 新しいレビュー → 「@{reviewer} から新しいレビューがありました：{state}」
   • コンフリクトを検出 → 「{base_branch} とのマージコンフリクトがあります」
   • すべて問題なし → 「PR #{N} はすべて成功しており、マージ可能です」
5. 次回のポーリングサイクルに備えて状態ファイルを更新します

コメントのトリアージワークフロー

Phase 4 で新しいコメントが検出されたら、別途呼び出すことなく、この処理をインラインで実行します。

クエリテンプレートについては references/github-api.md を、検出ルールについては references/bot-patterns.md を読み込みます。

取得

1. すべてのレビュースレッドを取得する — ページネーションを使った GraphQL reviewThreads クエリを実行します。isResolved == false で絞り込みます
2. PR レビューを取得する — REST のレビューエンドポイントを使います。状態、本文、作成者を含むすべてのレビューを収集します
3. Issue レベルのコメントを取得する — PR の会話コメント用 REST エンドポイントを使います
4. 早期終了 — 未解決スレッド、対応が必要なレビュー、対応が必要な Issue コメントがすべて 0 件の場合は、トリアージをスキップします

分類

各項目について、次の手順を実行します。

1. 作成者の種類を特定する — 人間またはボット。ボットの場合は、まず内容、次にユーザー名に基づいて分類します
2. ノイズを除外する — bot-patterns リファレンスに従って、ノイズ項目を自動分類します
3. 重大度を解析する — ボット固有の形式から抽出します。人間からのコメントは、CHANGES_REQUESTED の場合は「主要」、APPROVED と質問の組み合わせの場合は「軽微」とします
4. 重複を排除する — 同じファイルの 3 行以内の範囲にあるインラインコメントをまとめ、最も高い重大度のコメントを残します
5. 分類する — カテゴリ（バグ／セキュリティ／パフォーマンス／スタイル／正確性／ドキュメント／テストカバレッジ）、重大度（重大／主要／軽微／些細）、確度（高／中／低）、処置（修正、または理由を添えて無視）を判定します

人間からのコメントを自動的に無視することはありません。 すでに明らかに解決済みであるか、レビュー担当者が任意であると明示していない限り、必ず修正対象として分類します。

修正

1. 監査証跡として.claude/scratchpad/pr-{N}-review-plan.mdに計画ファイルを書き込む
2. 概要を報告 — 件数（修正対象N件、会話項目K件、無視する項目M件）を出力し、直ちに続行する
3. 無視するスレッドを解決する — 簡潔な返信を投稿し、GraphQL経由で解決する
4. 実際の問題を修正する — コミットグループごとにまとめ、独立したファイルの修正を並行して行う
5. コミットしてプッシュする — 利用可能であればlint/testを実行し、論理的な修正グループごとに1つのコミットを作成する
6. 解決して返信する — 修正したスレッドに返信を投稿し、GraphQL経由で解決する
7. 確認する — スレッドを再取得して未解決のスレッドが残っていないことを確認し、CIの状態を確認する

モニターの停止

• 「Stop babysitting」／「cancel the PR monitor」→ CronDeleteでジョブを削除する
• セッション終了 → ジョブは自動クリーンアップされる（セッション単位）
• PRがマージまたはクローズされた → 次回のポーリングで自動検出し、自動キャンセルする

停止時には、最終概要としてポーリング総数、適用した修正、解決した競合、現在の状態を報告する。

アンチパターン

• 開始前にセットアップについて質問する — すべてを自動検出し、デフォルトを使用して、直ちに開始する
• --force-with-leaseを使わずに強制プッシュする — チームメイトのコミットを上書きするリスクがある
• 人間のコメントを自動解決する — 人間からのフィードバックは絶対に自動解決しない
• 返信を投稿せずにスレッドを解決する — レビュー担当者が理由を確認できるようにする
• トリアージで無視と分類された項目を修正する — 分類を尊重する
• 個々のコメントごとに1つのコミットを作成する — 関連する修正はコミットグループのラベルごとにまとめる
• ローカルでlint/testの合格を確認する前にプッシュする
• チェックが実行中の間に失敗を再診断する — 完了を待つ
• 2分ごとより頻繁にポーリングする — 2分が最短間隔
• 状態に変化がないのにポーリングのたびに通知する — 状態が遷移したときだけ通知する
• ユーザーが明示的に許可していないのに自動マージする — マージは後戻りできない操作
• github-actions[bot]を常にノイズとして分類する — DangerJS、スキーマチェッカー、その他のアクティブなツールが共有するIDであるため、内容に基づいて分類する
• 認証を確認せずにbk CLIを使用する — bk auth statusでテストし、REST APIまたはgh pr checksにフォールバックする

関連スキル

• 修正をプッシュする前のローカルでのセルフレビューにはreview-prを使用する