用途：作为代码审查的“指挥者”，不逐行审查代码，而是判断改动了什么、应由谁审查，并行调度只做诊断的评审子代理，再把结果合并成一份报告。价值在于路由与整合：让合适的专家看到改动，用户只读一份去重后的清单。
主要能力：三位固定评审每次都运行——sr-reviewer 负责整洁代码（圈复杂度、DRY、命名、错误路径、抽象边界、可维护性、与代码库规范偏离）；sa-reviewer 负责架构（分层一致性、竞态/顺序/原子性、缓存与失效、性能、整洁架构边界）；qa-reviewer 负责 QA（未处理边界情况、改动导出对调用方的连锁影响、可能回归）。专项评审按改动检测添加：frontend-reviewer（前端代码）、ui-ux-reviewer（渲染/视觉层：标记、样式、布局、设计令牌、无障碍）、backend-reviewer（路由、服务、仓储、数据库、API 处理器）、security-auditor（认证、加密、注入、密钥、依赖等安全敏感面）。路由是加法式且倾向包含，安全尤其倾向包含。
使用方式：需在主线程内联运行，不能放进子代理，因为需要 Agent 工具调度评审、用 AskUserQuestion 处理歧义。步骤：1）确定范围，支持无参数（默认当前 diff 对比基线分支，含已提交与未提交改动）、指定文件/路径、范围或分支、PR 编号/URL（用 gh pr diff）、staged/unstaged/committed；范围为空则停止。2）分类改动并路由，向用户说明选了哪些评审及触发信号。3）在单轮内并行调度所有选中评审，提示词保持精简，只给范围与关注领域。4）合并报告：Urgent→HIGH、suggestion→LOW，同一 file:line 的同一根因去重并标注所有提出者，保留最高严重度，HIGH 在前、同层按文件分组。输出每行格式：SEVERITY - 问题 - path:line - 评审者。无问题则输出“No issues found across: …”。之后可提出把某条发现展开为完整修复建议，并询问是否代为应用修复，未经确认不修改。
适用场景：需要多视角、按改动类型自动匹配专家的代码审查，尤其全栈改动、涉及安全敏感面或希望得到单一去重清单时。
限制：评审子代理随 delivery-chain 插件提供，需在会话中安装/加载，否则 subagent_type 调度失败，应告知用户插件未启用而非静默跳过。该技能止于报告（及用户批准的修复），从不提交、推送、打开或合并 PR。改动跨数十文件时仍调度完整评审组，但应让评审优先高风险文件，并在摘要中说明覆盖是否受限，不得暗示未获得的完整覆盖。具体安装命令与价格资料暂未提供。