用途：统一代码审查系统，根据场景分派合适的审查智能体，用于代码质量、缺陷、合规检查或合并前审查。
主要能力与模式： 快速审查：适用于临时检查、低噪声反馈，分派 quick-reviewer，采用置信度评分，仅报告置信度不低于 80 的问题，按严重程度分组（Critical 90-100、Important 80-89）。 深度审查：适用于完成功能后、合并前或计划执行审查循环，分派 deep-reviewer，使用含占位符的完整清单，占位符包括 {WHAT_WAS_IMPLEMENTED}、{PLAN_OR_REQUIREMENTS}、{BASE_SHA}、{HEAD_SHA}、{DESCRIPTION}，输出优点、问题（Critical/Important/Minor）、建议与合并结论。 专项审查：针对特定质量维度，分派 comment-analyzer（注释准确性与文档质量）、test-analyzer（测试覆盖质量与行为覆盖缺口）、silent-failure-hunter（错误处理与静默失败）、type-design-analyzer（类型不变量与封装）。 综合审查：适用于合并到主分支前，采用四遍结构（TDD 合规、仅差异质量、上下文质量、浏览器审计），详见 references/comprehensive-review-procedure.md。
使用方式：先用 scripts/review-prep 收集 git 上下文（自动检测基础分支，输出 BASE_SHA、HEAD_SHA、差异统计、变更文件、提交日志），可用 --json 获得结构化输出；阅读所选智能体的参考文件；以提示词加 review-prep 输出启动通用 Task 智能体；按反馈行动，Critical 立即修复，Important 在继续前修复。
工作流集成：计划执行（逐任务/批量）用深度审查，合并到主分支前用综合审查，临时或受阻时用快速审查，特定关注点用专项审查，GitHub PR 审查与发布用 github-pr 技能。审查后可选用简化流程，在不改变功能的前提下提升清晰度、一致性与可维护性。
反馈处理：收到审查反馈时按 READ、UNDERSTAND、VERIFY、EVALUATE、RESPOND、IMPLEMENT 六步响应，先验证再实现，必要时以技术理由反驳。
限制与注意：避免因“简单”跳过审查、忽略 Critical、带未修复 Important 继续、顺序执行综合审查各遍（1 与 2 可并行）、未在综合模式第 2 与第 3 遍间去重。具体安装命令与收费信息暂未提供。