| name | codex-review |
| description | OpenAI Codex を MCP 経由（mcp__codex__codex）で呼び出し、セカンドオピニオンとしてコードレビュー・調査をさせるスキル。引数がなければ現在のリポジトリの変更（staged/unstaged含む）またはdefault branchとの差分をレビューさせ、引数（テーマ・ファイル・バグの症状など）があればそれについて調査・レビューさせる。観点は保守性・テスト十分性・spec適合・実装の筋の良さなど。ユーザーが「codexでレビューして」「codexに見てもらって」「codexで調べて」「別のモデルの意見も欲しい」「セカンドオピニオン」と言ったとき、あるいは自分のレビューを別視点で裏取りしたいときに使う。トリガー: codex-review, codexレビュー, codexで見て, /codex-review |
| allowed-tools | Read, Bash, Grep, Glob, AskUserQuestion, mcp__codex__codex, mcp__codex__codex-reply |
Codex コードレビュースキル
OpenAI Codex を MCP 経由（mcp__codex__codex）で呼び出し、コードレビューや調査を「別のモデルの目」で実施させるスキル。
Claude 自身がレビュー対象（差分／調査テーマ）を確定し、観点を添えた依頼文を組み立てて Codex に渡す。Codex は read-only サンドボックスでリポジトリを自分で読み、レビュー結果を返す。
自分（Claude）がレビューを書くのではなく、Codex にレビューさせて、その結果をユーザーに橋渡しするのが役割。セカンドオピニオン用途を想定している。
呼び出しモードの判定
引数の有無で対象が変わる。
| 状況 | Codex にさせること |
|---|
| 引数なし | 現在のリポジトリの変更差分のコードレビュー（下記「差分の確定」で対象を決める） |
| 引数あり | 引数で示されたテーマの調査・レビュー（例: 「認証まわりを見て」「このバグの原因」「foo.go のリファクタ案」「N番目のPRの妥当性」） |
引数があるのに対象が曖昧で、かつ判断が結果を大きく左右する場合のみ AskUserQuestion で確認する。基本は決めて進め、冒頭で「〜を対象に依頼しました」と明示する。
進め方
Step 1: 対象の確定
引数なし（差分レビュー）の場合、まず判断材料を集める：
git rev-parse --show-toplevel
git branch --show-current
git status --porcelain
git log --oneline -10
git symbolic-ref --quiet refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@'
差分対象の確定ロジック：
| 状況 | レビュー対象 |
|---|
| feature branch にいる | default branch との merge-base からの差分（ブランチの仕事全体）＋未コミットの staged/unstaged |
| default branch (main/master) にいて未コミット変更がある | staged + unstaged の変更 |
| 引数やユーザー指示で範囲が明示されている | それに従う（特定コミット範囲、特定ファイルなど） |
差分の規模と対象コミット範囲を把握しておく（Codex への依頼文に具体的な git 参照を書くため）：
BASE=$(git merge-base HEAD origin/main 2>/dev/null || git merge-base HEAD main 2>/dev/null)
git --no-pager diff --stat "$BASE"...HEAD
git --no-pager diff --stat HEAD
引数あり（調査・レビュー）の場合、リポジトリルート（git rev-parse --show-toplevel）だけ押さえ、テーマをそのまま Codex への依頼に落とす。差分に限定しない全体調査になることが多い。
Claude 側で差分の中身まで精読する必要はない。対象範囲を正しく Codex に伝えることが仕事。ただし範囲判定に必要な git 情報は必ず自分で確認する（Codex に丸投げすると別ブランチ基準でレビューしかねない）。
Step 2: Codex への依頼文を組み立てる
mcp__codex__codex を次の設定で呼ぶ：
sandbox: "read-only" — 読み取り専用。Codex にファイルを書き換えさせないcwd: Step 1 で取得したリポジトリルートの絶対パスapproval-policy: "never" — 対話的な承認を挟まず最後まで実行させるprompt: 下記テンプレートに沿って、対象範囲＋観点を明記した依頼文
依頼文には必ず以下を含める：
- 対象範囲の明示 — 引数なしなら確定した git 参照（例: 「
<BASE> と HEAD の差分、および未コミットの変更」）、引数ありならそのテーマ
- 観点（下記「レビュー観点」を要約して渡す）
- プロジェクト固有ルールを尊重せよという指示 —
CLAUDE.md / .claude/rules/ を読んで最優先の評価基準として扱うこと
- 出力形式の指定 — 深刻度（Must-fix / Should-fix / Consider）で整理し、各指摘に
file:line・根拠・提案・確信度を付けること。良い点も少数挙げること
依頼文テンプレート（引数なし・差分レビュー）
あなたはこのリポジトリのコードをレビューするシニアエンジニアです。以下の変更を、プロのレビュアーとして評価してください。
## レビュー対象
<BASE> と HEAD の差分（ブランチの仕事全体）、および未コミットの staged/unstaged 変更。
まず `git diff <BASE>...HEAD` と `git diff HEAD` で差分を確認し、変更されたファイルは全体・呼び出し元・呼び出し先も読んで文脈を把握してから評価すること。差分の行だけを見て指摘しないこと。
## 最優先の評価基準
リポジトリ直下および .claude/ にある CLAUDE.md / .claude/rules/ を読み、そこに書かれたプロジェクト固有ルールを最優先の評価基準として扱うこと。違反は明確な指摘対象。
仕様がある場合（.spec/{slug}/spec.md, .cckiro/issues/, docs/ など）は設計意図（設計の心）を継いでいるかを見る。一字一句の一致は求めない。
## 観点
1. 長期的な保守性・抽象化: DRY違反やコピペ、逆に過剰抽象化。責務分離。命名・構造だけで意図が読めるか
2. テストの十分性: 期待動作・異常系・境界値を担保するテストがあるか。実装に密結合した脆いテストでないか。外部サービス/時刻/乱数に依存する処理はモックだけでは保証にならない旨も見る
3. spec適合（設計の心）: 逸脱があれば合理的な逸脱か見落とし・手抜きかを判断
4. 実装の筋の良さ: その言語のイディオム・新しめの機能の適切な利用、エラーハンドリング作法、並行性・リソース管理
5. その他（該当時のみ）: 明確なバグ、セキュリティ、API公開範囲、マルチインスタンス安全性、後方互換、観測性、ドキュメント更新
## 姿勢
- 粗探しではなく本質的な指摘を少数精鋭で。重大な問題は遠慮なく指摘する
- 各指摘に「なぜそう思うか」と具体的な代替案を必ず添える
- 確信度が低い指摘は「意図的かもしれないが」と前置きする
- 良い設計判断は明示的に評価する
## 出力形式
深刻度で整理し、各指摘に file:line・問題・なぜ・提案・確信度（高/中/低）を付ける。
- 🔴 Must-fix / 🟡 Should-fix / 🟢 Consider の3段階
- 冒頭に「何を対象にレビューしたか」を1行。良い点も数点。
- 指摘がゼロの深刻度は見出しごと省く。無理に指摘を水増ししない
依頼文テンプレート（引数あり・調査/レビュー）
引数のテーマを「## 依頼」に据え、上記の観点・姿勢・出力形式を流用する。差分に限定せず、テーマに関係するコードを Codex 自身に探索させる。
あなたはこのリポジトリを調査するシニアエンジニアです。以下の依頼に答えてください。
## 依頼
<ユーザーの引数（テーマ／バグの症状／対象ファイル／調査してほしいこと）をそのまま／整理して記載>
関係するコードを自分で探索して読み、根拠（file:line）とともに答えること。
## 最優先の評価基準・観点・姿勢・出力形式
（差分レビュー版と同じ。CLAUDE.md/.claude/rules を尊重、観点1〜5、根拠と代替案を添える、深刻度で整理）
Step 3: Codex を実行し、必要なら追撃する
mcp__codex__codex を呼ぶ。応答が浅い・対象を取り違えている・追加で掘りたい点がある場合は、返ってきた threadId（または conversationId）を使って mcp__codex__codex-reply で追撃する（例: 「観点2のテストについてもう少し具体的に」「そのファイルの◯◯関数も見て」）。
Step 4: 結果をユーザーに報告
Codex の出力を、ユーザーが読みやすい形で提示する。
- Codex の指摘であることを明示する（自分の意見と混同させない）。「Codex のレビュー結果」として提示する
- 冒頭に「何を対象に Codex へ依頼したか」を1行。範囲の取り違えを防ぐ
- Codex の出力が冗長・散漫なら要点を整理してよいが、指摘の内容を勝手に取捨選択して握りつぶさない。全部出すのが基本
- ユーザーに求められれば、Codex の指摘に対する自分（Claude）の見解（同意/保留/反論）を添える。ただし求められるまでは Codex の結果の橋渡しに徹する
やらないこと
- コードの修正そのもの。 これはレビュー・調査スキル。Codex にも read-only で実行させる。修正が要るなら指摘を提示した上でユーザーの指示を待つ
- Codex の指摘の勝手な取捨選択・改変。 要約はしてよいが、内容を歪めたり握りつぶしたりしない
- PR のレビューコメント対応。 それは
/check-pr の役割
- Claude 単独でのレビュー。 それが欲しい場合は
my-code-review を使う。本スキルは Codex に投げるのが本質
