multi-model-review

マルチモデル・コードレビュー — 3つのAIモデルの固有の強みを活かして多角的にレビュー＆修正を行う。

前提条件

• Codex CLI がインストール済みで、mcp__codex__codex ツール経由（または Codex CLI が MCP サーバーとして利用可能な状態）で呼び出せること。未導入なら Codex CLI を導入・認証しておく。
• Gemini CLI がインストール済みで、gemini コマンドが Bash から実行できること。未導入なら Gemini CLI を導入・認証しておく。
• Codex・Gemini の呼び出しには、それぞれ利用者自身のAPI課金（OpenAI / Google、またはプラン経由の利用枠）が発生する。4並列 Agent（Claude設計 + Codex + Gemini + Claudeセキュリティ）+ 統合フェーズでリクエストがまとまって発生する点に注意。
• Claude 側は Agent（サブエージェント、opus ティア想定）を並列 spawn できる環境であること。

入力

$ARGUMENTS

対象のプロジェクトパスまたはファイルパス。省略時はカレントディレクトリ全体を対象とする。

使用モデル（各モデルの固有の強みに特化）

モデル名は実行時に動的解決する（Phase 0 で取得 → 後続の表示・ログに使用）。固定バージョンをスキル本文に書かない。

実モデルは Agent tool の model 引数および各 CLI のデフォルトに従う（CLI 側でアップデートが入れば自動追従）。スキル側でモデル名をハードコードしない。 Claude 側 Agent の model は既定 "opus"（レビュー系 = opus のモデル運用方針に従う）。セッションがより上位のモデル（Fable 等）で走っていて品質最優先の指示がある場合は、そのティアを model に指定してよい。

エージェントプロンプト

Phase 1 の Agent 1〜4 と Phase 2 の統合エージェントに渡すプロンプト原文は references/agent-prompts.md にある。Phase 1 の spawn 前に必ず Read し、 【プロジェクトパス】【ファイルリスト】【diff 内容】 を Phase 0 の取得値で差し替えて使う。

ワークフロー

Phase 0: 対象の特定 + モデル解決

1. git diff で変更ファイルを特定する（未コミットの変更がある場合）
2. 変更がない場合は git diff HEAD~1 で直近コミットの差分を対象とする
3. 対象ファイルのリストと差分内容を取得する
4. プロジェクトのリンター設定（ESLint / Biome / etc.）を確認する
5. 取得した ファイルリスト、diff 内容、プロジェクトパス を変数として保持する

6. モデル解決（最新版を実行時に取得）

スキル冒頭で以下を組み立てる。後続のフェーズはこの値だけを使う。

• CLAUDE_MODEL_ID / CLAUDE_DISPLAY — assistant の現在モデルID（システムプロンプト記載）をそのまま採用する。 表示名は ID から無理に整形せず、整形できない形式なら ID 原文を表示に使う（ID の命名形式はモデル世代で変わるため、sed 等の固定パターン変換に依存しない）。
• Codex / Gemini は CLI から取得:

CODEX_VERSION="$(codex --version 2>/dev/null | head -1 || echo 'unknown')"
CODEX_MODEL="$(codex config get model 2>/dev/null || echo 'default')"
CODEX_DISPLAY="Codex ${CODEX_VERSION} (${CODEX_MODEL})"

GEMINI_VERSION="$(gemini --version 2>/dev/null | head -1 || echo 'unknown')"
GEMINI_MODEL="$(gemini -p 'Reply with only your model name and version, one line.' 2>/dev/null | head -1 || echo 'default')"
GEMINI_DISPLAY="Gemini CLI ${GEMINI_VERSION} (${GEMINI_MODEL})"

取得失敗時は "（latest）" の文字列でフォールバックする。最新モデル名がわからなくても処理は続行する。

Phase 1: マルチモデル並列レビュー（4並列）

4つの Agent を同時に spawn する。 すべて読み取り専用で、修正は行わない。 各モデル/専門は そのモデルにしかできないこと に集中する。 プロンプト原文はすべて references/agent-prompts.md の該当セクションを使う。

Agent 1: Claude 最上位 — 設計・ロジック（深い推論）

「設計意図を理解し、動くけど設計として問題があるコード」を見抜く役。 セキュリティは Agent 4（セキュリティ専門）に委譲し、本エージェントは設計とロジックに集中する。

Agent設定:
  description: "opus-design-review"
  model: "opus"（Phase 0 の方針でティア引き上げ可）
  mode: "auto"
プロンプト: references/agent-prompts.md「Agent 1: Opus — 設計・ロジック」

Agent 2: Codex — 実行ベースのバグ検出（コード実行可能）

Codex の唯一の差別化点「サンドボックスでコードを実際に実行して検証できる」を活かす。

Agent設定:
  description: "codex-runtime-review"
  mode: "auto"
プロンプト: references/agent-prompts.md「Agent 2: Codex — 実行ベースのバグ検出」
  （mcp__codex__codex を read-only / approval-policy: never で呼ぶ内容）

Agent 3: Gemini — リポジトリ全体のクロスファイル影響分析（巨大コンテキスト）

Gemini の唯一の差別化点「リポジトリ全体を一度に投入してクロスファイル分析できる」を活かす。

Agent設定:
  description: "gemini-crossfile-review"
  mode: "auto"
プロンプト: references/agent-prompts.md「Agent 3: Gemini — クロスファイル影響分析」
  （Bash で `gemini -p "..." --sandbox` を実行する内容）

Agent 4: Claude 最上位 セキュリティ専門 — OWASP・シークレット・認可・暗号・依存脆弱性

セキュリティ監査だけに集中する独立エージェント。Agent 1（設計）とは責務を完全に分離する。 これにより設計レビューがセキュリティを薄く広く触る形になるのを避け、深い脅威モデリングを行う。

Agent設定:
  description: "opus-security-review"
  model: "opus"（Phase 0 の方針でティア引き上げ可）
  mode: "auto"
プロンプト: references/agent-prompts.md「Agent 4: Opus — セキュリティ専門監査」

Phase 1 の4エージェントはすべて並列実行する。

Phase 2: 統合・トリアージ・修正

Phase 1 の4エージェントの結果がすべて揃ったら、1つの Claude 最上位 Agent を spawn する。

Agent設定:
  description: "opus-consolidate-fix"
  model: "opus"（Phase 0 の方針でティア引き上げ可）
  mode: "auto"
プロンプト: references/agent-prompts.md「Phase 2: 統合・トリアージ・修正」
  （【Agent N の結果】を Phase 1 の実結果で差し替える）

統合エージェントの責務（詳細はプロンプト原文）:

1. 重複排除 + クロスバリデーション（複数エージェント一致 → severity 1段階UP）
2. セキュリティ critical 最優先で severity 順に修正実行（Edit ツール使用）
3. シークレット混入時はコード除去 + ローテーション要と記録（git 履歴に残るため）
4. 統合結果レポート（指摘数・修正数・スキップ数・セキュリティ結論）を返す

Phase 3: 最終検証（Claude 最上位 + リンター + セキュリティスキャナ）

Phase 2 の修正後、同じエージェントの結果を受けて以下を実行する。

1. リンター実行: プロジェクトに ESLint / Biome / etc. があれば Bash で実行し、修正がスタイルルールに違反していないか確認
2. 依存脆弱性スキャン: パッケージマネージャの audit を実行（プロジェクト構成に応じて）
3. シークレット最終スキャン: 修正後の差分にシークレットが残っていないか機械的に再確認
4. 自己レビュー: 修正後のコードを Read で読み、修正が新たなバグやセキュリティ後退を入れていないか確認

リンター実行:

# プロジェクトに応じて適切なリンターを実行
npx eslint 【修正ファイルリスト】 2>&1 || true
# または
npx biome check 【修正ファイルリスト】 2>&1 || true

依存脆弱性スキャン（プロジェクトに応じて選択）:

# Node.js
npm audit --audit-level=high 2>&1 || true
# Python
pip-audit 2>&1 || true
# Go
govulncheck ./... 2>&1 || true
# Ruby
bundle audit check --update 2>&1 || true

シークレット最終スキャン:

# 利用可能なら gitleaks 推奨。なければ最低限の grep でフォールバック
command -v gitleaks >/dev/null && gitleaks protect --staged --no-banner 2>&1 || \
  git diff --cached -U0 | grep -EHin "(api[_-]?key|secret|token|password|BEGIN [A-Z]+ PRIVATE KEY)[\"'\\s:=]" -i || true

リンター/audit/シークレット検知でエラーがあれば修正する。critical な脆弱性（既知CVE/シークレット混入）は必ず解消してから Phase 4 に進む。

Phase 4: 最終レポート出力

すべての Phase の結果を集約して報告する：

🏆 マルチモデル・コードレビュー完了

━━━ 使用モデル & 役割 ━━━
  🔷 ${CLAUDE_DISPLAY} (設計)     → アーキテクチャ・ロジック・型・エラー処理
  🟠 ${CODEX_DISPLAY}             → 実行ベースのバグ検出 + 動的セキュリティ検証
  🟢 ${GEMINI_DISPLAY}            → クロスファイル影響分析 + 設定/依存俯瞰
  🛡️ ${CLAUDE_DISPLAY} (Security) → OWASP・シークレット・認可・暗号・依存脆弱性

━━━ Phase 1: 並列レビュー結果 ━━━
  Claude設計: X件（設計: X / ロジック: X / 型: X / エラー: X）
  Codex:      X件（実行時バグ: X / 動的セキュリティ: X / テスト失敗: X）
  Gemini:     X件（依存破壊: X / API契約: X / 設定漏れ: X / シークレット混入: X）
  Security:   X件（OWASP: X / シークレット: X / 認可: X / 暗号: X / 依存脆弱性: X）

━━━ Phase 2: 統合・修正 ━━━
  全指摘: X件（重複排除後）
  クロスバリデーション一致: X件
  修正: X件 / スキップ: X件

━━━ 🔒 セキュリティ・サマリー ━━━
  結論: ❌ 修正必須 / ⚠️ 要対応推奨 / ✅ 問題なし
  critical: X件 / warning: X件 / info: X件
  シークレット混入: あり (X件) / なし
  ⚠️ ローテーション要否: 該当キー/トークン/秘密鍵をリストアップ（git履歴に残るため必須）
  既知CVE: X件（npm audit / pip-audit / govulncheck より）

━━━ Phase 3: 検証 ━━━
  リンター: PASS / X件修正
  依存脆弱性スキャン: PASS / X件のCVE
  シークレットスキャン: クリーン / X件検出
  自己レビュー: PASS / X件追加修正

━━━ 修正ファイル一覧 ━━━
  - file1: 修正概要
  - file2: 修正概要

━━━ クロスバリデーション（複数エージェントが一致した指摘） ━━━
  - [Claude設計 + Security] file:line — 説明
  - [Codex + Security] file:line — 説明（動的検証で確認されたセキュリティ問題）
  - [Claude設計 + Gemini] file:line — 説明
  - [Codex + Gemini] file:line — 説明

設計思想

各エージェントが「そのエージェントにしかできないこと」だけをやる

• Claude 設計: 他モデルより推論力が高い → 「動くけど設計として問題」を見抜く
• Codex: 唯一コードを実行できる → 静的分析では見つからない実行時バグ + 動的セキュリティ検証
• Gemini: 最大のコンテキスト → リポジトリ全体を投入してファイル間の影響・設定漏洩を分析
• Claude セキュリティ: 専門知識ベースの脅威モデリング → OWASP/CWE/シークレット/暗号/依存脆弱性

設計とセキュリティを別エージェントに分離する理由：1つのエージェントに「設計もセキュリティも見て」と依頼すると、両方を浅く広く触る形になり、深い脅威モデリングが行われない。 独立したセキュリティ専門エージェントを置くことで、攻撃者視点の深い監査と、設計者視点の深い構造分析が両立する。

クロスバリデーションの信頼度

異なるモデルファミリー（Anthropic / OpenAI / Google）または異なる専門（設計 / セキュリティ）が同じ問題を独立に指摘した場合、それは高確率で本物の問題。 特に「Codex の動的検証 + Claude セキュリティの静的分析」が一致したセキュリティ問題は確証度が極めて高い。

注意

• Phase 1 の spawn 前に references/agent-prompts.md を Read する（プロンプト原文はそこにしかない）
• Phase 1 の 4エージェントは必ず並列実行 する（Claude設計 / Codex / Gemini / Claudeセキュリティ）
• Phase 2 は Phase 1 の全結果が揃ってから順次実行する
• Codex は mcp__codex__codex で呼び出す（read-only / approval-policy: never）
• Gemini CLI は gemini -p "..." --sandbox で Bash 実行する
• Phase 3 のリンター・依存 audit・シークレットスキャナは、プロジェクト言語/構成に応じて適切なものを選択する
• シークレット混入が見つかった場合は単に削除するだけでなく、最終レポートで「該当キー/トークンのローテーション要否」を必ず明示する（git履歴に残るため）
• Phase 3 で critical な脆弱性（既知CVE / シークレット混入 / 既知の認可バイパス）が残っている場合は Phase 4 に進む前に必ず修正
• Phase 3 で問題がなければ追加修正なしで Phase 4 へ進む