用途：审查当前分支 diff 的结构质量，在保持行为不变的前提下，主动寻找能删除概念、分支、包装或层级的更简单设计，而不是把复杂度挪到别处。
主要能力与审查标准：检查每处有意义改动是否具备更简单的结构（能否用不同模型或归属边界消除分支、模式、辅助函数或层级）；控制流是否内聚（分散的特例、重复条件、深层嵌套、职责混杂）；抽象是否有用（薄包装、泛型魔法、投机性扩展点、重复辅助函数）；边界是否清晰（功能逻辑留在规范模块，类型与不变量显式）；文件大小是否合理（改动使文件超过 1,000 行视为拆分信号，除非有明确结构理由）；编排是否合理（不必要的串行独立工作、可能留下部分状态更新的操作）；可读性（偏好直接、朴素的代码与清晰命名）。
审查边界：只审查改动代码及判断所需的周边代码；以仓库约定和既有规范辅助函数为准；跳过自动化已报告的格式化与 lint 问题；偏好少量高置信度的结构性问题而非表面意见；除非收益明确且不超出本次改动的归属边界，否则不提议大重构。
发现门槛：只有能指出文件与相关 hunk、具体维护成本或失败模式、最小可行修复、以及该修复优于现状的理由时才报告。以下视为阻塞项（除非实现有明确理由）：结构回退或可避免的边界泄漏；文件新跨过 1,000 行且无有用拆分；在已繁忙的流程中加入临时分支；存在规范辅助函数却重复逻辑；增加间接性而无清晰度的抽象、类型转换或可选契约；能移除大量附带复杂度的明确简化。不因个人风格、假设的未来需求或只是复杂度不同的重写而阻塞。
输出：按影响排序——结构回退与更简单设计；控制流、边界、抽象与类型问题；文件大小、模块化与可读性问题。每条发现使用格式：[severity] file:line — finding，并附 Impact（具体成本或风险）与 Fix（最小可行修复）。最后以 APPROVE（无阻塞发现）或 CHANGES REQUESTED（附阻塞数量）结束。
限制：资料未提供安装命令、平台支持、收费方式或具体使用步骤。