用途：审查需求文档或计划文档，通过多角色（persona）分析发现问题。适用于已有需求或计划文档、需要从产品、设计、安全、范围、对抗性等角度获得审查意见的场景。
主要流程与能力：
- 获取并分析文档。若提供路径则读取；未指定则询问要审查的文档，或用文件搜索工具（如 Claude Code 的 Glob）在 docs/brainstorms/ 或 docs/plans/ 中找最新文档。之后区分类型：来自 docs/brainstorms/ 的为 requirements，来自 docs/plans/ 的为 plan。
- 选择条件性角色。按文档内容信号激活，例如含用户功能或市场声明时激活 product-lens；含 UI/UX、用户流程时激活 design-lens；含认证、API、PII、支付等时激活 security-lens；含多优先级层级或大量需求时激活 scope-guardian；需求超过 5 条、含高风控领域或新架构时激活 adversarial。始终包含 coherence-reviewer 与 feasibility-reviewer。
- 并行派发所有裁判智能体，每个拿到完整文档与模板变量（如 persona_file、schema、document_type、document_path、document_content）。某个智能体失败或超时不阻塞整体，在 Coverage 中标明；最多 7 个仍并行。
- 汇总处理：校验 JSON 是否符合 findings schema；过滤置信度低于 0.50 的发现并保留为残余关注；按 section+title 归一化去重，意见相反的不合并；对残余关注做跨角色佐证或具体阻塞风险提升至 P2；角色冲突时生成组合发现并交由用户权衡；按 autofix_class 分为 auto、batch_confirm、present 三类路由；缺乏建议修复的 auto 降级为 batch_confirm，batch_confirm 再降级为 present。
- 应用与呈现：自动应用 auto 修复；batch_confirm 汇总为一次批量确认（用平台的阻塞式提问工具，如 AskUserQuestion、request_user_input、ask_user 询问是否应用这 N 项修复）；其余逐项呈现。输出含覆盖率表、已应用自动修复、残余关注与待决问题。保护 docs/brainstorms/、docs/plans/、docs/solutions/ 中的文件，不得建议删除。
- 下一步：提供“再次精炼”或“审查完成”。两次精炼后可建议结束，但用户可继续。返回“Review complete”作为终止信号。
限制与约束：不要重写整份文档；不要添加用户未讨论的新章节或需求；不要过度设计；不要创建单独审查文件或元数据章节；不要修改 ce-brainstorm、ce-plan 两个调用方技能。具体使用命令与安装方式资料中暂未提供。