用途：在提交答案前对智能体自己的结论做交叉检查，用不共享其框架的评审者压力测试答案。评审者集合取决于可用资源：始终可用的是隔离的 idea-validator 智能体（同模型家族，但没有父上下文，无法锚定你的框架，且会读取实际文件）；若可通过 CLI 包装器或 API 访问第二个模型家族（如 Gemini、GPT），可将其加为外部评审者，它仅依据简报评审、无仓库访问，适合概念与技术时效性判断，不适合文件级事实。
何时调用：存在两条或以上可行路径需要选择时用 Round-Table；高风险决策（架构、发布文案等有真实回滚成本的）用 Boardroom Debate；同一问题尝试 2 次以上仍卡住，或有非平凡提案待批准时用 Devil's Advocate。若都不触发则不要调用，常规工作单模型答案足够。范围外：事实查询（如“最新的 X 是什么”）属于 WebSearch，不是评审。
先有自己的思考（关键）：任何评审风格之前，先自行研究、形成带理由与权衡的提案并展示给用户，然后再调用评审者批评它。在形成自己立场前询问评审者，会使其成为决策的种子而非验证器。
三种风格：1）Devil's Advocate（单次批评）：用自包含工件（内联粘贴设计/决策/计划，加上应读取的文件路径）启动 idea-validator，或把同一工件发给外部模型。2）Boardroom Debate（并行验证，核心模式）：写一个自包含工件，内容内联粘贴，不要依赖仅看简报的评审者可能静默加载失败的文件引用；在同一条消息中并行启动所有评审者，顺序调用会破坏独立性；建立验收台账（关注点/评审者 A/评审者 B/我的评估/行动），裁决而非计票，代码阅读型评审者在代码事实上优先于仅看简报者。3）Round-Table（在路径间选择）：发散→深化→收敛，收敛前必须与用户确认：核实事实（联网检查）→广泛生成/挑战选项→用具体论据淘汰弱项至 2-3 个→向用户呈现幸存者并询问偏好→收敛为一个主选加淘汰清单→核实最终主张→综合。
关键评估规则：每次评审后，质疑每条建议（事实还是推测？）、检查评审者看不到的缺失上下文、核实数字（预测不是测量），并呈现表格：评审者说/我的评估/行动。反模式：原样转发评审输出、全盘接受、把评审者信心当作正确性、为琐碎或风格选择运行评审、顺序执行“并行”调用。限制：外部评审者无仓库访问，仅适合概念与技术时效性；事实查询不适用本技能。