babysit-pr

PR を見守る

多くのリポジトリには AI レビューボットがあります。常に正しいとは限りませんが、役に立ちます。

待機

独自のウォッチャー、ポーリングループ、sleep ループは決して作成しないでください。PR ごとにウォッチャーを 1 つ使います。T3 Code では watch_pull_request、それ以外では pr-wait を使ってください。同じ PR に両方を使ってはいけません。GitHub アカウント上のすべてのウォッチャーは、1 つのレート制限を共有します。

T3 Code の場合：watch_pull_request

既存のチェックとコメントを先に処理してください。その後、watch_pull_request を呼び出して、ターンを終了します。チェックが失敗したとき、必須チェックに合格したとき、誰かがコメントまたはレビューしたとき、あるいはブランチで競合が発生したときに、T3 Code がメッセージであなたを呼び戻します。

• PR を担当するスレッドだけが、その PR を監視します。 委任された子タスク（レビュアー、Sol のラウンド、delegate_task の子タスクなど）の場合は、watch_pull_request を決して呼び出さないでください。PR の担当は親です。作業していない PR を監視しないでください。
• 呼び戻しは新しい情報であり、マージの判断ではありません。 マージ条件を自分で確認してください。
• 引き継ぐときは監視を解除してください。 監視中のスレッドは Working の状態に留まり、ユーザーの受信トレイには表示されません。作業を止めるとき（準備完了、ブロック中、またはユーザーへの質問時）は、まず unwatch_pull_request を呼び出してください。マージまたはクローズされると、監視は自動的に終了します。
• 「監視を停止しましたが、読み取れませんでした」 は、通常、GitHub のレート制限を使い切ったことを意味します。再度監視する前に、gh api rate_limit --jq .resources.graphql を実行してください。remaining が 0 に近い場合は、バックグラウンドコマンドを 1 つ実行して reset まで待ってから、再度監視してください。短い間隔で監視を繰り返してはいけません。

それ以外の場合：pr-wait

このスキルのディレクトリにある scripts/pr-wait を使って待機してください（絶対パスを使用してください）。

pr-wait <pr> [--repo owner/name] [--until ready|green|any-change]

実際にイベントが発生するたびに、1 行ずつ出力します。--until 条件が満たされるか PR がマージされると終了コード 0、対応が必要な場合（必須チェックの失敗、競合、未解決のスレッド、PR のクローズ）は 1、不正な入力の場合は 2 で終了します。

• ready（デフォルト）：必須チェックがすべて成功し、Greptile または Macroscope が最新のコミットをレビュー済みで、未解決のスレッドがありません。見守るときに使ってください。
• green：必須チェックのみを確認します。リポジトリに Greptile も Macroscope もない場合に使ってください。
• any-change：最初のイベントで終了します。

Claude Code では、Monitor ツール（timeout_ms: 3600000）で実行してください。そうすると、各行が出力されるたびにあなたが呼び戻されます。Monitor を使わない場合は、1 つの長いコマンドとして実行してください。コマンドは自動的に終了します。

プッシュ後、終了コード 1 への対応後、再開後には、もう一度実行してください。すでに報告した内容は記憶しているため、その間に発生したイベントが失われることはありません。別の PID がすでに PR を監視していると表示された場合、2 つ目を起動しないでください。イベントが届かない場合に限り、古いプロセスを終了してください。

どちらのウォッチャーを使う場合も、イベントへの対応が不要なら、メッセージを送らずにターンを終了してください。「まだ待機中」と投稿したり、伝えたりしてはいけません。

GitHub のレート制限

gh pr create、gh pr view、gh pr checks は GraphQL を使います。GraphQL の制限を使い切った場合、REST の制限は別枠であり、通常はまだ余裕があります。PR の読み取りには gh api repos/<owner>/<repo>/pulls/<n> を、チェックには gh api repos/<owner>/<repo>/commits/<sha>/check-runs を使ってください。

レビュー

最新のプッシュ以降に投稿されたチェック結果とコメントだけに対応してください。コードを変更する前に、ボットの指摘をすべてソースと照らし合わせて確認してください。実際の指摘と CI の失敗を修正し、リポジトリの失敗とインフラストラクチャの一時的な問題を区別してください。誤検知を却下する場合は、その理由を文章で返信してください。

リポジトリに .macroscope/check-run-agents/*.md がある場合は、Macroscope の指摘に返信する前に、そのルールを読んでください。Macroscope の指摘にはルールへの参照があります。

CodeRabbit の指摘は参考情報です。他の指摘と同様に扱いますが、CodeRabbit を待ったり、CodeRabbit のためにマージを保留したりしないでください。

対処する価値がないと判断したレビュー bot のフィードバックには、理由を文章で返信し、コメントを解決済みにしてください。ユーザーに代わってコメントを投稿する際は、必ず leaving-pr-comments スキルを使用してください。

アップロードする手段がある場合は、スクリーンショットや動画も役立ちます。

PR の規模は、ユーザーの目的に必要な範囲にとどめてください。レビューのやり取りでは、一見簡単そうな修正を一つずつ加えるうちに、PR が大きくなりがちです。想定されたケースにおける実際のバグを修正してください。それ以外は、理由を文章で添えて見送り、後続対応として記載してください。不要なテスト、重要でないエッジケースへのガード、余分な統合や互換性対応、小さなパフォーマンスコストなどが該当します。コードを削除または縮小する修正を優先してください。

ベースブランチとマージ

main の変更を注視し、必要に応じてリベースしてください。pr-wait は、新しいベースコミットがこの PR のファイルに影響した場合と、PR が BEHIND または DIRTY になった場合に通知します。watch_pull_request が報告するのはコンフリクトのみなので、PR の準備完了を宣言する前に、BEHIND でないことを自分で確認してください。 重複する PR によってこの PR が不要になった場合は、監視を停止してユーザーに報告してください。クローズが明示的に許可されていない限り、PR をクローズする前にユーザーに確認してください。

変更がなければ、内容のないコメントを投稿せず、何もせずに待機してください。pr-wait が 0 で終了するか、T3 Code で最新の head に対するマージゲートが通過したら停止してください。マージするのは、ユーザーが明示的に依頼した場合だけです。それ以外の場合は、PR の準備が整ったことを報告してください。マージの直前には git fetch を実行し、PR を再確認してください。BEHIND または DIRTY の場合、あるいは最後に成功した実行以降に取り込まれたベースコミットがこの PR のファイルに影響している場合は、絶対にマージしないでください。リベースしてプッシュし、再び成功するまで待ってください。