babysit-pr

PRバビシッター

目的

PRが以下の終了状態のいずれかに達するまで持続的に監視します：

• PRがマージまたはクローズされた場合。
• ユーザーの支援が必要な状況が発生した場合（例：CIインフラ問題、再試行回数を使い切った後のフレーキー障害の繰り返し、権限問題、安全に解決できない曖昧な状況）。
• 任意のハンドオフマイルストーン：PRが現在グリーン + マージ可能 + レビュークリーンな状態。これは進行マイルストーンとして扱い、監視停止条件ではありません。PRが開いている間は、遅れて到着したレビューコメントが迅速に通知されるようにします。

単一のスナップショットがチェックが保留中にidleを返しただけでは停止しないでください。

入力

以下のいずれかを受け付けます：

• PR引数なし：現在のブランチからPRを推測（--pr auto）
• PR番号
• PR URL

コアワークフロー

1. ユーザーがPRの「監視」「ウォッチ」「バビシット」を依頼した場合、特に意図的にワンショット診断スナップショットを行わない限り、ウォッチャーの継続モード（--watch）で開始します。
2. ウォッチャースクリプトを実行してPR/レビュー/CI状態のスナップショットを取得します（または--watchからの各ストリームスナップショットを消費します）。
3. JSONレスポンス内のactionsリストを検査します。
4. diagnose_ci_failureが存在する場合、失敗した実行のログを検査し、障害を分類します。
5. 障害が現在のブランチに起因する可能性が高い場合、コードをローカルでパッチし、コミットし、プッシュします。ランダムなフレーキーテスト、CIインフラ、依存関係の停止、ランナー問題、その他ブランチに関係しない障害にはパッチを適用しないでください。
6. process_review_commentが存在する場合、通知された公開レビューアイテムを検査し、対応するか判断します。
7. レビューアイテムが実行可能で正しい場合、コードをローカルでパッチし、コミットし、プッシュし、その後、以下のGitHub状態変更ポリシーで許可されている場合にのみ、関連するレビュースレッドを解決します。
8. 人間が作成したレビューコメント/スレッドに返信を投稿しないでください。ユーザーが正確な返信を明示的に確認した場合を除きます。人間のレビューアイテムが実行不可能、すでに対応済み、または有効でない場合、GitHubで返信する代わりに、そのアイテムと推奨対応をユーザーに通知します。
9. 障害がフレーキー/無関係である可能性が高く、retry_failed_checksが存在する場合、--retry-failed-nowで失敗したジョブを再実行します。
10. 実行可能なレビューフィードバックとretry_failed_checksの両方が存在する場合、レビューフィードバックを優先します。新しいコミットはCIを再トリガーするため、レビュー変更を意図的に延期しない限り、古いSHAでフレーキーチェックを再実行しないでください。
11. ループごとに、CI障害やマージ可能性状態の対応前に、新しく通知されたレビューフィードバックを確認し、その後、CIとともにマージ可能性/マージ競合状態を確認します（例：gh pr viewを使用）。
12. プッシュまたは再実行アクションの後、すぐにステップ1に戻り、更新されたSHA/状態のポーリングを続行します。
13. パッチ/コミット/プッシュのために一時停止する前に--watchを使用していた場合、プッシュ直後に同じターンで--watchを自分で再起動します（ユーザーがスキルを再度呼び出すのを待たないでください）。
14. stop_pr_closedが表示されるか、ユーザー支援が必要なブロッカーに達するまでポーリングを繰り返します。グリーン + レビュークリーン + マージ可能なPRは進行マイルストーンであり、PRが開いている間にウォッチャーを停止する理由にはなりません。
15. 端末/セッションの所有権を維持します。バビシッティングがアクティブな間は、同じターンでウォッチャーの出力を消費し続けます。--watchプロセスをデタッチしたままにして、監視が完了したかのようにターンを終了しないでください。

コマンド

ワンショットスナップショット

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --once

継続的ウォッチ（JSONL）

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --watch

フレーキー再試行サイクルのトリガー（ウォッチャーが示した場合のみ）

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr auto --retry-failed-now

明示的なPRターゲット

python3 .codex/skills/babysit-pr/scripts/gh_pr_watch.py --pr <number-or-url> --once

CI障害分類

再実行を決定する前に、ghコマンドを使用して失敗した実行を検査します。

• gh run view <run-id> --json jobs,name,workflowName,conclusion,status,url,headSha
• gh api repos/<owner>/<repo>/actions/runs/<run-id>/jobs -X GET -f per_page=100
• gh api repos/<owner>/<repo>/actions/jobs/<job-id>/logs > /tmp/codex-gh-job-<job-id>-logs.zip
• gh run view <run-id> --log-failed（ワークフロー実行全体が完了した後のフォールバックとして）

gh run view --log-failedはワークフロー実行スコープであり、実行全体が完了するまで失敗したジョブのログを公開しない場合があります。より迅速な診断のために、まず実行のジョブをポーリングし、特定のジョブが失敗したらすぐに、Actionsジョブログエンドポイントからそのジョブのログを直接取得します。ウォッチャーには、各失敗ジョブのjob_idとlogs_endpointを含むfailed_jobsリストが含まれています（GitHubが公開する場合）。

失敗したジョブログが、変更されたコード（タッチされた領域のコンパイル/テスト/リンター/型チェック/スナップショット/静的解析）を指している場合、障害をブランチ関連として扱うことを優先します。

ログが一時的なインフラ/外部問題（タイムアウト、ランナープロビジョニング障害、レジストリ/ネットワーク停止、GitHub Actionsインフラエラー）を示している場合、障害をフレーキー/無関係として扱うことを優先します。

ログが障害をPRブランチに明確に関連付けていない限り、テスト、ビルドスクリプト、CI設定、依存関係ピン、またはインフラに近いコードを変更してフレーキー/無関係な障害を修正しようとしないでください。フレーキー/無関係な障害の場合、ウォッチャーがretry_failed_checksを推奨した場合にのみ再実行します。それ以外の場合は待機するか、ユーザーの支援を求めます。

分類が曖昧な場合は、再実行を選択する前に1回手動診断を試みます。

簡潔なチェックリストについては、.codex/skills/babysit-pr/references/heuristics.mdを参照してください。

レビューコメント処理

ウォッチャーは以下のレビューアイテムを通知します：

• PR issueコメント
• インラインレビューコメント
• レビュー提出（COMMENT / APPROVED / CHANGES_REQUESTED）

公開されたフィードバックのみに対応します。GitHubのPENDING状態のレビュー提出と、その保留中レビューに添付されたインラインコメントは無視します。保留中のレビューフィードバックを「確認済み」としてマークしないでください。レビュアーがレビューを提出した後に通知されるようにする必要があります。

人間のレビュアーフィードバックに加えて、Codexレビュアーボットのフィードバック（例：chatgpt-codex-connector[bot]からのコメント/レビュー）も意図的に通知します。関連性のないボットノイズはほとんど無視する必要があります。

安全性のため、ウォッチャーは信頼された人間のレビュー著者（例：リポジトリのOWNER/MEMBER/COLLABORATOR、認証されたオペレーター）と、Codexなどの承認されたレビューボットのみを自動通知します。

新しいウォッチャー状態ファイルでは、既存の未対応の公開レビューフィードバックが即座に通知される場合があります（監視開始後に到着したコメントのみではありません）。これは、すでに開いているレビューコメントを見逃さないように意図的に行われています。

コメントに同意し、実行可能な場合：

1. コードをローカルでパッチします。
2. codex: address PR review feedback (#<n>)でコミットします。
3. PRのヘッドブランチにプッシュします。
4. プッシュが成功したら、以下のGitHub状態変更ポリシーで許可されている場合にのみ、関連するGitHubレビュースレッドを解決します。
5. 新しいSHAで直ちに監視を再開します（プッシュを報告した後に停止しないでください）。
6. 監視が--watchモードで実行されていた場合、プッシュ直後に同じターンで--watchを再起動します。ユーザーが再度要求するのを待たないでください。

人間が作成したGitHubレビューコメント/スレッドに自動的に返信を投稿しないでください。人間のコメントに同意できない場合、実行不可能/すでに対応済みと考えられる場合、または質問に答える必要がある場合、そのアイテムを推奨返信とともにユーザーに報告し、GitHubに投稿する前に明示的な確認を待ちます。ユーザーが返信を承認した場合、自動化された返信であり人間ユーザーからのものではないことを明確にするために、[codex]プレフィックスを付けます。

後でウォッチャーがあなた自身の承認済み返信を通知した場合（認証されたオペレーターが信頼されたレビュー著者として扱われるため）、その自己作成アイテムはすでに処理済みとして扱い、再度返信しないでください。

コードレビューコメント/スレッドがGitHubですでに解決済みとしてマークされている場合、新しい未解決のフォローアップフィードバックがない限り、実行不可能として扱い、安全に無視します。

GitHub状態変更ポリシー

監視に必要なPR状態はすべて読み取ることができます。書き込みはこのポリシーに準拠する必要があります。

上記の説明に従って、レビュー中のコードを更新したり、CI再実行を強制するためにPRをプッシュできます。

バビシッティングを依頼した人間、またはCodexレビューボットからのレビューコメントスレッドを解決できます。解決する際は、[from Codex]: プレフィックスを付けたコメントを残し、どのような変更を行い、どのコミットにそれらが含まれているかを説明します。バビシッティングを依頼したユーザー以外の人間が参加しているレビュースレッドには触れないでください。

変更を行う前に、PRウォッチャースクリプトの出力に依存せず、自分でPR状態を取得します。

明示的に依頼されない限り、以下を行わないでください：

• 他の人間のレビュースレッドにコメントする。代わりにチャットでユーザーと通信する。
• ユーザー以外の人間からのレビュースレッドを解決する。
• ユーザー以外の人間と対話する。
• PRをドラフトまたはレビュー準備完了としてマークする。
• PRをクローズまたは再オープンする。

一般的に、あなたが行ったこととユーザーが行ったことを他の人間が見分けにくくなる方法でGitHub上で行動しないでください。疑わしい場合は、チャットでユーザーに明確化を求めます。

Git安全ルール

• PRのヘッドブランチのみで作業します。
• 破壊的なgitコマンドを避けます。
• 文脈を回復するために必要な場合を除き、ブランチを切り替えないでください。
• 編集前に、関連性のない未コミットの変更がないか確認します。存在する場合は停止し、ユーザーに問い合わせます。
• 各修正が成功した後、コミットしてgit pushし、その後ウォッチャーを再実行します。
• 修正のためにライブの--watchセッションを中断した場合、プッシュ直後に同じターンで--watchを再起動します。
• 同じPR/状態ファイルに対して複数の--watchプロセスを同時に実行しないでください。1つのウォッチャーセッションをアクティブに保ち、停止するか意図的に再起動するまで再利用します。
• プッシュは終了結果ではありません。厳密な停止条件が満たされない限り、監視ループを続行します。

コミットメッセージのデフォルト：

• codex: fix CI failure on PR #<n>
• codex: address PR review feedback (#<n>)

監視ループパターン

ライブのCodexセッションでこのループを使用します：

1. --onceを実行します。
2. actionsを読み取ります。
3. 最初にPRがマージまたはクローズされたかどうかを確認します。その場合、その終了状態を報告し、直ちにポーリングを停止します。
4. CIサマリー、新しいレビューアイテム、マージ可能性/競合状態を確認します。
5. CI障害を診断し、ブランチ関連とフレーキー/無関係を分類します。全体の実行がまだ保留中でも、failed_jobsに失敗したジョブがすでに含まれている場合、そのジョブのログを取得して即座に診断します。ワークフロー実行全体が完了するのを待たないでください。障害がブランチ関連の場合のみパッチを適用します。
6. 別の著者からの各通知レビューアイテムについて、実行可能な場合はパッチ/コミット/プッシュし、その後、上記のGitHub状態変更ポリシーで許可されている場合にのみ解決します。実行不可能、すでに対応済み、または書面での回答が必要な場合、自動投稿する代わりに、推奨返信とともにユーザーに通知します。後続のスナップショットがあなた自身の承認済み返信を通知した場合、情報として扱い、再度返信せずに続行します。
7. 実行可能なレビューコメントとフレーキー再実行の両方が存在する場合、レビューコメントを優先して処理します。レビュー修正にコミットが必要な場合、それをプッシュし、古いSHAで失敗したチェックを再実行しないでください。
8. retry_failed_checksが存在し、かつ現在のSHAをレビュー/CI修正コミットで置き換えようとしていない場合にのみ、失敗したチェックを再実行します。CIをグリーンにするためだけに、関連性のないフレークやインフラ障害に対してコード変更を行わないでください。
9. コミットをプッシュした場合、対象となるレビュースレッドを解決した場合、または再実行をトリガーした場合、アクションを簡単に報告し、ポーリングを続行します（停止しないでください）。人間のレビューコメントに書面でのGitHub返信が必要な場合、投稿前に停止して確認を求めます。
10. レビュー修正プッシュ後、厳密な停止条件がすでに満たされていない限り、同じターンで継続的監視（--watch）を積極的に再起動します。
11. すべてが成功し、マージ可能で、必要なレビュー承認でブロックされておらず、未対応のレビューアイテムがない場合、PRは現在マージ準備ができていると報告しますが、PRが開いている間は新しいレビューコメントが迅速に通知されるようにウォッチャーを実行し続けます。
12. ユーザー支援が必要な問題（インフラ停止、フレーキー再試行の使い果たし、不明瞭なレビュアー要求、権限）でブロックされた場合、ブロッカーを報告して停止します。
13. それ以外の場合は、以下のポーリング間隔に従ってスリープし、繰り返します。

ユーザーがPRの監視/ウォッチ/バビシットを明示的に要求した場合、--watchを優先して使用し、ポーリングが1つのコマンドで自律的に継続されるようにします。デバッグ、ローカルテスト、またはユーザーが明示的にワンショットチェックを要求した場合にのみ、--onceスナップショットを繰り返し使用します。

ポーリングを続行するかどうかをユーザーに確認するために停止しないでください。厳密な停止条件が満たされるか、ユーザーが明示的に中断するまで自律的に続行します。

新しいSHAが作成されたという理由だけで、レビュー修正プッシュ後に制御をユーザーに戻さないでください。ウォッチャーの再起動とポーリングループへの再突入は、同じバビシッティングタスクの一部です。

--watchプロセスがまだ実行中で、厳密な停止条件に達していない場合、バビシッティングタスクはまだ進行中です。ターンを終了する代わりに、ウォッチャーの出力をストリーミング/消費し続けます。

ポーリング間隔

レビューポーリングは積極的に行い、CIがグリーンになった後も監視を続けます：

• CIがグリーンでない間（保留中/実行中/キューイング中または失敗）：1分ごとにポーリングします。
• CIがグリーンになった後：PRが開いている間は基本間隔でポーリングを続け、新しく投稿されたレビューコメントが長期のグリーン状態バックオフを待たずに迅速に通知されるようにします。
• 何かが変更されるたびに（新しいコミット/SHA、チェックステータスの変更、新しいレビューコメント、マージ可能性の変更、レビュー決定の変更）即座に間隔をリセットします。
• CIが再びグリーンでなくなった場合（新しいコミット、再実行、または後退）：基本ポーリング間隔を維持します。
• いずれかのポーリングでPRがマージまたはクローズされたことが示された場合：直ちにポーリングを停止し、終了状態を報告します。

停止条件（厳密）

…（翻訳のため省略）