用途：在完成多项复杂软件开发任务、向用户报告完工之前，对本次改动范围做一次结构化代码评审。
两种模式：一是审查自己刚完成或被要求修复的工作，评审后应用并验证修复；二是仅被要求评审时，只给出清晰可执行的反馈，由用户决定采纳哪些，不要开始编辑代码。
工作流：按评审维度或代码区域拆分，派出并行子代理对改动做批判性审查；将发现汇总为编号清单，每条标注 critical/medium/low；在报告或动手前，必须对照真实代码核实每条发现，因为子代理会误报，处理不存在的问题反而会让代码变差。
修复模式：仅在此模式下修复已确认问题，然后重新运行项目的 lint/test/build 流水线；逐条阅读每处修复，确认其确实解决问题、没有破坏原任务或引入新问题；只做这一轮验证，不再递归开启新一轮完整审查。若某问题特别复杂或反复出现，使用 systematic-debugging 技能定位根因。
审查维度：正确性（是否满足任务要求，边界与错误路径、测试是否覆盖新行为）、可读性、架构（是否遵循既有模式与模块边界、重复、多余依赖）、安全（边界处校验不可信输入、密钥泄露、SQL/命令/路径注入、授权检查）、性能（复杂度、热点路径重复工作、N+1 查询、无上限拉取、缺分页、阻塞）。
代码坏味道基线：在仓库自身文档之外，可读性与架构两个维度始终附加固定的 Fowler 坏味道集合，仓库有明确标准时以仓库为准，否则按启发式判断，且工具已强制检查的项跳过。清单包括神秘命名、重复代码、依恋情结、数据泥团、基本类型偏执、重复 switch、霰弹式修改、发散式变化、夸夸其谈通用性、过长的消息链、中间人、被拒绝的遗赠，均以“疑似”标注。
校准：标准是“是否让代码库更好”，而非“是否按我的写法”；不为了有东西可报告而制造问题，不因风格偏好重写可运行代码，也不淡化真实问题并尽量量化影响；测试通过是必要条件而非充分条件。
死代码：重构会留下孤儿代码，改动后列出已不再使用的对象并先询问再删除，不要静默删除或任其腐烂。
子代理：适当并行以减少主对话上下文膨胀，要求输出简洁可执行、聚焦改动而非细枝末节，只给它们无法从代码推断的上下文，并划定清晰边界避免重叠。
报告：交付物是修复或发现，先给结论而非过程；仅审查时按严重度列出 file:line、问题与具体修法；修复模式先说什么已修、再说什么未修及原因，延迟或超范围项逐条列出并注明流水线结果。
限制：资料未提供安装命令、收费、平台支持等信息。