codex-code-review

Codex による敵対的コードレビュー

主担当のコードレビュアーとして振る舞います。外部レビュアーとして OpenAI Codex CLI と指摘事項を議論し、確度の高いレビューを作成してください。このスキルを呼び出したエージェントやプロバイダーを推測してはいけません。

あなたは読み取り専用です。ファイル編集ツールや書き込みツールを使用してはいけません。リポジトリ内のファイルを変更または作成してはいけません。修正を提案または適用してはいけません。指摘事項のみを報告してください。

参照ファイル

該当する手順に進んだら、以下を読んでください。

• references/debate-protocol.md - 議論ループの仕組み、収束ルール、エラー処理、役割を逆にした議論。ステップ 6 の前に読んでください。
• references/prompt-template.md - Codex 呼び出し用プロンプトテンプレートと出力解析のガイダンス。ステップ 4 の前に読んでください。

深度モード

ユーザーのリクエストから、どの深度モードにするかを判断します。

Quick：Codex による 1 回限りのレビュー。議論は行いません。ユーザーが「quick」「fast」「single pass」などと言った場合に使用します。

Deep：重大および警告レベルの指摘をすべて敵対的議論ループに進めます。情報レベルの指摘はそのまま通します。ユーザーが「deep」「thorough」「argue everything」などと言った場合に使用します。

Auto（デフォルト）：以下の基準に基づいて、議論する対象を決めます。

• 差分が 200 行未満で、重大または警告レベルの指摘がある場合：それらすべてを議論します
• 差分が 200 行を超える場合：重大な指摘のみ議論し、警告および情報レベルの指摘はそのまま通します
• 認証、暗号、支払い、権限、またはセキュリティ上重要なパスに関わるファイルの場合：差分のサイズにかかわらず、重大および警告レベルの指摘をすべて議論します
• 情報レベルの指摘のみの場合：議論を省略します
• 指摘が 10 件以上の場合：深刻度の高い上位 5 件のみ議論します

レポートの冒頭に、選択したモードとその理由を記載してください。

ステップ 1：リクエストを把握する

ユーザーが指定した引数を確認します。以下が含まれる場合があります。

• 直接レビューするファイルパス
• 未コミットの変更をレビューするディレクトリ
• 差分比較の対象となるブランチ名
• レビューするコミット SHA
• PR 番号または GitHub PR URL
• 深度の指定（「quick」「deep」「thorough」など）
• 注目する領域（例：「SQL インジェクションに注目」）

自然に解釈してください。トークンがファイルパスのように見える場合は、存在するか確認してください。ブランチのように見える場合は、git で確認してください。ディレクトリのように見える場合は、そのディレクトリに移動してください。PR 番号または GitHub PR URL のように見える場合は、gh pr view <number> --json number で確認してください（差分は取得しないでください。Codex が自ら gh pr diff を実行します）。該当するものが見つからない場合（ファイル、ディレクトリ、ブランチ、コミット SHA、PR のいずれでもない場合）は、ユーザーに「'' を解決できませんでした。ファイル、ディレクトリ、ブランチ、コミット SHA、または PR 番号ではありません。」と伝えてください。

対象が指定されていない場合は、現在の作業ディレクトリにある未コミットの変更をレビューしてください。

ステップ 2：前提条件を確認する

which codex を実行します。見つからない場合は、そこで終了して「codex CLI がインストールされていません。次のコマンドでインストールしてください：npm install -g @openai/codex」と報告してください。

ファイル以外のレビュー方式では、git rev-parse --git-dir を使って git リポジトリ内にいることを確認してください。

Step 3: レビュー対象を決定する

ユーザーの依頼に基づいて、Codex が何をレビューする必要があるかを判断します。自分で差分を生成したり、ファイルの内容を読み取ったりしないでください。Codex はファイルシステム全体にアクセスできるため、自分で確認できます。Codex が確認すべき場所を把握できるよう、対象を明確に説明するのがあなたの役割です。

• 未コミットの変更：git status で実際に変更があるかを手早く確認します。変更がない場合は、「未コミットの変更は見つかりませんでした」と報告します。Codex に渡す対象の説明は、「<absolute repo path> 内の未コミットの変更（ステージ済みおよび未ステージ）」です。
• ブランチの差分：git rev-parse でブランチの存在を確認します。対象の説明は、「<absolute repo path> 内の、現在のブランチと <branch> の比較による変更」です。
• コミット：SHA の存在を確認します。対象の説明は、「<absolute repo path> 内のコミット <SHA> によって導入された変更」です。
• PR：gh pr view で PR の存在を確認します。対象の説明は、「PR #<N> の変更です。Codex は差分を確認するために gh pr diff <N> を実行してください。チェックアウト先は <absolute repo path> です」です。
• ファイルパス：ファイルが存在することを確認します。対象の説明は、「ファイル <absolute paths>」です。

すべてのパスを絶対パスに解決します。次のステップで、この対象の説明を Codex に渡します。

Step 4: Codex から初回レビューを取得する

正確なプロンプト形式と出力の解析方法については、references/prompt-template.md を読みます。プロンプトでは説明によってレビュー対象を指定します。差分、ファイルの内容、コードをプロンプトに貼り付けてはいけません。Codex がファイルを読み取り、自分で git コマンドを実行します。

レビュー用プロンプトを使って codex exec を呼び出します。必ず --full-auto を渡してください。heredoc 構文を使って標準入力経由で渡します。

codex exec --full-auto - <<'CODEX_PROMPT'
<prompt content here>
CODEX_PROMPT

シェルコマンド内では、ユーザーが指定した値を必ず引用符で囲みます。プロンプトの内容がシェルによって解釈されるのを防ぐため、echo "$PROMPT" より heredoc を優先してください。

ワークフローをブロックせずに Codex を実行する

Codex の処理には時間がかかります。詳細なレビューには通常 3〜10 分かかり、大きな差分の場合はさらに長くなることもあります。利用可能な場合は、現在のランタイムのバックグラウンド実行またはノンブロッキングのプロセス機能を使い、上限を 10 分に設定します。ランタイムがフォアグラウンドコマンドしかサポートしていない場合は、その環境で Codex を実行し、同じ上限時間内で完了を待ちます。ポーリング、スリープ、ビジーループは行わないでください。

ランタイムが許す場合、Codex の実行中にほかの有用な作業を行います。変更されたファイルを再読する、Step 6 の役割を逆転した議論に向けて独立した指摘事項を整理する、レポートの構成を準備する、といった作業ができます。

10 分の上限に達した場合は、ランタイムで利用可能な手段を使って、プロセスの途中出力を確認します。Codex がまだ進行中であれば、同じプロンプトで、時間を制限した再実行を行います。Codex が正常に終了し、進捗がなかった場合に限り、実行失敗と判断します。

Codex のスキップは失敗であり、代替策ではありません

このスキルの価値は、Codex による独立したレビューにあります。主レビュー担当者だけの結果では、その目的が気づかれないまま損なわれます。「Codex の処理に時間がかかりすぎる」は「さらに待つ」と解釈し、外部レビューを放棄する理由にしてはいけません。

Codex を使わずに進めてもよい理由は、次のものに限られます。

• codex がインストールされていない（Step 2 で確認済み）
• 具体的なエラー（認証、ネットワーク、API の失敗）による終了コードが 0 以外の場合 — エラーをそのまま提示します
• 正常終了したにもかかわらず、出力が本当に空の場合

次の理由は認められません。

• 「しばらく時間が経った」
• 「キャッシュが期限切れになるのが心配」
• 「ユーザーを待たせている気がする」
• 「差分が大きいので、自分だけでレビューする」

上記の基準に従って Codex が本当に失敗した場合は、そこで停止し、ユーザーに次のように伝えます。Codex failed: <reason>. Retry, or proceed with a primary-reviewer-only review? ユーザーの判断を待ってください。黙ってレビューの範囲を縮小してはいけません。

**出力の検証：**出力に NO_ISSUES_FOUND または少なくとも 1 つの FINDING: マーカー（大文字と小文字は区別しません）が含まれていることを確認します。出力が正確に一致しない場合の解析方法については、プロンプトテンプレートのリファレンスを参照してください。

**Codex が NO_ISSUES_FOUND を返した場合：**Deep モードまたは Auto モードでは、そこで終了せず、役割を逆転した議論を行うため Step 6 に進みます。Quick モードでは、問題なしと報告して終了します（Quick は仕様上、1 回のパスのみです）。

ステップ 5：深度モードに応じて指摘をトリアージする

• Quick：議論を省略します。すべての指摘をそのままレポートに記載します。
• Deep：重大および警告の指摘すべてについて議論します。情報レベルの指摘はそのまま通します。
• Auto：上記のヒューリスティックを適用します。判断の根拠を記録します。

ステップ 6：敵対的な議論ループ

議論の詳細な進め方、収束ルール、役割を逆転させる議論のプロトコルについては、references/debate-protocol.md を読んでください。

議論の候補ごとに、次の手順を実行します。

1. 参照されている行の実際のソースファイルを読みます（前後 20～30 行のコンテキストを含む）。
2. EVIDENCE の引用とソースを照合して、行番号が正しいことを確認します。行番号が誤っている場合は正しい行を見つけ、そちらを使用します。
3. 議論のプロトコルに従います。具体的なコードの根拠を示して異議を唱え、Codex に回答させ、収束するか 5 ラウンドに達するまで繰り返します。

Codex のターン： 異議を伝えて codex exec を呼び出します。Codex が確認すべきファイルと行の範囲を説明してください。コードをプロンプトに貼り付けないでください。Codex はソースファイルを自分で読み取れます。DEFEND、RETRACT、または REVISE で回答するよう Codex に求めてください。

Codex が NO_ISSUES_FOUND を返した場合は、役割を逆転させた議論を実施します。見落とされている問題がないか、変更箇所を独自に確認してください。独自の指摘を 2～3 件作成し、Codex に提示して反論を求めます。

現在のランタイムが並列タスクまたはサブプロセスをサポートしている場合、異なる指摘に関する独立した議論ラウンドは並列実行できます。

ステップ 7：指摘をレポートする

構造化されたレポートを出力します。却下された指摘は含めないでください。

## Code Review Results

Mode: <quick | deep | auto (with reasoning)>
Reviewed: <what was reviewed>
Debated: <N findings challenged> | Passed through: <M findings>
Findings: <X confirmed, Y unresolved, Z dismissed>

### Confirmed Issues

#### [SEVERITY] <title>
**File:** `<path>:<line>`
**Evidence:**
\`\`\`
<the relevant code>
\`\`\`
**Problem:** <description>
**Agreed by both reviewers after N rounds**

### Unresolved (Disagreement)

#### [SEVERITY] <title>
**File:** `<path>:<line>`
**Codex's position:** <summary>
**Primary reviewer's position:** <summary>
**Recommendation:** <your best judgment>

### Info

#### <title>
**File:** `<path>:<line>`
**Note:** <description>

空のセクションは省略します。指摘がまったくない場合は、「両方のレビュアーが合意しました：重大な問題は見つかりませんでした。」と記載します。

注意点

• codex exec は標準出力に出力します。一時ファイルや -o フラグは不要です。呼び出して出力を読み取ってください。
• Codex のプロンプトに差分、ファイル内容、コードブロックを渡さないでください。Codex はファイルシステムにアクセスできます。コードの内容ではなく、確認すべき場所を伝えてください。
• 別のディレクトリにあるファイルをレビューする場合は、cd する前にすべてのパスを絶対パスに解決してください。
• インジェクションを防ぐため、シェルコマンドではユーザーが指定した値を必ず引用符で囲んでください。

実行例

/codex-code-review
/codex-code-review /path/to/other/repo
/codex-code-review src/auth.ts src/api/handler.ts
/codex-code-review main
/codex-code-review abc1234
/codex-code-review #42
/codex-code-review quick review
/codex-code-review deep review of branch main
/codex-code-review focus on SQL injection vulnerabilities