用途：对 diff、pull request 和风险变更做只读的多模型评审，偏向在非平凡开发后进行关键审查。目标是产出简短、具体的问题清单，而非泛泛评论，并透明披露评审之间的分歧。
主要能力：以模型参数将子代理分别固定到不同模型（GPT-5.5、Claude Opus 4.6、GPT-5.3-Codex），可用时使用全部三个，否则至少两个。每个子代理共享只读系统前言：必须保持只读、不越界、不推测、不建议补丁，对每条发现引用精确文件与行号，独立形成判断而不锚定给定上下文。
工作流分阶段：Phase 1 确定范围，优先使用活跃 PR、当前 git diff、会话内已完成编辑或用户给出的文件列表；无可审查内容时请用户指向分支、PR、diff 或文件集。Phase 2 构建变更摘要，包含意图、变更文件（仅路径加一行描述）和如何检查（分支/PR/提交信息），控制在约 50 行内，不粘贴原始 diff，不预判风险。Phase 3 并行启动全部子代理做独立首轮评审，完成前不相互展示发现。Phase 4 共识综合，将发现分为共识（两个及以上评审独立指出同一底层问题）、单一评审但有强证据、有争议或推测；丢弃风格闲聊、可被 linter 捕获的细枝末节和低置信推测。Phase 5 可选交叉评审，当用户要求"discuss""debate""cross-review"或存在值得复核的争议发现时触发，将匿名化综合结果回传各代理，让其对每条发现表示同意、不同意或补充细微差别，并更新综合结果。
使用方式：按评审者提示词为每个委员会代理传入 Phase 2 的变更摘要（绝不粘贴原始 diff），要求其用工具阅读改动文件、检查诊断、运行聚焦测试，只返回会阻碍批准或明确需跟进的高信号发现，聚焦正确性、回归、安全、风险行为变更的缺失测试和具体性能问题，不提供代码修改建议，不报告风格或推测性问题，每条发现引用精确文件与行；无阻塞问题则回复"No blocking issues found."。综合后始终将发现保存到会话文件夹的 review.md。
适用场景与默认行为：默认偏"评审→修复"模式；用户明确说"only review""just review""don't change anything""read-only"等时进入仅评审模式，不编辑文件。修复模式下先呈现发现，再为可修复项并行启动 Explore 子代理调查修复，按严重程度应用，跳过有争议项，修复后做轻量复评并报告已修复项与仍需用户输入的事项。
限制：仅只读评审；有争议发现需用户判断，不自动处理；缺失事实（如具体价格、平台要求等）暂未提供。