用途：moe-review 用于对任意交付物做多视角评审，包括代码 diff、论文、报告、设计文档等。它不亲自评审，而是充当评审协调者：分析交付物、组建 5 位领域专家、并行派发、汇总反馈、自动修复并循环复审。
主要能力：
- 分析交付物。代码类可用 git diff --stat 与 git diff 识别语言、框架、领域与工作类型；文档类通读生成或修改的文件，识别文档类型、主题、目标读者与目的。
- 自动组建 5 位专家，不询问用户。强调多样性，覆盖不同维度（如架构、领域、代码质量、安全、性能、测试；文档则可用主题、方法论、数据、文风、目标读者视角）。人设需具体，包含姓名、前公司、年限与专长。
- 并行评审。5 个 Agent 调用必须放在同一个 function_calls 块中，禁止串行。子代理按严重级别（CRITICAL、MAJOR、MINOR、NITPICK）分类问题，给出位置、描述与修复建议，并输出严格 JSON（含 reviewer、specialty、summary、approval、issues、praise、confidence）。
- 汇总与自动修复。合并反馈，同一问题被多人提出则提升优先级；按严重度排序并展示汇总表。CRITICAL 与 MAJOR 立即自动修复，MINOR 酌情处理，NITPICK 可忽略；代码类修复后运行构建与测试验证。
- 自动复审循环。修复后自动再次并行派发 5 位专家，并附上一轮问题与修复情况。终止条件为：5 位全部 APPROVED、无 CRITICAL/MAJOR 剩余、达到第 3 轮、或无新问题。
- 最终报告。以表格列出专家团队与最终结论、修复摘要与统计（轮次、问题数、已修复数、未应用数及原因），代码类附构建与测试结果，文档类替换为相应检查（如拼写检查）。
使用方式：由用户指向一个交付物，技能按上述六个阶段自动执行；核心要求是并行执行、专家多样性优先于深度、人设具体化、保守自动修复、最多 3 轮防止死循环。
适用场景：代码评审、论文与研究报告评审、设计文档与提案评审等需要多视角把关的交付物。
限制：资料未提供具体安装命令、收费方式、支持平台或运行环境要求；专家为虚拟人设，评审质量依赖人设具体程度；设计类判断需升级给用户，同一问题连续两轮未解决则停止自动修复并上报。