| name | codex-consultant |
| context | fork |
| description | Codex CLI (OpenAI gpt-5.4) に直接相談するスキル。設計判断・実装方針・コードレビュー・デバッグ方針など、別モデルの視点が欲しい時に使用する。「codexに相談」「codexに聞いて」「別の視点が欲しい」「セカンドオピニオン」「codexでレビュー」「codexとペアプロ」「codexとTDD」「codexでペアプログラミング」「ペアプロモード」「adversarial review」と言った時にトリガーする。 |
Codex Consultant
Codex MCP (gpt-5.4, reasoning: xhigh) に直接相談し、セカンドオピニオンを得る。
モード選択ガイド
基本相談
使い方
mcp__codex__codex ツールを呼び出す:
mcp__codex__codex(
prompt: "<質問・相談内容>",
# 固定パラメータ（下表「固定パラメータ」参照）: model, config.model_reasoning_effort
)
ファイルコンテキスト付き相談
ファイルパスを指定し、Codex自身に読ませる（path-first方式）:
mcp__codex__codex(
prompt: "以下のファイルを読んで<質問>に答えてください。
対象ファイル: src/module.ts
指摘は file:line 形式で記述してください。",
cwd: "<絶対パス形式のプロジェクトルート>",
# 固定パラメータ（下表参照）: model, config.model_reasoning_effort
)
cwd は必ず絶対パスで指定（例: /Users/name/projects/my-app）- ファイルパスは
cwd からの相対パスで列挙
セッション継続（マルチターン）
同じトピックで深掘りする場合、前回の threadId を使って会話を継続:
# 初回: 新規セッション開始
mcp__codex__codex(
prompt: "<初回の質問>",
# 固定パラメータ（下表参照）: model, config.model_reasoning_effort
)
# → レスポンスから threadId を取得
# 継続: threadId を指定して会話を再開
mcp__codex__codex-reply(
threadId: "<取得したthreadId>",
prompt: "<フォローアップの質問>"
)
コードレビュー
git diff で差分を取得し、Codex に渡してレビューを依頼する:
# 1. Bash ツールで差分を取得
git diff # 未コミットの変更
git diff main...HEAD # 特定ブランチとの差分
# 2. 差分を Codex に渡してレビュー
mcp__codex__codex(
prompt: "以下の差分をコードレビューしてください。設計上の問題点、バグの可能性、改善案を指摘してください。\n\n<diff出力>",
cwd: "<プロジェクトルート>",
# 固定パラメータ（下表参照）: model, config.model_reasoning_effort
)
# カスタム観点でのレビュー
mcp__codex__codex(
prompt: "セキュリティ脆弱性に注目して以下の差分をレビューしてください。\n\n<diff出力>",
cwd: "<プロジェクトルート>",
# 固定パラメータ（下表参照）: model, config.model_reasoning_effort
)
レビュー+修正モード
指摘だけでなく、修正可能なものはCodexにその場で直させる場合:
mcp__codex__codex(
prompt: "以下の差分をコードレビューし、バグや明確な問題は対象ファイルを読んだ上でその場で修正してください。設計上の問題は指摘のみ行ってください。差分に含まれるファイル以外は編集しないでください。修正した箇所は file:line 形式で報告してください。\n\n<diff出力>",
cwd: "<絶対パス形式のプロジェクトルート>",
# 固定パラメータ（下表参照）: model, config.model_reasoning_effort, sandbox, approval-policy
)
自動実行モード
コード変更を伴う作業を Codex に依頼する場合:
mcp__codex__codex(
prompt: "<変更指示>",
cwd: "<プロジェクトルート>",
# 固定パラメータ（下表参照）: model, config.model_reasoning_effort, sandbox, approval-policy
)
ペアプログラミングモード
Mode A: Driver/Navigator
一方が実装（Driver）、他方がレビュー・方向付け（Navigator）を担当する。
パターン1: Claude=Driver / Codex=Navigator（デフォルト）
Claudeが実装し、ユーザーの要件に基づきコードを書いた後、Codexにレビュー依頼する:
mcp__codex__codex(
prompt: "Navigatorとしてレビューしてください。以下のファイルを読み、
- 設計上の問題点
- エッジケースの見落とし
- より良い代替案
を指摘してください。指摘は file:line 形式で。
対象ファイル: src/feature.ts
要件: <要件の要約>",
cwd: "<絶対パス形式のプロジェクトルート>",
# 固定パラメータ（下表参照）: model, config.model_reasoning_effort
)
指摘を取り込んで修正した後、必要に応じて再レビューする:
mcp__codex__codex-reply(
threadId: "<前回のthreadId>",
prompt: "修正しました。対象ファイルを再読込して再レビューをお願いします。
修正ファイル: src/feature.ts"
)
パターン2: Codex=Driver / Claude=Navigator
Codexが実装し、Claudeがレビュー・方向付けする。
Codexに実装依頼:
mcp__codex__codex(
prompt: "以下の要件を実装してください:
<要件の詳細>
制約:
- <技術的制約>
- <アーキテクチャの方針>",
cwd: "<プロジェクトルート>",
# 固定パラメータ（下表参照）: model, config.model_reasoning_effort, sandbox, approval-policy
)
生成されたコードの品質・設計をClaudeがレビューし、修正指示をCodexに送信する:
mcp__codex__codex-reply(
threadId: "<前回のthreadId>",
prompt: "以下の点を修正してください:
- <修正点1>
- <修正点2>"
)
Mode B: Ping-Pong TDD
テストと実装を交互に書く。RED→GREEN→REFACTORサイクルを回す。
パターン1: Claude=テスト / Codex=実装（デフォルト）
- RED: 要件に基づき失敗するテストを作成
- GREEN: Codexに実装を依頼
mcp__codex__codex(
prompt: "以下のテストファイルを読み、テストを通す最小限の実装を書いてください。テスト以外の変更は不要です。
テストファイル: tests/feature.test.ts",
cwd: "<絶対パス形式のプロジェクトルート>",
# 固定パラメータ（下表参照）: model, config.model_reasoning_effort, sandbox, approval-policy
)
- テスト実行で通過を確認
- REFACTOR: 重複除去・設計改善
- 次のテストを追加し、ステップ2（GREEN）に戻る
パターン2: Codex=テスト / Claude=実装
- RED: Codexにテスト作成を依頼
mcp__codex__codex(
prompt: "以下の要件に対するテストを書いてください。実装は書かないでください。
要件: <要件>
テストファイル: <テストファイルパス>
テストフレームワーク: <jest/vitest/pytest等>",
cwd: "<プロジェクトルート>",
# 固定パラメータ（下表参照）: model, config.model_reasoning_effort, sandbox, approval-policy
)
- GREEN: テストを通す最小限のコードを書く
- テスト実行で確認
- REFACTOR: リファクタリング
- 次のREDをCodexに依頼
mcp__codex__codex-reply(
threadId: "<前回のthreadId>",
prompt: "テストが通りました。次の要件のテストを追加してください:
- <次の要件>"
)
Mode C: Adversarial Review
実装後にCodexが攻撃的なテスト・レビューを行い、堅牢性を高める。
フロー
- 通常通り実装する
- Codexに破壊テスト+修正を依頼
mcp__codex__codex(
prompt: "以下のファイルを読み、攻撃的レビューを行ってください:
対象ファイル: src/auth/handler.ts, src/auth/middleware.ts
観点:
- 異常入力・境界値で壊れるケース
- セキュリティ脆弱性（インジェクション、認可漏れ等）
- 競合状態・デッドロックの可能性
- リソースリーク・メモリ問題
- エラーハンドリングの不備
致命的な問題（セキュリティ脆弱性、データ破壊等）は対象ファイルを読んだ上で直接修正してください。設計レベルの問題は指摘のみ行ってください。対象ファイル以外は編集しないでください。
具体的な攻撃ケース（入力例やシナリオ）を提示してください。
修正・指摘は file:line 形式で記述してください。",
cwd: "<絶対パス形式のプロジェクトルート>",
# 固定パラメータ（下表参照）: model, config.model_reasoning_effort, sandbox, approval-policy
)
- 設計レベルの指摘を修正し、Codexによる修正の品質をレビューする
- 再攻撃
mcp__codex__codex-reply(
threadId: "<前回のthreadId>",
prompt: "以下の修正を行いました。修正ファイルを再読込して再度攻撃してください。新しい攻撃ベクトルも試してください。
修正ファイル: src/auth/handler.ts
修正概要: <修正内容の要約>"
)
- 新しい脆弱性が見つからなくなるまで3-4を繰り返す
ファイル参照の原則
Codexはエージェントとしてファイル読み取り能力を持つため、path-first（パス指定でCodex自身に読ませる）を基本とする。
path-first（デフォルト）
- ファイルレビュー、コード相談、ペアプロ、Adversarial Review
cwd は毎回絶対パスで指定（例: /Users/name/projects/my-app）- ファイルパスは
cwd からの相対パスで列挙
- 指摘は
file:line 形式を要求
- Codexがファイルを読めなかった場合は即報告させる
inline（例外）
- git diff、CIログ、例外スタックトレース等、ファイルとして存在しない情報
- コードレビューセクションの diff はこの方式
相談パターン
| パターン | プロンプト構成 |
|---|
| 設計判断 | 要件 + 選択肢 + トレードオフの質問 |
| デバッグ | エラー内容 + 関連コード + 試したこと |
| コードレビュー | git diff + レビュー観点 |
| リファクタリング | 現状コード + 改善方針の相談 |
| アーキテクチャ | 現構造 + 要件変化 + 方針相談 |
固定パラメータ
| パラメータ | 値 | 説明 |
|---|
| model | gpt-5.4 | 常に指定 |
| config.model_reasoning_effort | xhigh | 常に指定 |
| cwd | プロジェクトルート | ファイルアクセスが必要な場合に指定 |
| sandbox | workspace-write | コード変更を伴う場合に使用 |
| approval-policy | on-failure | コード変更を伴う場合に使用 |
注意事項
- Codexの回答は参考意見として扱い、最終判断はClaudeが行う
- ファイル参照は path-first を基本とし、promptにコードを埋め込まない（「ファイル参照の原則」参照）
mcp__codex__codex-reply で threadId を指定し、文脈を維持した深い議論が可能- ペアプロモードでは各ラウンドの成果を要約してユーザーに報告する
