用途：对 git diff、提交范围或拉取请求做结构化代码审查，替代零散评论，系统覆盖影响评估、风险识别、文档影响与测试覆盖分析，帮助发现文档需更新、错误处理边界与跨模块影响等易漏问题。
适用时机：用户要求“审查我的改动”或“审查此 PR”、合并功能分支前、重大重构后验证、准备 PR 描述时。不适用于审查外部/上游代码或安全审计。
执行方式：由主智能体直接运行，以保留对话上下文；输出为聊天式审查报告，用户要求时可写入 docs/reviews/。
工作流：1) 确定审查范围，如 git diff、git diff --staged、git diff main..HEAD、git diff <commit1>..<commit2>、git diff $(git merge-base main HEAD)..HEAD，先用 git diff <scope> --stat 概览；2) 按源码、测试、配置、文档、依赖分类变更并统计规模；3) 分析影响，包括范围、公共 API、破坏性变更、数据模型、错误处理；4) 评估风险，涵盖复杂度、跨模块、并发、安全、数据丢失、回滚；5) 检查文档影响，交叉比对变更文件与现有文档；6) 检查测试覆盖，判断新函数、行为变更、错误路径、边界条件是否有测试；7) 按固定格式呈现审查，并用提问工具与用户讨论。
审查格式包含概览指标、影响评估、风险矩阵、文档影响、测试覆盖与建议。规则：只审查 diff 而非整个代码库；反馈需具体到文件名、行号、函数名；区分“必须修复”与“可考虑”；尊重用户已说明的意图；文档影响检查为必做项；不使用内置 explore 子智能体。
限制：测试覆盖为启发式检查而非覆盖率工具；不用于安全审计或外部代码审查。