用途：对代码面做理解优先的清理，默认范围是当前分支相对 main 的 diff（git diff main...HEAD --name-only），也可指定文件、模块或整个包。适用于“Claude 写的”“agent 生成的”“vibe-coded”“没逐行审过”“感觉不对但测试通过”等场景，或继承他人代码、无法从代码本身还原设计意图时。
主要能力与流程：八阶段工作流。1）框定范围、用户置信度与测试状态；2）建立理解基线，用特征测试固定当前行为，并运行观察真实输入；3）验证现实，核对导入是否真实存在、函数签名是否匹配、框架用法是否正确、API 是否过时，并做 slopsquatting 检查；4）追踪真实调用者，0 调用者删除，1-2 调用者默认内联，3 个以上才保留；5）删除并观察，注释掉后跑测试与关键路径冒烟；6）对仍不理解的代码加日志运行观察；7）审计安全边界，包括边界输入校验、硬编码密钥、数据层授权、错误处理；8）由边界向内同心圆重构，一次提交一个改动。
硬性规则：理解先于结构，未固定行为前拒绝重构；默认内联，强制三法则；追踪读取而非引用；测试不是意图证据；不信任注释；验证每个依赖；不轻信错误处理；一次提交一个改动。
限制：无法实际运行代码时不能使用，因为方法论是运行观察而非阅读相信。测试红时先用 /hunt 定位根因；若目标是符合项目规范或行业标准（加测试、类型、命名、替换宽泛 except），应改用 /best-practice。若用户想跳过理解基线，技能会拒绝。参考资料包括 references/patterns.md、references/diagnostic.md、references/audit.md，以及 .research/code-simplification.md 的 §6 与 §8.5。