用途：实现完成后的质量保证。先做 Design Doc 合规校验，再做安全校验；用户确认修复路由后执行代码侧修复或设计侧更新，最后重新校验并出报告。
主要能力：以编排器身份调度子代理。code-reviewer 做 Design Doc 合规审查；security-reviewer 做安全审查；task-executor 执行代码修复；technical-designer（update 模式）、document-reviewer、design-sync 处理设计侧重；quality-fixer 做质量门禁；修复后重新调度 code-reviewer / security-reviewer 复验。输出结构化报告，含 complianceRate、verdict、identifierMatchRate、验收标准达成情况、标识不匹配、质量问题，以及安全 status 与四类发现（confirmed_risk、defense_gap、hardening、policy）。
使用方式：Design Doc 默认取最近一个，也可通过 $ARGUMENTS 指定。从 docs/design/ 识别 Design Doc，并用 git diff 检查实现文件；工作计划的 Review Scope 仅在明确提供或可无歧义解析时读取，否则记为 none，不做推断。安全返回 blocked 时立即停止并上报。结果呈现采用 c（代码侧修复）、d（设计侧更新）、s（跳过）三种路由，支持空输入、all-recommended、all:c/all:d/all:s 及 F1:c 形式；须用户显式确认后才能继续。代码侧任务文件写于 docs/plans/tasks/review-fixes-YYYYMMDD.md，修复采取暂存方式，超过 5 个文件停止。修复完成后删除该任务文件。
适用场景：Design Doc 驱动的开发流程中的实现后审查，以及需要在审查后自动修复合规与安全问题的情况。
限制：不能处理根本性业务逻辑变更、架构级改动和 Design Doc 缺陷；已提交的密钥属 blocked，需人工介入。任务文件模板参考 documentation-criteria 技能；spawn_agent 使用 fork_turns="none"。运行前需加载 coding-rules、testing、ai-development-guide、llm-friendly-context 技能。其他安装与配置细节资料未提供。