codex-review

name	codex-review
description	現在のブランチの変更差分をOpenAI Codex CLIにレビューさせ、指摘を検証して妥当なものを修正する。実装完了後のセルフレビューや、ユーザーが「Codexにレビューさせて」と依頼したときに使う。
argument-hint	[比較先ブランチ or 追加のレビュー観点]

Codexレビュー

現在のブランチの変更差分を OpenAI Codex CLI にレビューさせ、指摘を検証したうえで妥当なものを修正するスキル。実装がひと段落したあとのセルフレビューゲートとして使う。

引数($ARGUMENTS)が与えられた場合は「比較先ブランチ」または「追加のレビュー観点」として解釈する。

手順

1. 前提チェック

codex --version を実行し、Codex CLI が使えることを確認する。無ければ以下を案内して中断する(勝手にインストールしない):

• インストール: npm install -g @openai/codex
• 認証: codex login

2. レビュー対象の diff を決める

• 比較先はデフォルトで main(引数で指定があればそれを優先)。merge-base 基準で、未コミットの変更も含める:

  git diff $(git merge-base main HEAD) -- <対象パス>
  

• 対象パスはデフォルトで Assets/AirSticker と Assets/Tests。今回のタスクで意図的に変更した場所(Demo、README など)があればそれも加える。
• ProjectSettings/、Packages/packages-lock.json、.meta・マテリアル等のエディタ churn は対象に含めない(CLAUDE.md「Repo cautions」参照)。
• diff が空なら「レビュー対象の変更がない」と報告して終了する。

3. Codex にレビューを実行させる

レビュープロンプトは複数行になるため、スクラッチパッドの一時ファイルに書き出してから Bash ツールで渡す(timeout は 600000ms):

codex exec --sandbox read-only --output-last-message <スクラッチパッドの結果ファイル.md> "$(cat <プロンプトファイル>)" > /dev/null 2>&1

• --sandbox read-only は必須。Codex はレビュー専任であり、ファイルを書き換えさせない。
• Windows では codex のコンソール出力の日本語が文字化けするため、レビュー結果は必ず --output-last-message でファイルに書かせて Read ツールで読むこと(コンソール出力は捨ててよい)。

プロンプトには以下を含めること:

• 実行してほしい diff コマンド(手順2で決めたもの)そのもの
• 変更の意図の1〜2文の要約(Codex が文脈を誤解しないように)
• レビュー観点:
  • バグ・ロジックエラー・エッジケース
  • ワーカースレッド内から Unity API を呼んでいないか(このリポジトリ最重要。ThreadPool に渡る処理で触れるデータは事前にメインスレッドで収集されている必要がある)
  • スレッド安全性(ワーカースレッドとメインスレッドの共有状態、ポーリングフラグ)
  • プールのライフサイクル(DecalMeshPool / ReceiverObjectTrianglePolygonsPool のエントリ回収漏れ・リーク)
  • パフォーマンス(フレーム分割の破壊、Update 内のアロケーション)
  • ドキュメント変更時: README の EN/JA ペアが同期しているか
• 出力形式: 指摘ごとに severity(blocker/major/minor) / ファイル:行 / 指摘内容 / 根拠 を日本語で。問題がなければ「指摘なし」と明言させる

4. 指摘のトリアージ

Codex の指摘を鵜呑みにしない。各指摘について実際のコードを読んで妥当性を検証し:

• 妥当な指摘 → 修正候補とする(severity・修正方針・既存コード由来かどうかを整理する)
• false positive → 修正候補にせず、却下理由を記録する

5. 修正前にユーザーの確認を取る(必須)

検証で妥当と判断した指摘があっても、確認なしに修正を始めない。

1. まず検証結果(修正候補の指摘/却下した指摘と理由)をテキストで報告する
2. AskUserQuestion で「どの指摘を修正するか」をユーザーに選ばせる
   • multiSelect: true で指摘ごとに選択肢を作る(1問あたり選択肢は4つまで。多い場合は severity の高い順に複数の質問へ分割する)
   • 各選択肢の description に修正方針の要約を書く
3. ユーザーが選択した指摘だけを修正する

6. 収束と報告

修正を行った場合は手順3から再レビューする(往復は最大3回)。再レビューで新たな妥当な指摘が出た場合も、修正前に必ず手順5の確認を挟む。3往復で収束しなければ状況を報告してユーザーの判断を仰ぐ。

最後に以下をまとめて報告する:

• 修正した指摘(何をどう直したか)
• ユーザーが見送りを選択した指摘
• 却下した指摘とその理由