codex-review-loop

Codex レビューループ

ChatGPT Codex によるオンラインの GitHub PR レビューに対して PR を収束させ、その後マージするためのループです。 隠れたインフラはありません。必要なのは gh、同梱のポーリングスクリプト、そして以下の手順だけです。

機械的な処理（トリガー、2 種類のシグナルのポーリング、指摘事項の抽出）は codex-review-loop.sh にあります。判断を伴う処理（指摘事項への対応、検証、マージの決定）は、あなたが行います。

前提条件（最初に確認）

• リポジトリでChatGPT Codex の GitHub PR レビュー連携が有効になっている必要があります（組織／リポジトリの設定）。 PR のオープン時、ドラフトからレビュー可能な状態への変更時、または @codex review コメントの投稿時にレビューが開始されます。Bot アカウント： chatgpt-codex-connector[bot]。リポジトリが連携されていない場合、このループは機能しません。その旨を伝えてください。
• gh の認証が完了しており（gh auth status）、jq がインストールされている必要があります。リポジトリ内からスクリプトを実行してください （gh repo view を使って owner/name を自動検出します）。

ループ

スクリプトはバックグラウンドで実行してください（ポーリングの合間にスリープするため）。完了時に再度呼び出されるようにし、フォアグラウンドでスリープさせないでください。

1. トリガーを送信して、1 ラウンド分ポーリングします。 bash <skill>/codex-review-loop.sh run <PR> は、UTC の基準時刻を記録してから @codex review を投稿し、結果を待ちます。判定結果の行は必ず 1 行だけ出力されます。
   • RESULT=FORMAL_REVIEW id=<rid> ... inline_comments=<n> → Codex が問題を検出しました。スクリプトはインラインの指摘事項（FILE: path:line と本文）も出力します。
   • RESULT=CLEAN ... ／ RESULT=CLEAN_REVIEW ... → このラウンドでは重大な問題はありません。
   • RESULT=TIMEOUT → 再実行するか、PR を手動で確認してください。
2. 指摘事項がある場合： それぞれに対応します。修正する前に、Codex の指摘を実際のコードと照らし合わせてください。誤っている場合もあります（例：コードに存在しない API の仕様を主張することがあります。ソースを確認してください）。実際の問題を修正し（1 つの箇所だけでなく、できれば同種の問題全体を修正します）、プッシュする前にローカルで検証してください（コンパイル、ユニットテスト、リンター、API ゲートなど、リポジトリで使われているもの）。コミットしてプッシュし、手順 1 に戻ります。プッシュすると新しいコミットになるため、クリーンの連続回数はリセットされます。
3. 問題がない場合： これがクリーンの 1 回目です。同じコミットに対してもう一度だけトリガーを送信します（新しいコミットは作成せず、run <PR> を再実行します）。Codex の結果は非決定的で、同じコミットを再レビューして新たな問題が見つかることがあります（実際に確認されています）。2 回連続でクリーンになってから、マージに進みます。
4. マージ（このリポジトリのマージポリシーに関してユーザーの許可がある場合のみ）： gh pr merge <PR> --merge --delete-branch を実行します。その後、ローカルの main を同期します。

スクリプトが 2 種類のシグナルをポーリングする理由

Codex は結果を 2 通りの方法で報告するため、片方だけをポーリングすると判定を半分見逃してしまいます。

• 指摘事項 → 正式なレビュー（/pulls/<PR>/reviews、state=COMMENTED）とインラインコメント。これらは pull_request_review_id を使ってレビューと関連付けられます。
• 問題がない場合 → 本文に「Didn't find any major issues」と書かれたイシューコメント（/issues/<PR>/comments）。

どちらも、Bot のログイン名と、トリガー時に記録した基準時刻より後のタイムスタンプで絞り込みます。そのため、以前の古いレビューを新しい判定と取り違えることはありません。「Codex is reviewing…」という Bot の応答は、問題なしを示す文言と一致しないため無視されます。

重要な手順（痛い経験から学んだこと）

• マージ前に 2 回連続でクリーンにします。 クリーン 1 回だけでは不十分です。Codex の結果は非決定的です。
• 修正する前に検証します。 指摘事項は事実ではなく、確認すべき主張として扱ってください。このコードベースに当てはまらない指摘を、むやみに「修正」しないでください（成功していたゲートを失敗させるおそれがあります）。根拠を示して返信または異議を唱えるか、根本的な懸念を解消する堅牢性の改善を行います。
• プッシュする前に検証します。 修正はそれぞれ、まずリポジトリのローカルゲートを通過させてください。コンパイルエラーでレビューラウンドを無駄にしないようにします。
• 1 ラウンドにつき懸念事項が 1 つでも問題ありません。 終盤のラウンドでは P2／P3 が 1 件だけ見つかることもよくあります。順に解消してください。
• マージを決めるのはユーザーです。 マージポリシーを一度確認し、許可されていないリポジトリを自動マージしないでください。

別のリポジトリへの適用

• 通常、変更は不要です。リポジトリは自動検出されます。ボットのログイン名やクリーンな表現が異なる場合は、 スクリプトの先頭にある BOT / CLEAN_RE を編集してください。
• レビューキューの処理が遅い場合は、poll/run の引数 3、4 にあたる maxIters / interval を調整してください。
• マージ戦略：リポジトリの慣例に応じて、--merge を --squash/--rebase に置き換えてください。