| 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 を決める
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. 修正前にユーザーの確認を取る(必須)
検証で妥当と判断した指摘があっても、確認なしに修正を始めない。
- まず検証結果(修正候補の指摘/却下した指摘と理由)をテキストで報告する
- AskUserQuestion で「どの指摘を修正するか」をユーザーに選ばせる
multiSelect: true で指摘ごとに選択肢を作る(1問あたり選択肢は4つまで。多い場合は severity の高い順に複数の質問へ分割する)- 各選択肢の description に修正方針の要約を書く
- ユーザーが選択した指摘だけを修正する
6. 収束と報告
修正を行った場合は手順3から再レビューする(往復は最大3回)。再レビューで新たな妥当な指摘が出た場合も、修正前に必ず手順5の確認を挟む。3往復で収束しなければ状況を報告してユーザーの判断を仰ぐ。
最後に以下をまとめて報告する:
- 修正した指摘(何をどう直したか)
- ユーザーが見送りを選択した指摘
- 却下した指摘とその理由
