用途：在 PR 审查、合并前检查代码变更或收到 GitHub 代码审查请求时使用，由编排者（Staff Engineer 角色）并行调度子代理做多维度审查，自身不直接审代码。
主要能力：分两个维度。正确性由 code-quality-reviewer 负责代码质量、架构、防御性编程、测试、模式与简化；安全性由 security-reviewer 负责 OWASP Top 10、认证、数据暴露、注入、IDOR，以及条件触发的 SQL 性能检查。流程为收集上下文、并行派发两个子代理、汇总、输出报告；存在 CRITICAL 或 IMPORTANT 时判定为 CHANGES REQUIRED，否则 APPROVED。子代理失败会重派一次，仍失败则标记 Review Incomplete。
使用方式：建议在可用的最强推理模型上运行，model: inherit 只是请求而非保证，若会话使用小模型需先升级。编排者预先计算上下文，包括 git merge-base、git rev-parse、git diff、git diff --name-only、git log --oneline 等命令结果，以及 PR 元数据、需求来源、代码库上下文、约定上下文、Schema 上下文、失败语义上下文、框架上下文等占位符。diff 超过约 2000 行时优先安全相关文件并摘要其余部分。PR 评论由 Python 入口预先收集，不再通过 gh api 重复获取。
适用场景：GitHub PR 审查、合并前变更检查、复审（review_number 大于 1 时避免重复标记已解决问题）、回答评论中高置信度问题（低于 90% 置信度不回答）。
限制：不替代独立的 SQL REVIEW 阶段；汇总阶段只做格式化与去重，不重新调查；需按框架类型系统校验发现，类型安全或框架内置处理的问题应丢弃；团队审查简报与 review-lens 语料缺失时记录不可用并正常继续，不因缺失而失败。具体安装命令与价格资料暂未提供。