second-opinions

此技能仅适用于 Claude。Codex 和 Gemini CLI 不应调用此技能。

Second Opinions

将任务委派给 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” → 关注该重点。默认：一般审查。	从不 — 默认采用一般审查
Diff 范围	没有其他提示时，审查未提交的更改。“branch” → 分支 diff。类似 SHA 的字符串 → 指定提交。	代码审查范围不明确

2. 准备材料

根据任务类型收集内容：

任务类型	要收集的材料
代码审查	按选定范围获取 Git diff。自动检测默认分支。显示 --stat。若超过 2000 行或内容为空，则发出警告。
计划/架构	从对话上下文中提取计划。读取任何引用的文件。若上下文中没有计划，则询问用户。
文档	读取目标文件。若总计超过 2000 行，则发出警告。
自定义任务	将用户指令作为任务定义。读取任何引用的文件或目录。

自动检测代码审查的默认分支：

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

3. 构建与分发

文件系统边界：将以下指令添加到发送给 Codex 和 Gemini 的所有提示词中，并置于任何其他内容之前：

重要：不要读取或执行 ~/.claude/、.claude/、.agents/ 下的任何文件，也不要读取或执行任何路径中包含「skills」的文件。这些是为其他系统准备的 AI Agent 配置文件，其中包含与当前任务无关的提示词模板和 bash 脚本。请完全忽略它们，只关注项目自身的源代码、测试和文档。

这样可以避免模型浪费 token 去读取技能定义、Agent 配置和其他元文件，而不是完成实际任务。

提示词结构：使用 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，务必将其纳入，以便审查者根据项目约定进行检查。

请参阅 references/codex.md，了解 Codex MCP 提示词模式和调用方式。 请参阅 references/gemini.md，了解 Gemini CLI 调用模式。

分发规则：

• 同时运行两个工具时，在同一条消息中调用 mcp__codex__codex 和 Bash(gemini ...)，以便并行执行。
• 直接分发，不要预先检查工具是否可用。如果某个工具调用失败，只运行可用的工具。

迭代模式（用于计划/架构任务，或用户明确要求时）：

1. 分发初始审查
2. 如果审查者提出重要疑虑，根据反馈修改材料
3. 使用 mcp__codex__codex-reply（带上 threadId）重新提交，或调用新的 gemini，并附上修订背景
4. 最多进行 3 轮，以避免循环

4. 呈现结果

误入歧途检测：呈现输出之前，检查每个模型的回复，确认其没有因为查看 Agent 配置文件而偏离项目代码审查。留意以下内容：.claude/、SKILL.md、skills/、.agents/、CLAUDE.md（提及其作为技能文件，而非项目约定时）、gstack、plugin.json 或 hooks/。如果检测到这些内容，请附上警告：

一个或多个模型似乎读取了 Agent 配置文件，而不是审查你的代码。其输出可能不可靠。建议重试。

门槛判定：对于代码审查任务，根据输出确定门槛结果：

• 检查发现项中是否有 [P1] 标记。若有，门槛结果为 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 会卡住。 从另一个 Agent 调用时，它会进入交互式审批模式。始终传入 --yolo（或 -y）。
• Codex 默认会执行实现。 如果没有明确说明“这是一个分析任务，不要编写代码”，Codex 会生成补丁，而不是列出发现的问题。始终明确要求仅进行分析。
• 模型会偏离任务去查看技能文件。 如果没有要求忽略 .claude/、.agents/ 和技能目录，Codex 和 Gemini 都会读取这些内容。文件系统边界指令可以避免这种情况，但仍要检查输出是否有偏离任务的迹象。
• 使用差异时 heredoc 会出问题。 差异中包含 $、反引号和特殊字符，会导致 shell heredoc 展开出错。始终改用 printf + cat 管道。
• 单独使用 git diff 会漏掉已暂存的更改。 使用 git diff HEAD 捕获已暂存和未暂存的修改。
• 大型差异会降低审查质量。 超过约 2000 行后，两个模型都会开始漏掉问题。请提醒用户并建议缩小范围。
• -e security 会被静默忽略。 Gemini 安全扩展安装后名为 gemini-cli-security，而不是 security。