Codex Review

起動したら最初に codex の枠を見る (ratelimit -source codex -check。rc=1 のときの扱いは subagent-model-tiering.md の「枠の残量」)。

codex exec review を基本に、必要なら codex exec を fallback として使い、コード変更に対する Codex のレビューを取得する。

引数

$ARGUMENTS は自由テキスト。commit ID、差分の基点、重点的に見てほしい観点を含められる。

/codex-review                                    → 未コミット変更をデフォルトレビュー
/codex-review --uncommitted                      → 未コミット変更をデフォルトレビュー
/codex-review abc1234                            → 特定コミットをデフォルトレビュー
/codex-review abc1234..HEAD                      → 現在の HEAD に対する差分をデフォルトレビュー（--base abc1234）
/codex-review origin/master..HEAD                → upstream との差分をデフォルトレビュー
/codex-review 削除ロジックの安全性を重点的に見て     → 未コミット変更を重点レビュー
/codex-review abc1234 削除ロジックの安全性を重点的に見て → 特定コミットを重点レビュー
/codex-review --strict                           → 未コミット変更を厳しめにレビュー
/codex-review --adversarial                      → 未コミット変更を敵対的にレビュー（壊しにいく）
/codex-review abc1234 --adversarial              → 特定コミットを敵対的にレビュー

手順

1. 引数のパース

$ARGUMENTS から以下を抽出する:

• --uncommitted: 明示的にフラグがあれば未コミット変更をレビュー
• --strict: 厳しめレビューモード
• --adversarial: 敵対的レビューモード（「壊れている」前提で反証しにいく。「敵対的に」「壊しにいって」「red team で」等の自然文でも同じ扱い）。--strict と併記されたら --adversarial が優先（上位互換）
• 基点付き差分: {base}..HEAD または {base}..{current_head_sha} 形式のみ --base {base} として使用する。{base} は commit SHA でもブランチ名でもよい
• 任意の差分範囲: {base}..{target} で {target} != HEAD の場合、codex exec review ではそのまま表現できない。誤った差分をレビューしないため、そのまま --base に変換せず、終点を HEAD に合わせて実行するかをユーザーに確認する
• commit ID: 7〜40文字の hex 文字列（[0-9a-f]{7,40}）が単独であれば --commit {sha} として使用
• カスタム指示: 上記以外のテキスト（レビュー指示に追記する）
• デフォルト: 何も指定がなければ codex exec review --uncommitted で未コミット変更をレビュー。master 直作業の運用では、必要に応じて origin/master..HEAD のように基点を明示する
• CLI 制約: codex exec review は --base / --commit / --uncommitted と [PROMPT] を併用できない。selector を使う場合はプロンプトなしで実行する
• コマンド選択:
  • selector のみ: codex exec review
  • selector なしで --strict / --adversarial またはカスタム指示あり: codex exec review のプロンプト付きモード
  • selector と --strict / --adversarial / カスタム指示が両方ある: codex exec -s read-only を使う

2. 出力先の準備

d="$(skill-tmpdir codex-review)"   # <本体 checkout>/tmp/codex-review/<session-id>/ を作って返す (dotfiles の bin/skill-tmpdir)
stamp="$(date +%Y%m%d-%H%M%S).$$"
review_out="$d/review.$stamp.md"

• 出力ファイルは毎回ユニークなパスにする。tmp/ 直下に置かない (直下に散ると掃除できない。dotfiles issue 774)

3. レビューの実行

codex exec review を基本に使用する。--ephemeral -o "$review_out" は常に付与する（--full-auto は付けない。理由は「ルール」参照）。selector と追加指示を両立させる必要がある場合のみ、codex exec -s read-only を使う。

レビュー指示テンプレート

通常モード（プロンプト付き）:

コードレビューして。バグ、リグレッション、仕様逸脱、テスト不足を優先。問題があるものだけを重要度順に列挙し、各項目に file:line、理由、最小修正案を書く。要約や称賛は不要。

厳しめモード（--strict）:

厳しめにコードレビューして。バグ、データ破壊、クラッシュ、並行処理の不整合、仕様逸脱、テスト不足を優先。良い点の記述は不要。問題があるものだけを重要度順に列挙し、各項目に file:line、再現条件、理由、最小修正案を書く。

敵対的モード（--adversarial）:

この変更は「壊れている」という前提で敵対的にレビューして。目的は感想を述べることではなく、壊れることを具体的に実証すること。

## やること
- この実装を壊す入力・状態・順序・タイミング・環境を自分で構築する（境界値 / 空・巨大・不正データ / 異常系 / 並行・再入 / 再送・二重実行 / 部分失敗 / リトライ / 再起動 / 権限・ネットワーク断 / 別プラットフォーム・別バージョン）
- コード・コメント・コミットメッセージ・テスト名にある主張（「〜は保証される」「対応済み」「検証済み」「ありえない」）を 1 件ずつ反証しにいく。反証できなかったものは「反証できなかった」と明記する
- テストが実装を追認しているだけでないか疑う: 自作エンコーダを自作デコーダで往復させるだけの循環テスト、常に真になるアサーション、本物の契約とずれたモック、失敗しても気づけないテスト
- 「問題なし」で終わらせない。壊せなかったなら、どこまで攻めて壊せなかったのかを書く

## 出力
問題ごとに: file:line / **発火条件**（具体的な入力・順序・環境。再現手順の形で）/ 何が壊れるか（データ破壊・クラッシュ・誤結果・ハング・サイレント不整合）/ 最小の構造的修正案。
発火条件を具体的に示せないものは **「未確認リスク」** として別セクションに分けて書く（確証のない断定をしない）。要約・称賛は不要。

カスタム指示がある場合は、テンプレートの末尾に追記する。

敵対的モードの effort の既定は high。xhigh / max が常に劣るとは断定しない。 未解決の不変条件に合う攻め口・実験を先に選び、effort を変えるときは codex-drive のモデル表にある比較手順を使う。

例外: 呼び出し側の skill が effort を指定していれば従う。完了は本数でなく、対象差分・重要な不変条件・採用指摘・未確認範囲を照合して判断する。1 本で足りる場合も「指摘なし」を正しさの証明にせず、未解決の重要項目があれば別 lens・実験を追加する。

実行モード

• デフォルトモード: 引数なしなら codex exec review --uncommitted を使う
• プロンプト付きモード: selector なしで実行する。未コミット変更に対して --strict / --adversarial やカスタム指示を渡したい時に使う
• selector モード: --uncommitted / --commit / --base を付けて実行する。この場合はプロンプトを付けない
• fallback モード: selector と --strict / --adversarial / カスタム指示を両立させたい時は codex exec -s read-only を使い、対象差分をプロンプト内で明示する

実行パターン

# 🚨 全パターンで `</dev/null` 必須（理由は下記「ルール」参照）

# パターン A: デフォルトの未コミットレビュー
command codex exec review -m gpt-6.1-sol -c model_reasoning_effort="high" --uncommitted --ephemeral -o "$review_out" </dev/null

# パターン B: プロンプト付きの未コミットレビュー
command codex exec review -m gpt-6.1-sol -c model_reasoning_effort="high" --ephemeral -o "$review_out" </dev/null \
  'コードレビューして。バグ、リグレッション、仕様逸脱、テスト不足を優先。問題があるものだけを重要度順に列挙し、各項目に file:line、理由、最小修正案を書く。要約や称賛は不要。'

# パターン C: 特定コミットのデフォルトレビュー
command codex exec review -m gpt-6.1-sol -c model_reasoning_effort="high" --commit {sha} --ephemeral -o "$review_out" </dev/null

# パターン D: 現在の HEAD に対する差分のデフォルトレビュー
command codex exec review -m gpt-6.1-sol -c model_reasoning_effort="high" --base {base} --ephemeral -o "$review_out" </dev/null

# パターン E: 特定コミットを重点レビューする fallback
command codex exec -s read-only -m gpt-6.1-sol -c model_reasoning_effort="high" --ephemeral -o "$review_out" </dev/null \
  'commit {sha} をコードレビューして。重点観点: {custom_instruction}。最初に `git show --stat --oneline {sha}` と必要な diff を確認してからレビューする。バグ、リグレッション、仕様逸脱、テスト不足を優先し、問題があるものだけを重要度順に列挙し、各項目に file:line、理由、最小修正案を書く。要約や称賛は不要。'

# パターン F: 基点付き差分を重点レビューする fallback
command codex exec -s read-only -m gpt-6.1-sol -c model_reasoning_effort="high" --ephemeral -o "$review_out" </dev/null \
  '{base}..HEAD の差分をコードレビューして。重点観点: {custom_instruction}。最初に `git diff --stat {base}..HEAD` と必要な diff を確認してからレビューする。バグ、リグレッション、仕様逸脱、テスト不足を優先し、問題があるものだけを重要度順に列挙し、各項目に file:line、理由、最小修正案を書く。要約や称賛は不要。'

# パターン G: 未コミット変更の敵対的レビュー（selector なし・プロンプト付きモード）
command codex exec review -m gpt-6.1-sol -c model_reasoning_effort="high" --ephemeral -o "$review_out" </dev/null \
  '<上記「敵対的モード」テンプレート全文>'

# パターン H: 特定コミット / 基点付き差分の敵対的レビュー（selector 併用なので fallback）
command codex exec -s read-only -m gpt-6.1-sol -c model_reasoning_effort="high" --ephemeral -o "$review_out" </dev/null \
  'commit {sha}（または {base}..HEAD の差分）を対象に、<上記「敵対的モード」テンプレート全文>。最初に `git show --stat --oneline {sha}`（または `git diff --stat {base}..HEAD`）と必要な diff を確認してから始める。'

実行時の共通制約（command プレフィックス、</dev/null、タイムアウト等）は「ルール」を参照。

4. 結果の読み取りと報告

1. まず "$review_out" を読む
2. "$review_out" が空なら失敗扱いにせず、Codex コマンドの stdout / stderr を確認する
3. codex exec review は -o に最終メッセージを書かず、stdout 側にだけレビュー本文を出す場合がある。その場合はコマンド出力からレビュー本文を拾って報告する
4. 出力ファイルにも stdout にもレビュー本文がない（codex が非ゼロ終了・タイムアウトした場合を含む）なら、blind リトライはせず、stderr の内容を添えて失敗をユーザーに報告して終了する
5. 指摘を以下の3カテゴリに分けて報告する:
   • すぐ直すべきもの（バグ、クラッシュ、データ破壊など）
   • 後回しでよいもの（コードスタイル、軽微な改善など）
   • 指摘なし の場合はその旨を報告
6. 敵対的モードのときは上の 3 カテゴリに加えて、「未確認リスク」（codex が発火条件を具体的に示せなかったもの）と**「攻めたが壊せなかった箇所」**を分けて報告する。前者は blind fix せず観測で潰す候補、後者は「安全の証明」ではなく攻め手の記録として扱う（下記「敵対的レビューの作法」参照）
7. 高重大度の指摘があれば、修正するか確認する

5. 一時ファイルの削除

レビュー本文を読み終わってユーザーに報告した 直後に、書き出したばかりの .md ファイル（$review_out）を必ず削除する。tmp/ をレビュー結果のアーカイブ置き場にしない。

rm -f "$review_out"

• 削除はグロブ禁止・完全一致パスのみ。"$d"/*.md / ./tmp/codex-*.log のような glob を rm に渡さない（$d は同じ session のサブエージェントと共有され、並行する他のレビューのファイルを巻き込んで消す事故になる）。消すのは $d/review.$stamp.md（$stamp は date +%Y%m%d-%H%M%S.$$ で PID 込み = セッション一意）の その 1 本だけ
• 🚨 Bash ツールは呼び出しごとに別シェルで、シェル変数 $review_out は次の呼び出しに引き継がれない。安全なのは次のどちらか:
  1. review 実行 → 出力 read → rm -f "$review_out" を 1 回の Bash 呼び出しにまとめる（$review_out がスコープ内に残る。これを既定とする）
  2. 別呼び出しで消すなら、$review_out の リテラル絶対パスをこの会話に控えてから、その完全一致パスを直接 rm -f する。固定名のマーカーファイル（例: ./tmp/.last_review_path）に退避しない（並行セッションが同名で上書きし合い、誤ったパスを消す）
• stderr を別ファイルに採る場合も 同じ $stamp を含む一意名にし、削除はその完全一致パスのみ（*.log glob 禁止）
• 削除対象は今回の実行で作った 1 ファイル（＋一意名の stderr ログ）のみ
• レビュー結果は会話履歴に残しておけば十分で、ファイルを残す必要はない
• 例外的にユーザーが「ファイル残しといて」と明示した場合のみスキップ

敵対的レビューの作法（他スキルから参照される正本）

--adversarial の考え方と指摘の採否ルール。codex-drive / codex-lead / cross-review / review-loop の敵対フェーズはここを正本として参照する（各スキルで別々に定義し直さない）。

原則

• 反証責任を実装側に置く: 「問題が見つからなかった」は「正しい」ではない。不変条件は「壊す方法が見つからなかった」ではなく「壊れないことをテスト/型/設計で固定した」で担保する
• 主張は偽と仮定して当たる: 「対応済み」「検証済み」「テスト green」は主張であって証拠ではない。特に自動生成・エージェント生成の差分では、サマリの主張と diff の実体を必ず突き合わせる
• 自分のテストで自分を証明させない: 循環テスト（自作エンコード↔自作デコード）・常に真のアサーション・実物とずれたモックは「green だが壊れている」を量産する。外部 vector / 実通信 / 別実装との照合で裏を取る
• 壊す条件を具体で書かせる: 「〜の可能性がある」で止めさせない。入力・順序・環境まで下ろせない指摘は仮説であって発見ではない

指摘の採否（Claude 側の検閲。敵対レビューほど無検閲採用が危険）

敵対レビューは通常レビューより false positive と過剰設計の提案が増える。出力をそのまま実装に流さず、次で仕分ける:

1. 発火条件が具体的なもの → コード・契約・実験で裏取りする。再現、または到達可能な経路と契約違反がコードで確認できたら修正対象
2. 再現できなかったもの → 再現しないだけで誤検出と断定しない。契約・到達経路でも確定できなければ未確認として観測を増やす。到達不能や契約との不一致を示せた場合だけ、根拠を付けて却下する
3. 未確認リスク（発火条件が示せないもの） → 修正せず、リスクとして報告 or issue 化する。将来の観測ポイントの候補にする
4. 「起こりえないが念のため」系の提案 → 原則採らない。取るなら「その入力がどこから来るか」を示せた時だけ
5. 壊せなかった報告 → green の根拠にしない（攻め手が浅かった可能性が常に残る）。重要な不変条件はテストで固定して初めて閉じる

subagent-model-tiering.md の「下位主体の出力は main が必ず検閲する」が敵対レビューにもそのまま効く。敵対レビューの結論に敵対するのは Claude の仕事。

自動化向けの出力

• codex-run -J / codex-fanout -J は JSONL のイベント、thread ID、完了/失敗、usage、コマンド実行を保存する。 rc=0 でも完了イベント・最終応答が揃わない run は未完了として集約対象から外す。結果の正しさは引き続き裏取りする。
• 指摘を機械集約する場合は codex-run -J -S <schema.json> ro <prompt-file> を使う。 schema の見本は templates/findings.schema.json。プロンプトで対象 SHA/差分・各指摘の ID・原典/コード根拠・ 発火条件・確認状態 (confirmed / unverified) と未検証範囲を指定する。 exec review の既定の出力形式とは混ぜず、構造化を必要とする場合は通常の read-only exec を選ぶ。
• schema 適合は形式の確認であり、主張の真偽やレビューの網羅性を保証しない。集約時は全指摘 ID の 採用・重複・保留・却下を対応表に残し、失敗 run を「指摘なし」としない。

プロジェクト固有のコンテキスト

Codex はリポジトリ内のコンテキストをある程度拾えるが、重要なプロジェクトルールや今回のレビュー観点は必要に応じてプロンプトに追記する。

ルール

実行時の共通制約の正本（codex-lead スキルもここの command codex / </dev/null / --full-auto 制約を参照する。下記注記を整理・更新するときは codex-lead 側のルールも併せて見直す）。引数パース（selector とプロンプトの併用不可、{base}..{target} の扱い）は「手順 1」、-o が空だった場合の fallback は「手順 4」、出力ファイルの削除は「手順 5」が正本。

• command codex を使うこと（codex 直接呼び出しは zsh 関数オーバーライドでエラーになる場合がある）
• 全ての command codex exec 呼び出しに </dev/null を必ず付ける。Claude Code の Bash ツールの stdin は非TTYのパイプ（書き込み側が開いたまま EOF が来ない）なので、prompt を引数で渡しても codex が「Reading additional input from stdin...」で stdin の EOF を待ち続け、コマンドがタイムアウトまでハングする。</dev/null で stdin を即 EOF にすると解消する（openai/codex#20919）。selector モード・プロンプトモードのどちらでも必要。codex 側が stdin チェックにタイムアウトを実装する等で修正されたら本対処は不要になる
• 常に --ephemeral -o "$review_out" を付与する。通常の exec/fallback の sandbox は -s read-only を明示する（--full-auto は使わず権限を明示する。互換フラグの有無は CLI の版に依存するので、過去の引数エラーを全バージョンに一般化しない）
• codex exec fallback を使う時は -s read-only を付ける
• モデルと effort は -m gpt-6.1-sol -c model_reasoning_effort="high" で明示する。省略すると ~/.codex/config.toml の既定 (対話 TUI 側の都合で変わる) を拾い、実行ごとにモデルが変わる。🚨 effort も省かない — モデルだけ指定すると effort は config.toml の値になる (対話の都合で変わるので、組を固定するのはここ)。codex-drive の「読む run」と同じ組に揃える (ユーザー決定 2026-10-02 で sol、2026-10-03 で effort を medium から high へ。それまでは gpt-6-luna)。high は運用上の既定。特定ベンチマークの優劣や API の価格を個別レビューの精度・5h 枠に一般化しない。effort を変えるときの比較方法は codex-drive のモデル表を参照
• レビュー結果はそのままユーザーに見せる（要約しすぎない）
• /tmp は使わず、出力ファイルは必ず skill-tmpdir codex-review の dir に置く
• codex exec review と codex exec -s read-only はレビュー用途として使い、コードを変更しない
• worktree など別 tree をレビューさせるときは cd する。codex exec review は -C を受け付けない (codex exec -s read-only は取れるので取り違えやすい)。selector を使わない (プロンプト指定の) 実行なら bin/codex-run がこの差分と出力・rc の保存をまとめて引き受ける
• コマンド実行ツールのタイムアウトは 900000ms（15分）に設定する
• 構造的修正優先: 指摘の報告時、修正案は中長期的に改修を続けることを前提とした構造的な方針を優先する。場当たり的な条件分岐やワークアラウンドを修正案として提示しない
• 敵対モードの指摘を無検閲で採用しない: コード・契約・再現で裏取りし、確定できないものは未確認として記録する（「敵対的レビューの作法」が正本）。逆に、敵対モードでない通常レビューでも「指摘なし＝安全」とは報告しない（見つからなかった、と書く）