# Codex Review

> 現在のブランチの変更差分をOpenAI Codex CLIにレビューさせ、指摘を検証して妥当なものを修正する。実装完了後のセルフレビューや、ユーザーが「Codexにレビューさせて」と依頼したときに使う。

- Skill: `cyberagentgameentertainment/codex-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add cyberagentgameentertainment/codex-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cyberagentgameentertainment/codex-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: cyberagentgameentertainment (https://skillmd.com/u/cyberagentgameentertainment)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cyberagentgameentertainment/codex-review

---


# 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):

```bash
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往復で収束しなければ状況を報告してユーザーの判断を仰ぐ。

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

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