simplify

简化

通过三个并行 Agent——复用、质量和效率——审查所有变更文件，然后修复发现的问题。

核心原则

变更的代码是唯一的审查目标。每个审查维度独立运行，查看完整差异，并在不了解其他 Agent 结果的情况下报告发现。主 Agent 汇总结果并应用修复。

强制门槛

1. 审查前先确定变更内容。 始终先运行 git diff（如果有暂存的变更，则运行 git diff HEAD）。未确认变更内容时，绝不进行审查。
2. 三个 Agent 必须并行运行。 禁止依次执行这三个审查 Agent。通过一条消息同时派发全部三个 Agent。
3. 每个 Agent 都要收到完整差异。 不要按 Agent 拆分或筛选差异。每个 Agent 都必须看到所有变更。
4. 直接修复问题。 此技能会修改代码，而不只是提供报告。如果发现的问题可以采取行动解决，就修复它。
5. 静默跳过误报。 如果某项发现不值得处理，就继续进行。不要反驳该发现，也不要解释为何跳过。
6. 不要将范围扩展到差异之外。 只审查变更的代码。不要重构未变更的代码，即使其中存在相同问题。

适用场景

• 完成任何实现工作后，需要验证代码质量时
• 用户说“简化”“清理”“审查变更”或“检查代码”时
• 执行 run-plan 后、review-work 前，作为中间质量检查
• 用户怀疑近期变更中存在重复逻辑、低效代码或临时拼凑的写法时

不适用场景

• 没有变更时（没有差异输出）
• 用户需要全面审计整个代码库时（此技能只审查差异）
• 用户只需要格式化或 lint 修复时
• 目标是验证计划时（请改用 review-work）

流程

阶段 1：确定变更内容

1. 运行 git diff，查看未暂存的变更
2. 如果没有输出，运行 git diff HEAD 检查已暂存的变更
3. 如果仍然没有输出，检查用户提到的或在本次对话中较早编辑过的近期修改文件
4. 如果无法确定任何变更，通知用户并停止

捕获完整的差异输出——这将作为三个 Agent 的输入。

阶段 2：并行启动三个审查 Agent

通过 Agent 工具在一条消息中同时派发全部三个 Agent。每个 Agent 都会收到完整差异及下方对应部分中的审查提示词。

提供给每个 Agent 的内容：

• 阶段 1 的完整差异输出
• Agent 的审查提示词（从下方对应部分原样复制）

不要提供的内容：

• 其他 Agent 的发现（各 Agent 独立运行）
• 修复问题的指示（Agent 只报告发现）

Agent 1：代码复用审查

向 Agent 提供以下提示词：

你正在审查代码差异中的复用机会。你的任务是找出新代码中重复实现代码库已有功能的部分。

对差异中的每项变更：

1. 搜索现有的实用工具和辅助函数，看看是否可以用它们替代新编写的代码。搜索实用工具目录（utils/、helpers/、lib/、common/、`shared/）、变更文件旁边的文件，以及变更文件导入的文件。
2. 标记任何重复现有功能的新函数。 报告新函数、已有函数，以及已有函数所在的位置。
3. 标记可使用现有实用工具的内联逻辑。 常见候选项：手动编写的字符串处理、手动路径处理、自定义环境检查、临时类型守卫、手动数组／对象转换、内联的日期／时间格式化。
4. 标记重新实现的标准库功能。 检查变更是否重新实现了语言标准库或已安装依赖中已有的功能。

对每项发现，报告：

• 复用机会： [简要说明]
• 新代码：[文件:行号] — [编写的内容]
• 已有代码：[文件:行号] — [已有内容]
• 建议：[如何替换]

如果未发现复用问题，请报告：“未发现复用问题。”

Agent 2：代码质量审查

向 Agent 提供以下提示词：

你正在审查代码差异中的质量问题。你的任务是找出临时凑合的模式、不必要的复杂性，以及抽象边界违规。

检查以下模式：

1. 冗余状态： 总是由其他变量推导得出的新变量、存储本可在访问时计算的值的缓存，以及本可直接调用函数的事件监听器或观察器。
2. 参数泛滥： 新增布尔标志参数的函数、变更后参数超过 4 个的函数，以及总是一起传递、应合并为单个对象的多个参数。
3. 略有差异的复制粘贴： 两个或多个仅相差 1–2 行的代码块、字段名不同但结构重复的条件语句，以及多个位置中相似的错误处理代码块。
4. 抽象泄漏： 从模块外部访问私有字段或内部状态、跨模块边界传递实现细节，以及导致一个模块依赖另一个模块内部结构的变更。
5. 字符串类型代码： 新增与已定义为常量的值进行比较的字符串、新增与现有枚举或联合类型值相同的字符串字面量，以及在多个位置出现但没有共享常量的魔法字符串。
6. 不必要的注释： 说明代码在做什么、叙述变更或引用任务的注释。删除这些注释。仅保留说明非显而易见的原因的注释，例如隐藏约束、细微不变量或变通方案。应删除的示例：// increment counter（位于 counter++ 上方）。应保留的示例：// Redis returns nil for both "key missing" and "value is empty" — we must distinguish。

对每项发现，报告：

• 质量问题： [类别]
• 位置：[文件:行号]
• 问题：[问题所在]
• 建议：[如何修复]

如果未发现质量问题，请报告：“未发现质量问题。”

Agent 3：效率审查

向该 Agent 提供以下提示词：

你正在审查代码差异中的效率问题。你的任务是找出不必要的工作、遗漏的并发处理和资源管理问题。不要过早优化——只标记明显不必要或明显管理不当的问题。

检查以下模式：

1. 不必要的工作： 在循环中多次计算相同的值、同一个文件被读取多次、可以缓存或批量处理却重复发起相同的 API 调用、可以通过一条带 WHERE IN 的查询完成却在循环中执行数据库查询。
2. 遗漏的并发处理： 多个彼此独立的操作通过 await 依次调用、可以并行处理却依次读取文件、彼此独立的 API 调用一个接一个地执行。
3. 热路径臃肿： 在请求处理程序中添加同步文件 I/O、在渲染函数中新增本可记忆化的计算、在模块加载时新增初始化逻辑。
4. 反复执行的无效更新： 未检查值是否变化，就在每次间隔触发时调用状态设置器；每次事件触发时都派发 store 更新，却没有变更检测保护；接受更新回调却不遵循“无变化”返回值的包装函数——添加变更检测保护，确保值未变化时不会通知下游使用方。
5. 不必要的存在性检查（TOCTOU）： if (existsSync(path)) { readFileSync(path) }——直接执行操作并处理错误。
6. 内存问题： 不受限制地增长的集合、注册后没有相应移除的事件监听器、在 dispose/destroy 处理程序中没有清理的订阅、在闭包作用域中保留时间过长的大型对象。
7. 范围过大的操作： 为提取单个值而读取整个文件、为按 ID 查找单条记录而获取所有记录、只需要一个字段却加载整个配置。

对于每项发现，请报告：

• 效率问题： [类别]
• 位置：[文件:行号]
• 问题：[浪费之处]
• 建议：[修复方法]

如果没有发现效率问题，请报告：“未发现效率问题。”

阶段 3：修复问题

1. 等待三个 Agent 全部完成
2. 汇总三个 Agent 的发现
3. 对重叠的发现去重（不同 Agent 可能标记同一段代码）
4. 对于每项可操作的发现：
   • 应用解决该问题的最小修复
   • 不要在同一更改中捆绑无关的改进
   • 不要将修复范围扩大到所标记问题之外
5. 对于每项误报：静默跳过
6. 运行测试套件，确认没有引入回归
7. 如果修复后测试失败：撤销该修复，并将其报告为需要人工处理的发现
8. 简要总结修复的内容（或确认代码已经没有问题）

何时停止

• 阶段 1 未检测到任何更改——通知用户并停止
• 三个 Agent 均未发现问题——确认代码没有问题
• 修复导致测试失败，且无法在不扩大范围的情况下解决——停止，报告回归，并建议使用 systematic-debugging

反模式

反模式	失败原因
未先运行 git diff 就开始审查	审查可能并未更改的代码，把时间浪费在无关发现上
依次运行 Agent	造成不必要的延迟；违反硬性关卡 #2
只向每个 Agent 提供部分差异	Agent 会遗漏跨多个文件的问题
报告发现却不进行修复	有悖于此技能的目的；用户还得手动处理
对跳过的发现争辩或加以解释	浪费上下文和时间；跳过并继续
顺便审查未更改的代码	范围蔓延；违反硬性关卡 #6
修复问题后不运行测试	可能悄无声息地引入回归
在修复中捆绑“顺便”进行的改进	将审查修复与无关更改混在一起；使差异难以理解

最简检查清单

• 运行 git diff，确认变更内容
• 并行调度全部三个 Agent（单条消息）
• 每个 Agent 都收到了完整的 diff
• 汇总了三个 Agent 的发现
• 针对可执行的发现应用了修复
• 不作解释地跳过误报
• 修复后运行了测试——没有引入回归
• 向用户总结了结果

后续步骤

简化完成后：

• 如果这是一次实现后的质量检查 → 建议转到 review-work，独立验证计划
• 如果发现并修复了问题 → 用户可以再次运行 simplify，确认修复没有问题
• 如果审查期间发现了 Bug → 建议使用 systematic-debugging

此技能本身不会调用下一个技能。它会报告结果，由用户决定下一步。