用途：在用户有未提交改动、希望提交前审查时使用，是对全部未提交内容做一次“整体 diff”的正确性检查。区别于构建循环中的逐任务即时审查、设计系统遵循审查和安全深度审计。
主要能力：按五个视角审查——正确性（逻辑错误、条件反转、差一错误、未处理 null/undefined、未 await 的 Promise、错误分支）；回归与契约（函数签名或返回结构变更但调用方未更新、导出被移除或改名仍被引用、schema 变更与查询不匹配、API 响应变更与前端消费方不符）；边界与错误处理（空/零/负数输入、网络失败路径、被吞掉的异常、新 UI 缺少加载或错误状态）；安全薄层（仅两项提交阻断项：diff 或未跟踪文件中的硬编码密钥、新增路由/端点缺少鉴权，更深问题转交安全审计）；一致性与复用（重复实现已有辅助函数、偏离本仓库既有模式、遗留调试输出、注释掉的代码块、返回假数据的 TODO 桩）。
使用方式：先运行 git status --porcelain、git diff HEAD、git diff --staged、git ls-files --others --exclude-standard（逐个完整阅读未跟踪文件）、git log --oneline -5 确定范围；若无未提交改动则停止；改动文件超过 30 个时询问是否缩小到当前功能。随后用一两句话说明改动意图，读取调用方、消费方、测试与类型等上下文，并加载仓库根目录 CLAUDE.md/AGENTS.md 约定。每条发现需有真实源码的 file:line 佐证，确认破坏的消费方确实存在且可达；属于 diff 内的问题才计为本次问题，已存在的标注为既有问题。报告先给一行计数，再列必须修复项（含问题、影响、验证位置、具体修复方式）、考虑项（最多五条）、既有问题，以及一行真诚肯定，最后给出明确结论“可提交”或“不可提交——先修复 N 项”。
适用场景与限制：典型功能 diff 约需 5–15 分钟；重复审查只看必须修复项、不再新增挑剔意见；不报格式化、导入顺序、缺失测试等由仓库 linter/CI 负责的内容；若发现与 docs/PRD.md 或任务意图矛盾，应指出分歧而非直接判定代码错误。建议在每次结束功能的提交前运行，并在涉及鉴权、支付或数据访问的工作后接续安全审计。