babysit-pr

PR の見守り

PR（または Graphite スタック全体）を自律的に監視し、CI の失敗を修正し、レビューコメントに対応して、検証済みの修正をプッシュします。長時間実行セッションとして動作し、すべての PR の準備が整うか、ユーザーがセッションを停止するまで、適切な間隔で内部的にループします。

呼び出し

/babysit-pr

セッションループ

このスキルは連続したループで実行されます。

1. 現在のブランチが Graphite スタックの一部かどうかを検出します
2. スタック内のすべての PR の状態（CI とレビュー）を確認します
3. 影響を受けたブランチのうち最も下位のものから問題を修正します
4. すべての PR の準備が整った場合 → 成功を出力して終了します
5. それ以外の場合 → 適切な間隔だけスリープしてから、繰り返します

digraph babysit {
    node [shape=box];

    "Start session" [shape=doublecircle];
    "Detect Graphite stack\n(gt ls)";
    "Collect PRs for\nall stack branches";
    "Any PRs found?" [shape=diamond];
    "Exit: no PRs found" [shape=doubleoctagon];
    "For each PR\n(bottom of stack first):\ncheck CI + reviews";
    "Any issues found\nacross stack?" [shape=diamond];
    "For each branch (bottom-up):\nfix, verify, commit,\nrestack";
    "gt submit --stack\n(single push)";
    "All PRs: checks green +\ncomments addressed?" [shape=diamond];
    "Print: Stack is ready" [shape=doubleoctagon];
    "Print remaining issues\n+ sleep interval";
    "Sleep with\nintelligent interval";

    "Start session" -> "Detect Graphite stack\n(gt ls)";
    "Detect Graphite stack\n(gt ls)" -> "Collect PRs for\nall stack branches";
    "Collect PRs for\nall stack branches" -> "Any PRs found?";
    "Any PRs found?" -> "Exit: no PRs found" [label="no"];
    "Any PRs found?" -> "For each PR\n(bottom of stack first):\ncheck CI + reviews" [label="yes"];
    "For each PR\n(bottom of stack first):\ncheck CI + reviews" -> "Any issues found\nacross stack?";
    "Any issues found\nacross stack?" -> "All PRs: checks green +\ncomments addressed?" [label="no"];
    "Any issues found\nacross stack?" -> "For each branch (bottom-up):\nfix, verify, commit,\nrestack" [label="yes"];
    "For each branch (bottom-up):\nfix, verify, commit,\nrestack" -> "gt submit --stack\n(single push)";
    "gt submit --stack\n(single push)" -> "All PRs: checks green +\ncomments addressed?";
    "All PRs: checks green +\ncomments addressed?" -> "Print: Stack is ready" [label="yes"];
    "All PRs: checks green +\ncomments addressed?" -> "Print remaining issues\n+ sleep interval" [label="no"];
    "Print remaining issues\n+ sleep interval" -> "Sleep with\nintelligent interval";
    "Sleep with\nintelligent interval" -> "Detect Graphite stack\n(gt ls)" [label="loop"];
}

1. Graphite スタックを検出する

現在のブランチがスタックの一部かどうかを判定します。

gt ls

これにより、スタック全体の構造が表示されます。出力を解析し、下位（trunk に最も近いブランチ）から上位の順にブランチの一覧を取得します。

ブランチが単独で（スタックの一部ではなく）存在する場合は、1 つのブランチからなるスタックとして扱います。以降のフローは同じように動作します。

2. スタック全体の PR を収集する

スタック内の各ブランチ（下位から上位）について、PR を検索します。

gh pr view <branch> --json number,url,headRefOid

(branch, pr_number, headRefOid) のタプルの一覧を作成します。まだ PR がないブランチはスキップします。

どのブランチにも PR が存在しない場合は、エラーを出力して終了します。

3. すべての PR の CI とレビューを確認する

並行して状態を収集するには、サブエージェントを使用します。 PR ごとにサブエージェントを 1 つ起動し、CI の状態、レビューのスレッド、一般コメントを並行して取得します。各サブエージェントは、担当する PR についてステップ 3a〜3c の確認を実行し、問題の構造化された概要を返します。これにより、メインコンテキストを整理でき、スタック全体にわたる API 呼び出しの逐次実行を避けられます。

失敗したチェックを調査する場合も同様に、失敗した実行ごとにサブエージェントを起動し、ログ（gh run view <run-id> --log-failed）を取得して根本原因を分析します。CI ログは冗長なため、サブエージェントに分離することでコンテキストの汚染を防げます。

すべての問題をブランチごとにタグ付けして一覧に収集し、どのブランチを先に修正すべきか把握します。その後、ステップ 4 に従って下位から順に修正します。

3a. 必須の CI を確認する

gh pr checks <pr_number> --json name,state,bucket,link,required

• HEAD コミットに対するチェックだけを対象にします。headRefOid を使って確認してください。
• 失敗はすぐに修正します。すべてのチェックが終わるまで待たないでください。一部のチェックがまだ保留中でも、すでに失敗したチェックがあれば、すぐに修正します。プッシュするとすべてのチェックで新しい CI 実行が開始されるためです。
• 失敗したチェック（必須・任意を問わず）ごとに、次の手順を実行します。
  1. ログを取得します：gh run view <run-id> --log-failed
  2. 根本原因を調査します
  3. コードを修正します
• チェックが pending または in_progress の場合は、実行開始からの経過時間を記録し（gh run view <run-id> --json createdAt を使用）、スリープ間隔の判断に役立てます。
• 任意チェックの失敗は、可能な範囲で修正しますが、終了条件を妨げるものではありません。

3b. インラインのレビュースレッド

gh api graphql -f query='
  query($owner: String!, $repo: String!, $pr: Int!) {
    repository(owner: $owner, name: $repo) {
      pullRequest(number: $pr) {
        reviewThreads(first: 100) {
          nodes {
            id
            isResolved
            comments(first: 10) {
              nodes { body author { login } path line }
            }
          }
        }
      }
    }
  }
'

3c. 一般的なレビューコメント

これらはトップレベルのレビューコメントです。特定のファイルや行に結び付いていない、レビュー投稿の本文です。重要な全体的なフィードバック、アーキテクチャに関する懸念、概要の依頼などが含まれることがよくあります。

gh api repos/{owner}/{repo}/pulls/{pr}/reviews --jq '.[] | select(.body != "" and .body != null) | {id, body, state, user: .user.login}'

レビューの一部ではない、独立した PR コメント（会話タブのコメント）も取得します。

gh api repos/{owner}/{repo}/issues/{pr}/comments --jq '.[] | {id, body, user: .user.login}'

処理ルール

次のスレッド／コメントはスキップしてください。

• 解決済み（スレッドの場合）
• すでにベビーシッターが対応済み（最後の返信がボットからのもの、または 🤖 で始まる）

残りのスレッドまたはコメントをそれぞれ分類し、対応してください。

すべての返信は、AI による支援であることを示すため、必ず 🤖 で始めてください。

種類	判定の手がかり	対応
実際の問題	バグ、正確性の問題、考慮漏れのケース、セキュリティ上の懸念	コードを修正します。返信：「🤖 修正しました — [変更内容の説明]」。該当する場合はスレッドを解決します。
スコープの変更	機能リクエスト、スタイルの好み、動作の変更	返信：「🤖 これはこの PR のスコープ外です。[簡単な説明]」。未解決のままにします。
問題ではないもの	誤解、すでに対処済み、事実誤認	返信：「🤖 これが問題ではない理由の説明」。未解決のままにします。

一般的なレビューコメントには、適切な API を使って返信してください。

• レビューコメント：gh api repos/{owner}/{repo}/pulls/{pr}/reviews/{review_id}/comments またはレビューへの返信
• Issue コメント：gh api repos/{owner}/{repo}/issues/{pr}/comments -f body="..."

4. 問題を下位ブランチから修正する

スタック内の複数の PR で問題が見つかった場合は、必ず最下位のブランチから修正してください。下位ブランチでの修正により、スタックを再配置した後に上位ブランチの問題も解決する場合があります。

重要：1 回のループでプッシュするのは 1 回だけです。 すべての修正をローカルで適用してから、最後にスタック全体をプッシュしてください。

問題がある各ブランチについて、下位から上位の順に次の手順を実行します。

1. ブランチをチェックアウトします： gt checkout <branch>
2. そのブランチの CI 失敗とレビューコメントをすべて修正します（手順 3 のルールに従います）
3. 対象を絞ってローカル検証を実行します — 変更したファイルの lint と型チェックを実行し、変更したコードを対象とするテストだけを実行します（全テストスイートは実行しません）。対象を絞ったテストの実行方法（特定のテストファイル、ディレクトリ、フィルターパターンの指定など）は、プロジェクトの CLAUDE.md／AGENTS.md を確認してください。検証に失敗した場合は、問題を修正して合格するまで再検証します。
4. ローカルでコミットします： gt modify --commit
5. 上位ブランチに変更を反映するため、スタックを再配置します： gt restack
6. 問題がある次のブランチに進みます

すべてのブランチを修正したら、次の手順を実行します。

7. スタック全体を 1 回だけプッシュします：

   gt submit --stack
   

5. スリープ間隔のロジック

各反復の後、現在の状況に応じてスリープ時間を選択します。

状況	スリープ時間	理由
コードをプッシュした直後で、CI がまだ開始されていない	2 分	CI が新しいコミットを取り込む時間が必要です
一部のチェックが失敗した（すでに修正してプッシュ済み）一方で、ほかのチェックはまだ実行中	3 分	新しいプッシュによってすべてのチェックが再実行されるので、すぐに再確認します
すべてのチェックがまだ実行中で、開始から 5 分未満	3 分	チェックの開始直後なので、すぐに再確認します
すべてのチェックがまだ実行中で、開始から 5～15 分	5 分	チェックが完了するまで待ちます
すべてのチェックがまだ実行中で、開始から 15 分超	5 分	時間のかかるチェックを、一定間隔で引き続き確認します
すべての CI が成功し、レビュー担当者の対応待ち	10 分	人の応答には時間がかかります
対応事項はないが、PR の準備がまだ完全に整っていない	5 分	デフォルトの確認間隔です

スタックをベビーシッターする場合、すべての PR のうち最も緊急度の高い状況に基づいて間隔を決めます（つまり、該当する間隔のうち最も短いものを使用します）。

スリープする前に、選択した間隔と理由を出力してください：「Sleeping {N} minutes — {reason}」

待機にはシェルの sleep を使います（例：5 分なら sleep 300）。

6. 終了条件

スタック内のすべての PR は、次の条件を満たすと準備完了です。

• すべての PR で、HEAD に対する必須の CI チェックがすべて成功している
• すべての PR のレビュー スレッドが、解決済みであるか、最後のコメントとしてベビーシッターからの返信がある
• すべての PR の一般的なレビューコメントに対応済みである（ベビーシッターからの返信がある）

任意のチェックの失敗は、この終了条件を妨げません。終了条件を満たした時点で任意のチェックが失敗している場合は、出力にその旨を記載したうえで、スタックの準備が完了したと宣言してください。

次を出力します：「すべての必須チェックが成功し、スタック全体のすべてのレビューコメントに対応しました。PR の準備が完了しました。」

よくある間違い

• 古い CI 結果に基づいて作業する — 失敗を調査する前に、チェックが HEAD のコミットに対するものか必ず確認してください。チェックが保留中の場合は、待ってください。
• 同じコメントに二度返信する — 返信する前に、スレッドの最後の返信がすでにベビーシッターからのものか確認してください。
• ローカルで検証せずにプッシュする — gt modify --commit の前に、必ずプロジェクトの検証コマンドを実行してください。
• 解決すべきでないスレッドを解決する — 実際の問題を修正したスレッドだけを解決してください。スコープ変更や問題ではない内容のスレッドは、レビュアーのために開いたままにしてください。
• 一般的なレビューコメントを見落とす — インラインのスレッドだけを確認しないでください。トップレベルのレビュー本文と issue コメントも必ず取得してください。レビュアーは、最も重要なフィードバックをそこに記載することがよくあります。
• プッシュ後に長く待ちすぎる — 修正をプッシュした後は、CI の結果をすぐに確認できるよう、短い間隔で待機してください。
• スタック内の間違ったブランチを修正する — 問題がある最も下位のブランチを必ず修正してください。上位のブランチを修正すると、マージコンフリクトが発生したり、スタックの再構築時に変更が上書きされたりすることがあります。
• 1 回のループ中に何度もプッシュする — まずすべてのブランチをローカルで修正し（各ブランチで gt modify --commit と gt restack を実行）、その後 gt submit --stack で一度だけプッシュしてください。何度もプッシュすると CI サイクルを無駄にし、競合状態が発生します。
• 修正後に restack を忘れる — スタックの途中にあるブランチを変更した後は、次のブランチに移る前に必ず gt restack を実行し、上位のブランチに変更を反映してください。
• 上位のブランチには影響しないと思い込む — 修正して restack した後は、すべての PR を最初から再確認してください。restack によって上位のブランチで新たな CI 失敗が発生することがあります。
• メインコンテキストで PR のステータスとログを順番に取得する — サブエージェントを使って各 PR の CI とレビューを並行して確認し、詳細な CI ログを取得してください。これにより、各ループの処理を速め、メインコンテキストウィンドウを判断とコード修正のために確保できます。