技能介绍

它解决什么问题

一次迭代结束时，工作分支里往往堆着十几次提交的叠加：为了绕过测试临时加的分支、复制了两遍的工具函数、上一轮重构留下一半的中间状态。这类"技术债务"不致命，但会让 git diff 变得难以阅读，也让 review 卡在"先理解再评判"的阶段。手动清理的问题是：它枯燥、耗时，且容易在改动过程中引入新错误——你本来是去收拾房间的，结果把台灯摔了。

工作方式：三代理并行

simplify-code 的做法是把清理工作拆给三个子代理并行执行，灵感来自 Claude Code 的 /simplify 命令。核心流程：

定位变更范围：先确定"recent code changes"的边界，通常以最近一次合并或分支分叉点为基准，而不是整个仓库
并行分析：三个子代理各自独立审阅同一批变更，分别从死代码移除、重复逻辑合并、控制流简化等角度提出修改意见
汇总产出：收集三份视角的建议，去重合并后输出一份清理方案，再交给主流程应用

这种"多视角并行"的好处是：单一 agent 容易顺着自己上一个改动的惯性思考，而三个独立代理的视角交叉能暴露更多盲区——比如一个代理发现某个函数只在测试里被调用，另一个则指出它和另一个分支的实现重复。

适用边界

只管清理，不管修 bug：它的职责是简化与去重，不是修复功能缺陷。发现可疑逻辑时，应回到常规的 code review 流程处理
范围限定在近期变更：不适合拿来清理整个历史代码库——那样既慢，也容易把尚在使用的兼容性代码误判为冗余
建议与测试配合使用：该技能与 requesting-code-review、test-driven-development 等技能相关联，清理后的改动仍需要测试兜底
并行代理需要去重协调：三个代理的建议可能重叠甚至冲突，最终方案需要合并环节处理，这也是该技能设计中的必要一步