pr-babysitter

PR ベビーシッター

• 対象： 1 件のオープンな PR を進行させます。コンフリクト、GitHub Actions／Buildkite／Vercel／Fly.io 全体の CI、受信したレビューコメント、マージ準備状況に対応し、その後、バックグラウンドモニターまたは単発の修正として、リポジトリのマージ後ウォッチでマージ後の状況を追跡します。
• 対象外： PR の作成や編集（pr-creator）、差分自体のレビューや修正（tidy）、npm のリリース PR（autoship は独自のリリース CI を監視します。autoship が作成するリリース PR や Version Packages PR のベビーシッターは行いません）。

モードの選択

呼び出し	モード
"babysit", "watch this PR", "monitor", "keep it green"	モニター：フェーズ 1 を 1 回実行し、その後、イベントまたはティックごとにフェーズ 2～5 を実行します
"fix CI", "why is CI red", "loop on CI"	フェーズ 3 のループを 1 回実行
"resolve conflicts", "rebase onto main", "update the branch"	フェーズ 2 を 1 回実行
"address the comments", "reply to the reviewers", "triage review comments"	コメントのトリアージワークフローを 1 回実行
"is it ready", "what is blocking the merge"	フェーズ 5 のレポートを 1 回実行

すべてのモードに適用される常設ルール：

• コードの監視や修正だけでは、返信の投稿は許可されません。ユーザーがそのコミュニケーションを許可した場合に限り、返信の投稿、スレッドの解決、レビューのリクエストを行います。それ以外の場合は返信を準備して報告します。

• scripts/fetch-comments.sh は、インストール済みの SKILL.md を基準とした相対パスで解決します。以下の ${CLAUDE_SKILL_DIR} は Claude Code 用アダプターであり、汎用的な環境変数ではありません。

• セットアップに関する質問はしません。PR、CI プラットフォーム、デフォルト設定（2 分ごとのポーリング、ノイズの自動解決、自動マージなし）を自動検出して開始します。上書き設定はインラインで指定できます："poll every 5 minutes"、"enable auto-merge"。

• クローズ済みの PR はスキップします。ドラフト（isDraft）も、指定がない限りスキップします。マージ済みの PR はリポジトリのマージ後ウォッチに進みます。マージ SHA 上の watch/<env> コミットステータスを待ち、最初の failure または error で停止して結果を報告します（references/monitoring-setup.md の「マージ後ウォッチ」）。マージ先のベース（マージコミットの第 1 親、またはリベースマージの場合は PR のリベース済みコミットの直前のコミット）に watch/* ステータスがない場合は、「マージ後ウォッチなし」と報告します。いずれの場合も、マージが本番環境に反映されたら、そこで変更を読み取り専用でスモークテストし（同じリファレンスの「本番スモークテスト」）、その結果も報告して停止します。

• コメントのトリアージは自律的に実行されます。計画ファイルは監査証跡であり、承認ゲートではありません。

• 状態が変わった場合にのみ発言します。変化のないポーリングでは何も伝えません。

リファレンスファイル

ファイル	読み込むタイミング
references/monitoring-setup.md	フェーズ 1、マージ済みの PR、停止時：監視の手順、モニタースクリプト、cron の代替手段、マージ後ウォッチ、状態ファイル形式、デフォルト設定、停止とライフサイクル
references/merge-conflicts.md	フェーズ 2：mergeStateStatus テーブル、リベースワークフロー、ロックファイルと生成ファイルの解決、中止基準
references/ci-platforms.md	フェーズ 3：gh pr checks のフィールドと終了コード、プラットフォームごとのログおよび再試行コマンド、Buildkite の認証チェーン、失敗の分類
scripts/fetch-comments.sh	コメントのトリアージ：最初に ${CLAUDE_SKILL_DIR}/scripts/fetch-comments.sh {N} を実行します。すべてのレビュー、スレッド、issue コメントを含む 1 つの JSON ドキュメント。--help は出力形式を表示します
references/github-api.md	コメントのトリアージ：スクリプトの出力仕様、スレッドの集計、アンカーの優先順位、返信待ちルール、返信と解決
references/bot-patterns.md	コメントのトリアージ：レビュアーの検出、重大度のマッピング、マージゲート、ノイズマーカー、重複排除、誤検出
references/fix-plan-template.md	コメントのトリアージ：計画ファイルの形式と、許可される無視理由
references/verification-gate.md	コミットの前：lint、型チェック、テスト、knip、不要なアーティファクトの一掃
references/git-resilience.md	git コマンドがハングする場合、または一時的に失敗する場合（fsmonitor の行き詰まり、古い index.lock、ネットワークの瞬断）
evals/evals.json	このスキルを変更する場合のみ。PR の作業中には読み込みません

監視ループ

フェーズ 1 はフォアグラウンドで一度だけ実行され、監視を開始します。その後、イベントまたはティックごとにフェーズ 2～5 を実行し、状態ファイルとの差分を取り、変更があった場合にのみ通知します。

進捗を追跡するには、このチェックリストをコピーしてください。

PR babysit progress:
- [ ] Phase 1: Initialize (detect PR, pick watch mechanism, snapshot state)
- [ ] Phase 2: Conflict check
- [ ] Phase 3: CI check (diagnose, fix, gate, push)
- [ ] Phase 4: Comment check (triage new comments)
- [ ] Phase 5: Readiness check (report transitions, write state file)
- [ ] After merge: post-merge watch until watch/* passes, fails, or is absent, then a read-only production smoke test

フェーズ 1：初期化

1. gh pr view [N] --json number,url,title,state,isDraft,headRefName,baseRefName,headRefOid,mergeable,mergeStateStatus,reviewDecision を実行します。ブランチに PR がない場合は、その旨を伝えて停止します。
2. owner/repo が必要な呼び出しのために、gh repo view --json owner,name を実行します。
3. gh pr checks --json name,link から CI プラットフォームを検出します（パターンの一覧は references/ci-platforms.md を参照）。
4. 監視方法を選択します。references/monitoring-setup.md の監視手段の段階で、該当する最初のものを選びます（ハーネスによる PR サブスクリプション、Monitor ツール、cron、なし）。該当する手段がなければ、監視モードだと主張してはいけません。一致するワンショットモードを実行するか、このランタイムではポーリングを継続できないと伝えます。
5. 状態を .claude/pr-babysitter/babysit-pr-{N}.md に記録します。監視方法と ID、head SHA、マージ可能性、チェックの状態、未解決スレッド数と返信待ちスレッド数、レビュー判定を記録します。このフォルダーはステージングしません。
6. 次の 5 行で確認します。PR、監視方法と ID、検出した CI、現在の状態、有効なデフォルト設定。

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

gh pr view --json mergeable,mergeStateStatus を実行します。DIRTY は競合を解消します。BEHIND は更新します。UNKNOWN は GitHub がまだ計算中であることを意味するため、次のティックで再確認します。それ以外は次へ進みます。

git fetch origin {base} && git rebase origin/{base}
git push --force-with-lease --force-if-includes

• クリーンなリベース：プッシュして通知します。
• ロックファイル、生成ファイル、または変更履歴のみの競合：リファレンスに従って再生成し、リベースを続けてプッシュします。
• ソースロジック、マイグレーション、または API コントラクトの競合：git rebase --abort を実行し、競合したファイルと各側の変更内容を添えて通知します。これらは人間の判断に委ねます。

単独の --force は使用しません。リースが拒否された場合は、ほかの誰かがプッシュしています。コミットを上書きせず、中止して通知します。ブランチに複数の作者がいる場合、リベースによってその人たちのコミットが書き換えられます。その場合は、代わりに origin/{base} をマージします。

フェーズ 3：CI チェック

1. gh pr checks --json name,state,bucket,link,workflow を実行します。bucket は pass、fail、pending、skipping、または cancel です。link は詳細 URL です。
2. pending があれば待機します。実行が完了する前に診断すると、誤った箇所を修正してしまいます。
3. fail があれば、references/ci-platforms.md に記載されたプラットフォームごとのコマンドを使ってログを取得します（GitHub Actions、Buildkite の認証チェーン、Vercel、Fly.io）。
4. リファレンスに従って分類します。フレーキー（1 回だけ再実行）、古い依存関係（ソースを変更する前に再インストールして再ビルド）、コードエラー（修正）、knip（不要なコードを削除するか設定する）、インフラ（通知。コードでは修正できません）。
5. 修正し、検証ゲートを実行して、コミットし、プッシュします。前の状態からのリグレッション（以前は成功していたが、現在は失敗している）を明示します。

ワンショットループ（「CI を修正」）： プッシュのたびに gh pr checks --watch --fail-fast を実行します（終了コード 0 はすべて成功、1 はチェック失敗、8 はまだ実行中）。チェックが成功した場合、失敗がインフラ起因の場合、または修正後に同じチェックが同じエラーで 2 回失敗した場合は、停止して要約します。同じ失敗が 2 回続いたらプッシュを停止する合図です。3 回目の別案を試す合図ではありません。

フェーズ 4：コメントチェック

1. 未解決スレッド数と返信待ちスレッド数を数えます（最新のコメントが自分以外によるもの。解決状態は問わず、レビュー担当者自身が最後のコメントを解決した場合を除きます）。
2. 両方の件数と、レビューコメントおよび issue コメント全体の最新の updated_at を状態ファイルと比較します。その場で編集されたボットコメントと、解決済みスレッドへの返信の両方を検知する必要があります。
3. いずれかの件数が増えた場合は、コメントのトリアージワークフローを実行し、「PR #{N} に新しいレビューコメントが N 件あります」と通知します。ノイズではないコメントのみを数えます。新しいコメントがすべてノイズ（プッシュのたびに編集される固定の `` コメントなど）だったポーリングでは、通知しません。

フェーズ 5：準備状況の確認

1. 準備完了とは、次のすべてを満たす状態です。mergeable == MERGEABLE、必須チェックがすべて pass、head SHA の commit_id を持つレビューによる reviewDecision == APPROVED、未解決のブロッキングスレッドがゼロ、自分の返信待ちスレッドがゼロ、すべてのマージゲートを満たしていること。
2. 「Human review required」と書かれたマージゲートのコメントは、その条件を強制した基準とともに報告すべきブロッカーであり、修正する指摘ではありません。
3. 準備完了の場合は、「PR #{N} is ready to merge.」と通知します。マージは後戻りできない操作です。ユーザーがオプトインした場合に限り、リポジトリのマージ方法を使って gh pr merge --auto を実行します。
4. 準備未完了の場合は、ブロッカーを明示します（「Waiting on: 2 checks pending」「Awaiting your answer: 2 questions from @reviewer」「Approval is stale: reviewed abc1234, head def5678」）。
5. 次のティックに備えて状態ファイルを書き込みます。

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

フェーズ 4 からのインライン実行、または単独実行。自律的に進めます。承認ゲートはなく、計画ファイルが監査証跡になります。

取得

${CLAUDE_SKILL_DIR}/scripts/fetch-comments.sh {N} を実行します。すべてのスレッドと各スレッドのコメントをページングし、アンカーを復元し、スレッドを分類し、自分のログイン名に対する owedReply を算出します。ゼロ以外の終了コードの場合、理由を示す一文が stderr に出力されます。その原因を修正して再実行し、クエリを手書きしないでください。

分類する前に reviewers[] を確認します。発言したすべてのログイン名が、指摘、判定、または明示的な「no content」とともに出力に含まれている必要があります。レビューはあるのにコメントがゼロのレビュアーがいる場合、取得時に何かが失われています。anchor.source == "needs-translation" の場合は、指摘を判断する前に、作業ツリーに対してアンカーラダーを完了してください。

未解決のスレッド、自分の返信待ちスレッド、対応が必要なレビュー、対応が必要な Issue コメントがすべてゼロの場合に限り、早期終了できます。

分類

• すべての投稿者によるすべてのインラインコメントを読みます。ボットの表にない投稿者は不明であり、ノイズではありません。ノイズとするには、明確なマーカーとの一致が必要です。
• スレッドごとではなく、コメントごとに分類します。ボットのスレッド内にある人間の返信には、人間のコメントとしての重みを全面的に持たせます。
• 投稿者の種類は、まず内容から判断し、次にログイン名から判断します。github-actions[bot] はレビュアーとノイズの両方が共有しています。
• 重要度は情報源自身のマーカーに基づきます。不明な情報源はデフォルトで Major とします。重要度でキューの順序は決まりますが、コメントを読むかどうかは決まりません。
• 人間の意図は、修正依頼、質問、細かな指摘、または了承です。質問には回答し、コード変更は行いません。人間のコメントを自動的に無視してはいけません。レビュアーが任意と明記していない限り、修正します。
• マージゲートの判定はフェーズ 5 への入力です。記録しますが、修正、返信、解決はしません。
• ボットの指摘のみ重複排除します（同じパスで 3 行以内なら、重要度の最も高いものを残します）。複数箇所にまたがる指摘は 1 項目として扱います。
• 無視する場合はすべて、計画テンプレートに記載された正当な理由のいずれかを付けます。「投稿者を認識できない」「スレッドはすでに解決済み」は該当しません。

修正

1. 計画を (references/fix-plan-template.md) に従って .claude/pr-babysitter/pr-{N}-review-plan.md に書き込み、件数を表示して続行します。
2. 無視するスレッドには一行で返信してから、解決します。
3. 質問には回答を投稿し、スレッドは開いたままにします。解決するのはレビュアーです。
4. 未回答の人間の返信がある解決済みスレッドには、その場で返信します。スレッドを未解決に戻さず、レポートに記載します。
5. 修正は論理的なグループごとに 1 コミットとします。各コミットの前に検証ゲートを実行し、そのグループのファイルだけをステージします。
6. 修正した各スレッドには、返信してから解決します。
7. スクリプトを再実行し、未解決のスレッド、自分の返信がまだ必要なスレッド、回答済みだがまだ了承されていない質問、および現在の CI 状況を報告します。証拠となるのは再実行の結果です。「すべて対応しました」では不十分です。

停止

「Stop babysitting」または「cancel the monitor」の場合は、references/monitoring-setup.md（Stopping、Session Lifecycle）に従って状態ファイルに記録された仕組みを停止し、処理したポーリングまたはイベント、適用した修正、解決した競合、トリアージしたコメント、および現在の状態を報告します。

注意点

• isResolved == false でスレッドをフィルタリングする場合：GitHub は解決済みスレッドを折りたたむため、解決後に投稿された人間の返信が、最も未読になりやすいコメントです。
• comments(first: 20)：スレッドのコメントは古い順に届くため、ページが途中で切れると最新のコメント、つまり返信が必要かどうかを決めるコメントが隠れてしまいます。このスクリプトはすべてのスレッドを最後までページングします。
• viewerDidAuthor は、閲覧者自身のコメントでも false を返しました。author.login を gh api user --jq .login と比較してください。
• line が null の場合は、古いコメントまたは複数行のコメントであり、PR レベルではありません。PR レベルなのは path が null の場合だけです。判断する前にアンカーを特定してください。
• ボットのレビュー本文をトリアージする場合：本文は件数です。Codex、Devin、Copilot、Bugbot はすべて指摘をインラインに記載します。本文が空の人間のレビューが 4 件ある場合は、何も言うことがないレビュアーが 4 人いるのではなく、スレッド内に内容があるレビューが 1 回行われたということです。
• 1 つのコメントを編集して更新するボット（自動承認の評価や DangerJS など）は同じ id を使うため、ID の状態差分では変化を検出できません。updated_at を比較してください。
• commit_id が head SHA ではないレビューを承認として数える場合：ブランチ保護の「古い承認を取り消す」が次の push でその承認を無効にするため、それまでは PR が準備完了の状態に見えます。
• 修正後に git add -A を実行すると、フックの生成物（ルートの schema.gql）が PR にコミットされます。git status --porcelain で確認し、パスを指定してステージングしてください。
• 返信する前にスレッドを解決すると、レビュアーには何も言わずに解決したように見え、再度未解決にされます。
• サブスクリプションのみの監視では、競合を検出できません。ベースブランチが進んで競合が発生しても、GitHub は Webhook を送信しません。
• Monitor が利用可能な場合に Cron を使うと、静かな間隔ごとにエージェントが起動し、情報がないままトークンを消費します。2 分未満の間隔でポーリングしても、同様に GitHub のレート制限を消費します。

関連スキル

• pr-creator：PR を作成または編集します。見守りを始めるのは PR の作成後です
• planning：新しいセッションで実行する計画を作成します。このスキルが作成する修正計画は 1 つの PR の監査証跡であり、planning の成果物ではありません
• tidy：差分自体をレビューして修正します。このスキルは GitHub のレビューコメントを適用します。単純なパッチを超える、監視中に作成した修正には tidy を実行してください
• autoship：npm のリリースパイプラインです。独自のリリース CI を監視するため、このスキルが進めるリリース PR を見守らないでください