Codex 再レビュー依頼

@codex review の投稿とスレッドへの返信は、いずれもコメント者がユーザー本人になるようにする。ボットやエージェント名義（例: cursor）では投稿しない。セッションですでに認められた投稿・修正の範囲を引き継ぎ、承認を繰り返し求めない。スキルの適用だけでは投稿やマージの許可は増えない。

レビューの依頼と追跡

投稿者の確認（レビュー依頼・スレッド返信の共通手順）

投稿許可と投稿名義は別に確認する。投稿を許可されていても、エージェント名義の認証を使ってよいことにはならない。

投稿経路は CLI とコネクタのみとする。本人認証を確認できる CLI を優先し、コネクタは書き込み時の認証主体まで確認できる場合に使う。ブラウザの GitHub は投稿経路の候補に含めない。どちらも使えない場合は投稿を停止し、必要な本人認証を報告する。

1. セッションで確認済みのユーザーの GitHub アカウントを、期待する投稿者として記録する。PR 作成者、Git の user.name / user.email、コメント本文の署名から本人を推定しない。本人のアカウントが不明で、利用可能な認証情報のメタデータでも特定できない場合だけ、GitHub ログイン名を確認する。
2. 書き込みに使う経路と同じホスト・認証で、現在の認証主体のログイン名とアカウント ID を読み取り、期待する本人と照合する。CLI なら実際の投稿と同じ環境の gh api user などを使う。別の CLI・コネクタ・ブラウザで確認した本人情報を流用しない。ツールの説明がエージェント名義での投稿を示す場合、そのツールは使わない。名義を確認できない書き込みツールも使わない。
3. 本人と一致する経路でのみ投稿する。利用可能な本人認証の経路があればそれを使い、一致しない経路へフォールバックしない。使える経路がなければ、投稿本文を用意したうえで、必要な本人認証と未投稿であることを報告する。試し投稿による名義確認や、無断でのアカウント切り替え・認証設定変更はしない。
4. 投稿結果またはコメントの再取得で、コメント ID・URL と実際の作者のアカウント ID を確認する。本人と一致したことを確認してから依頼済み・返信済みとして記録する。経路や認証が変わった場合は、次の投稿前に認証主体を確認し直す。

コネクタのプロフィール取得が本人を返しても、コメント投稿が同じ本人認証を使うとは限らない。投稿ツールの仕様と併せて確認し、書き込み時の主体を確定できなければ、プロフィール取得だけで本人名義の投稿が保証されたと判断しない。

投稿後に名義の不一致が判明した場合は、コメント URL と実際の作者を報告し、この実行の追加投稿を停止して終了する。正しい本人認証が見つかっても、この実行内では再投稿しない。既存コメントをどう扱うかと再依頼の要否は、ユーザーの対応指示を受けてから判断する。誤名義のコメントも存在する投稿として記録し、未投稿として扱わない。本人名義での依頼成功とは区別するが、投稿名義の不一致だけで正規 Codex の応答まで偽物と判定しない。タイムアウトなどで投稿結果が不明な場合も、既存コメントを照会して投稿の有無・作者を確認するまで再送しない。本文の編集では投稿者は変わらないため、編集による名義修正や自動削除・再投稿をしない。

依頼のタイミング

開始時に PR の HEAD SHA、Draft 状態、既存のレビュー・依頼・未解決スレッド、必須 CI を確認する。依頼ごとに対象 HEAD とコメント ID を記録する。

PR 作成時の自動レビューは、設定や実行履歴で確認する。最新 HEAD のレビューが進行中なら待ち、完了済みなら再依頼しない。自動レビューが無効、または実行の証拠がなく依頼もない場合は、認められた範囲で初回の @codex review を投稿する。既存依頼があるのに応答がない場合は連投せず、待機の終了条件を適用する。

初回以降は HEAD が変わったあと（指摘対応・CI 修正など理由を問わない）に再依頼する。同じ HEAD への連投はしない。ただし、コード変更なしで指摘を dismiss して resolve した場合は、同じ HEAD でも再依頼してよい。この例外は新しく処理した指摘に対して一度だけ使い、処理したスレッドと再依頼を記録する。

PR コメントは次の一文のみとする。Draft の Ready 化はユーザーから明示的に依頼された場合だけ行う。

@codex review

応答と指摘対応

応答は、リポジトリの連携設定・投稿者 ID で確認した正規の Codex アカウント（例: chatgpt-codex-connector[bot]）からのものだけを採用する。表示名や本文の一致だけで判断しない。次のいずれかを対象 HEAD の応答として扱う。

• 対象 HEAD のレビューに指摘スレッドが付く。
• 記録した対象 HEAD の @codex review コメントに Codex 自身の 👍 が付く。
• 対象 HEAD 向けに指摘なしコメントが付く（例: Didn't find any major issues）。

レビューの commit ID、実行履歴、または対象 HEAD を記録した依頼との対応で確認する。投稿日時だけでは最新 HEAD の完了とみなさない。対応を確認できなければ未確認として扱う。👀 のみは未完了。指摘なしコメントが確認できれば 👍 は待たない。

指摘への応答が届いたことと、指摘対応の完了を区別する。指摘は内容を確認して修正・検証し、対応済みの指摘には返信してスレッドを解決済みにする。採用しない指摘は根拠を返信して解決する。HEAD が変われば以前の完了判定を引き継がず、新しい HEAD に再レビューを依頼する。同じ HEAD の例外で再依頼した場合も、その応答を確認する。

待機と終了

ユーザー指定の期限を優先する。指定がなければ、この実行で Codex と CI に費やす累計待機時間を 30 分までとする。依頼の再投稿や HEAD の変更でこの上限をリセットしない。状態確認は数分間隔とし、環境の待機手段で分割して進捗を伝える。レート制限時は指定された再試行時刻に従い、それが期限を超えるなら終了する。

待機期限に達した場合、権限・連携の不足で確認できない場合、または外部サービスの障害で進められない場合は、確認済みの結果と残る条件を報告して終了する。成功とは報告せず、対象 HEAD、最後のレビュー依頼、未完了の CI・スレッド、再開に必要な状態を示す。無応答への連投、期限の無期限延長、自動化の新規作成はしない。修正可能な CI 失敗や競合は、依頼された範囲で対応を続ける。

終了報告の直前に HEAD と PR の状態を再取得し、次を確認する。

• PR に競合がない。マージ可能性が未確定なら確認待ちとする。
• 未解決スレッドがない。
• 現在の PR HEAD に対する必須 CI が完了している（成功、または許容された skip / パス除外による未実行）。pending / queued、および適用されるチェックの未作成は未完了。
• 最新 HEAD に対する Codex 完了がある。対象依頼への 👍・指摘なしコメント・そのレビューで出た指摘のすべて対応および resolve 済みのいずれかを確認する。再依頼が必要な場合は、その応答も確認済みであること。初回自動レビューも同じ基準で確認する。

すべて満たした場合、Draft なら「検証完了・Draft 維持」、Draft でなければ「merge-ready」として報告して止める。Draft であることだけを理由に待機や Ready 化はしない。明示がない限りマージしない。