用途：在不改变行为的前提下改进代码结构，一次只做一小步。铁律是「一次重构 → 测试 → 提交」，绝不批量修改。
适用时机（按顺序判断，命中即用）：用户说重构、清理、重组，或要求提取、重命名、简化，或识别出代码坏味道时使用。若用户想加功能或修缺陷，应改用 tdd-enforcer；若只是格式/风格修正，应改用 /lint。常见坏味道触发：重复代码、函数过长（超 30 行）、魔法数字/字符串、嵌套过深（超 3 层）、死代码、命名不清。
流程分五阶段。一、评估：确认是否属于重构，若属于新行为、修缺陷或风格调整，则说明并建议正确做法。二、保护：检查是否有测试；测试充分直接进入下一阶段，覆盖部分则为未测部分补特征测试，无测试则先补特征测试。特征测试是捕获当前实际行为的安全网，不是规格说明。三、重构：一次只做一项，每次改动后运行测试。分为三层：第一层始终安全（重命名、提取函数、内联变量、移动函数）；第二层有测试下安全（提取变量、分解条件、卫语句、替换魔法字面量、删除死代码）；第三层需谨慎（提取类、用多态替换类型判断、引入参数对象、用管道替换循环），须拆成更小步骤。多项适用时先选最小范围：重命名 < 提取变量 < 提取函数 < 提取类。四、验证：每次重构后运行测试，通过则以 refactor: [改动内容] 提交；失败立即回退，命令为 git checkout -- <changed-files>。不要在失败的重构上「修复」，应先回退再尝试更小步骤。连续两次失败则停下来询问用户。五、迭代：仍需重构则回到第三阶段，否则报告完成并总结改动。
边界情况：部分测试覆盖时只为你即将重构的代码补特征测试；重构中发现缺陷应停止，记录位置并询问用户；用户要求大规模重构时拆成步骤，逐步完成。
反模式：不要批量重构，不要「修复」失败的重构，不要在无测试下重构，不要在重构中改变行为，不要跳过提交。其他细节暂未提供。