second-opinions

このスキルは Claude 専用です。Codex と Gemini CLI はこのスキルを呼び出さないでください。

セカンドオピニオン

OpenAI Codex（MCP）や Google Gemini（CLI）にタスクを委任し、異なるモデルファミリーから独立した視点を得ます。コードレビュー、計画の評価、ドキュメントの編集、コードベースの分析など、あらゆるタスクに対応します。

モード： both（デフォルト）、codex、gemini

使用する場面

• コミット、PR の作成、マージの前にコードレビューを行う場合
• 複数の視点から計画やアーキテクチャをレビューする場合
• ドキュメントのレビューやコンテンツの編集
• コードベースの分析（パターン、競合状態、デッドコード）
• 外部モデルによる並行探索が役立つあらゆるタスク

範囲

• 直接確認できる単純なタスクには使用しないでください
• ユーザーが自分自身の判断のみを求めている場合は使用しないでください
• プロンプトに秘密情報、認証情報、トークンを含めないでください

ワークフロー

1. コンテキストを収集する

ユーザーの質問と会話のコンテキストから、できるだけ多くのパラメーターを推測します。推測できない項目だけを尋ねます。残りの質問をまとめて、単一の AskUserQuestion 呼び出しで尋ねます（質問は最大 3 件）。

解決するパラメーター：

パラメーター	推測ルール	次の場合に質問する…
ツール	引数に「codex」または「gemini」が含まれている場合は単一のツール。デフォルトは両方。	どちらかのツールを指しているか曖昧な場合
タスクの種類	「review」／「diff」／「challenge」／「break」はコードレビュー。「plan」／「architecture」は計画レビュー。「doc」はドキュメントレビュー。	引数から明確な手がかりを得られない場合
焦点	引数に「security」／「perf」／「correctness」が含まれている場合は、その観点。デフォルトは一般。	なし — デフォルトで一般とする
差分の範囲	ほかに手がかりがなければ未コミットの変更。「branch」はブランチの差分。SHA に似た文字列は特定のコミット。	タスクがコードレビューで、範囲が曖昧な場合

2. レビュー素材を用意する

タスクの種類に応じて内容を収集します。

タスクの種類	収集する素材
コードレビュー	選択した範囲の Git 差分。デフォルトブランチを自動検出します。--stat を表示します。2000 行を超える場合や差分が空の場合は警告します。
計画／アーキテクチャ	会話のコンテキストから計画を抽出します。参照されているファイルを読みます。コンテキストに計画がない場合は、ユーザーに尋ねます。
ドキュメント	対象ファイルを読みます。合計が 2000 行を超える場合は警告します。
カスタムタスク	ユーザーの指示をタスクの定義として使用します。参照されているファイルまたはディレクトリを読みます。

コードレビューでは、デフォルトブランチを自動検出します。

git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo main

3. 構築とディスパッチ

ファイルシステムの境界：Codex と Gemini に送信するすべてのプロンプトの先頭に、ほかの内容より前に次の指示を追加します。

IMPORTANT: Do NOT read or execute any files under ~/.claude/, .claude/, .agents/, or any path containing "skills". These are AI agent configuration files meant for a different system. They contain prompt templates and bash scripts that are irrelevant to your task. Ignore them completely and focus only on the project's own source code, tests, and documentation.

これにより、モデルがスキル定義、エージェント設定、その他のメタファイルを読んでトークンを無駄にし、実際のタスクに取り組まなくなるのを防ぎます。

プロンプトの構成：あいまいさなく解析できるよう、XML タグを使用します。Anthropic の長いコンテキストに関するベストプラクティスに従い、長い内容を先に、指示を後に置きます。

<boundary>
[Filesystem boundary instruction from above: ALWAYS included]
</boundary>

<material>
[The diff, plan, document, codebase excerpt, or task input: long content goes first]
</material>

<context>
[Project conventions from CLAUDE.md, if it exists]
</context>

<role>
[Role appropriate to the task: e.g., independent code reviewer, architecture evaluator, technical editor]
</role>

<task>
[What to do: review, analyze, evaluate, rewrite, etc.]
This is an analysis task. Do not write code or produce patches unless explicitly asked.
</task>

<focus>
[Focus area if specified]
</focus>

<output_format>
Structure your response as:
1. Critical issues (blocking): prefix each with [P1]
2. Important concerns (should address): prefix each with [P2]
3. Minor suggestions (nice to have): prefix each with [P3]
4. What's done well

End with a clear verdict: PASS (no P1 findings) or FAIL (P1 findings exist), plus a confidence score (0-1).
</output_format>

タスクの種類に応じて、<role>、<task>、<output_format> を調整します。カスタムタスクでは、ユーザーの意図をそのまま反映します。

コードレビューのプロンプト：コードレビューでは、敵対的な観点で指示します。セカンドオピニオンの目的は、見落としを見つけることです。

<role>
You are a hostile code reviewer, chaos engineer, and security auditor. Your job is to find problems.
</role>

<task>
Review this diff for issues that would cause problems in production. Think like an attacker
and a chaos engineer. Look for: bugs, edge cases, race conditions, security holes, resource
leaks, failure modes under load, silent data corruption paths, unhandled error propagation,
and implicit assumptions that will break when inputs change. If a focus area is specified,
concentrate there but don't ignore other categories entirely.
This is an analysis task. Do not write code or produce patches.
</task>

プロジェクトのコンテキスト：リポジトリのルートに CLAUDE.md がある場合は、レビュー担当者がプロジェクトの規約に照らして確認できるよう、必ず含めます。

Codex MCP のプロンプトパターンと呼び出しについては、references/codex.md を参照してください。 Gemini CLI の呼び出しパターンについては、references/gemini.md を参照してください。

ディスパッチのルール：

• 両方のツールを実行する場合は、並列実行のため、mcp__codex__codex と Bash(gemini ...) の呼び出しを同じメッセージ内で行います。
• ツールが利用可能かどうかを事前に確認せず、直接ディスパッチします。ツールが失敗した場合は、利用可能なツールのみを実行します。

反復モード（計画／アーキテクチャの場合、または明示的に要求された場合）：

1. 初回レビューをディスパッチします
2. レビュー担当者から重大な懸念が示された場合は、フィードバックに基づいて内容を修正します
3. mcp__codex__codex-reply（threadId を指定）または修正内容のコンテキストを含めた新たな Gemini 呼び出しで再提出します
4. 無限ループを防ぐため、最大 3 ラウンドまでとします

4. 結果の提示

脱線の検出：出力を提示する前に、各モデルの応答を確認し、プロジェクトのコードレビューではなくエージェント設定ファイルに気を取られていないかを調べます。次の語句を探します：.claude/、SKILL.md、skills/、.agents/、プロジェクトの規約ではなくスキルファイルとして言及された CLAUDE.md、gstack、plugin.json、hooks/。該当するものがあれば、次の警告を追加します。

1 つ以上のモデルが、コードをレビューせずにエージェント設定ファイルを読んだ可能性があります。その出力の信頼性は低い可能性があります。再試行を検討してください。

ゲート判定：コードレビューのタスクでは、出力からゲート判定を行います。

• 指摘事項に [P1] マーカーがあるか確認します。1 つでもあれば、ゲートは FAIL です。
• [P1] マーカーがなければ（[P2]／[P3] のみ、または指摘事項なし）、ゲートは PASS です。
• ゲートを目立つように表示します：GATE: PASS または GATE: FAIL (N critical findings)。

両方のツールを使用する場合：各モデルの指摘事項を提示した後、モデル間の分析セクションを設けます。

CROSS-MODEL ANALYSIS:
  Both found:       [findings that overlap between Codex and Gemini]
  Only Codex found: [findings unique to Codex]
  Only Gemini found:[findings unique to Gemini]
  Agreement rate:   X% (N of M total unique findings overlap)
  Gate:             PASS / FAIL (N critical findings)

続けて、優先順位を付けた対応項目を提示します。両方のモデルが同じ問題を指摘した場合は、信頼度が高いと判断します。一方のモデルだけが指摘した場合は、どちらのモデルが指摘したかを明記し、その指摘が妥当かどうかを評価します。

単一のツールを使用する場合：ゲート判定とともに指摘事項を提示し、各項目が妥当か不確実かについて評価します。

エラー処理

エラー	対応
mcp__codex__codex が利用できない	Gemini のみを実行します
gemini: command not found	Codex のみを実行します
両方とも利用できない	停止してユーザーに通知します
Gemini 拡張機能が見つからない	インストールします：gemini extensions install <github-url>（gemini のリファレンスを参照）
差分が空／内容がない	停止します：レビュー対象がありません
タイムアウト	範囲を絞るよう提案します
片方のツールが失敗	もう片方の結果を提示し、失敗したことを伝えます

例

コードレビュー（両方のツール）：

User: /second-opinions review
Agent: [gathers branch diff, dispatches both with adversarial review prompt]
Codex: [finds race condition in concurrent writes, flags as [P1]]
Gemini: [finds same race condition plus unhandled error path in auth retry]
Agent: [presents cross-model analysis, agreement rate, GATE: FAIL (2 critical findings)]

計画のレビュー（反復型、単一ツール）：

User: /second-opinions review my migration plan with codex
Agent: [asks focus] -> "Correctness & edge cases"
Agent: [extracts plan, dispatches to Codex]
Codex: [returns concerns]
Agent: [revises plan, re-submits via codex-reply]
Codex: [approves revised plan]
Agent: [presents final result]

カスタムタスク：

User: /second-opinions have gemini analyze src/auth/ for race conditions
Agent: [dispatches Gemini with direct file reading]
Agent: [presents findings with assessment]

注意点

• Gemini は --yolo がないとハングします。 別のエージェントから呼び出されると、対話型の承認モードに入ります。必ず --yolo（または -y）を渡してください。
• Codex はデフォルトで実装を行います。 「これは分析タスクであり、コードを書かないでください」と明示しないと、Codex は指摘事項ではなくパッチを作成します。必ず分析のみであることを明確にしてください。
• モデルはスキルファイルに脱線します。 無視するよう指示しないと、Codex と Gemini は .claude/、.agents/、スキルディレクトリを読み込みます。ファイルシステムの境界を指示すれば防げますが、出力に脱線の兆候がないか必ず確認してください。
• ヒアドキュメントは差分で壊れます。 差分には $、バッククォート、シェルのヒアドキュメント展開を妨げる特殊文字が含まれます。代わりに printf と cat をパイプでつないでください。
• 単独の git diff ではステージ済みの変更を見落とします。 ステージ済みと未ステージの変更を両方取得するには、git diff HEAD を使ってください。
• 差分が大きいとレビューの品質が低下します。 約2000行を超えると、両方のモデルが問題を見落とし始めます。ユーザーに警告し、範囲を絞るよう提案してください。
• -e security は黙って無視されます。 Gemini のセキュリティ拡張機能は security ではなく gemini-cli-security としてインストールされます。