用途：在面对一个代码问题的提议方案或现有代码时，找出最简的完整生产设计。简化指更容易理解和变更，同时保留每一项真实需求；文件、函数或行数更少本身不代表更简单。
两种模式：推荐模式用于“这能更简单吗”或方案评审，不修改文件，修订提议只改提议不改代码；实现模式用于用户要求简化、重构或应用建议，直接改动并验证，不再请求批准。除非用户要求改动，否则停留在推荐模式；仅当缺失的决策会改变方案或范围时才提问。
理解需求：阅读当前路径的代码、调用方、测试与本地模式，需求与风险清楚后即停止。区分依赖的行为与契约、可放弃的假设与锦上添花项，以及必须保留的复杂度，如领域规则、持久化、恢复与运维保证。移除某机制前须了解其使用方、在运行与故障处理中的作用及替代方案。
寻找更简形态：可吸收该行为的既有路径、辅助函数、类型、组件或 API；语言、框架或既有依赖已提供的重复代码；只有一种实际变体的通用代码、扩展点或配置；为局部缺陷重写、为简单状态引入状态机、为单一调用方引入框架、投机式迁移、新依赖或为内部便利大改 API；只增加一层调用的包装；逻辑偏离其自然归属等。只有一个调用方的聚焦模块，若隐藏真实复杂度并减少调用方所需知识，也是合理的。比较全生命周期成本而非初始规模，拒绝把复杂度、风险或人工工作后移的简化。
替换接口时要找到所有使用者（含测试），把测试迁到替代实现并校验同一行为；其他调用方或灰度需要时保留旧接口，并说明临时适配器何时可移除。在同一范围内发现同类问题应一并处理，范围外的单独报告。
实现：重构前运行相关测试，之后保留相同的有意义用例；仅在授权契约变更或测试确有错误时改预期结果，不得通过改夹具、模拟或测试选择掩盖失败。若含行为修复且可用 tdd 技能则使用，否则先看回归测试失败再修代码。要一直做到验证完成，遇阻碍则保留有效的失败测试，报告缺失的决策与剩余工作。
报告：推荐用需求、需保留的复杂度、可放弃的假设、更简路径（含位置）、权衡、验证六部分，无内容的行省略；实现则报告改动内容、为何更简、运行的检查及结果和限制。技能未在资料中说明其平台、依赖或安装方式。