跳到主要内容

Simplify Code

对近期代码变更进行 4 智能体并行清理。

技能元数据​

来源内置（默认安装）
路径skills/software-development\simplify-code
版本1.1.0
作者Hermes Agent（灵感来自 Claude Code /simplify）
许可证MIT
平台linux, macos, windows
标签code-review, cleanup, refactor, delegation, subagent, parallel, simplify
相关技能requesting-code-review, test-driven-development

参考：完整 SKILL.md​

信息

以下是 Hermes 在触发此技能时加载的完整技能定义。这就是技能激活时智能体所看到的指令。

Simplify Code — 并行审查与清理

用四个各司其职的审查者并行审查你近期的代码变更，汇总它们的发现， 并应用值得应用的修复。

这是一次清理，而不是找 bug。 你是在改进已经能正常工作的代码的 质量——消除重复、压平不必要的复杂度、削减浪费、把权宜之计转变为 更彻底的修复。不要在这里寻找正确性 bug；那是 requesting-code-review 的职责。

核心原则： 四个领域狭窄的审查者胜过一个大而全的审查者。每个 审查者都会深入代码库中搜索某一类问题——复用、质量、效率、抽象 层次——而不必将注意力摊薄到全部四类上。它们并发运行，因此你只需 付出一次审查的延迟，而不是四次。

何时使用​

当用户说出以下任何内容时触发此技能：

  • "simplify" / "simplify my changes" / "simplify these changes"
  • "review my code" / "review my recent changes" / "clean up my changes"
  • "/simplify"（如果他们还保留着 Claude Code 的习惯）

用户可能会添加的可选修饰语——请遵守：

  • 聚焦： "simplify focus on efficiency" → 只运行效率审查者 （或将汇总权重偏向它）。可识别的聚焦项：reuse、 quality（也接受 simplification）、efficiency、altitude。
  • 空运行： "simplify but don't change anything" / "just report" → 运行 四个审查者，展示发现，不做任何应用。应用前先询问。
  • 范围： "simplify the last commit" / "simplify staged" / "simplify src/foo.py" → 相应地缩小 diff 来源（见第 1 阶段）。

不要每次编辑后都自动运行此技能，也不要把它附加到无关任务的末尾。 它会消耗相当于四个子智能体的 token——仅在用户明确要求时调用。

流程​

第 1 阶段 — 确定变更范围​

捕获要审查的 diff。根据用户的要求选择来源，按以下默认顺序：

# 1. Default: uncommitted working-tree changes (tracked files)
git diff

# 2. If that's empty, include staged changes
git diff HEAD

# 3. Scoped variants the user may request:
git diff --staged                 # "staged changes"
git diff HEAD~1                    # "the last commit"
git diff main...HEAD              # "this branch" / "my PR"
git diff -- src/foo.py            # specific file(s)

如果 git diff 和 git diff HEAD 均为空，且没有 git 仓库或没有任何 变更，则回退到用户明确指定的文件，或本会话中最近创建/编辑的 文件。如果你确实找不到任何更改过的代码，请说明并停止——没有什么 可以简化。

捕获完整的 diff 文本。注意其大小：如果它非常大（比如变更超过 2000 行），请警告用户，每个子智能体都携带完整 diff 会消耗大量 token，并提供先缩小范围（按目录、按提交）再继续。

阶段 2 — 并行启动四个审查者​

使用 delegate_task 的批处理模式——把所有四个任务放进一个 tasks 数组里让它们并发运行。对于这个模式，四路 fan-out 是合适的；它在任何默认安装下都不会超出 delegation.max_concurrent_children 预算。

无法使用委派？ 如果你在当前上下文中无法调用 delegate_task（你是一个叶子子智能体、委派被禁用，或者预算耗尽），不要跳过审查或丢弃维度。在当前上下文中自己按顺序走完所有四个审查角度——相同的搜索标准、相同的问题报告格式。然后在最终总结里清楚说明这是一次单遍内联审查，不是并行 fan-out，让用户知道实际跑的是什么。

给每个审查者提供完整 diff（不是片段——跨文件问题就藏在缺口里），以及仓库绝对路径，让他们能搜索更广的代码库。每个审查者拿到 terminal、file 和 search 工具集（这样他们能用 git、read_file 以及 search_files/grep）。

告诉每个审查者：

  • 在现有代码库中搜索证据（不要仅凭 diff 推理）。
  • 应用切斯特顿栅栏（Chesterton's Fence）： 在标记任何东西待删除之前，对该行运行 git blame，理解它为什么存在。如果你无法确定原始用途，标记为 confidence: low——不要猜。
  • 以结构化输出报告发现，包含具体成本、置信度和风险： 
    file:line → problem → cost (what's duplicated/wasted/harder to maintain) → suggested fix | confidence: high/medium/low | risk: SAFE/CAREFUL/RISKY
    cost 字段迫使每条发现为自己辩护——一条无法说明问题实际代价的发现很可能只是吹毛求疵。
    • SAFE = 已证明不影响行为（未使用的导入、被注释掉的代码、直通包装器）。自动应用这些。
    • CAREFUL = 在不为改变语义的前提下有所改进（重命名局部变量、展平嵌套三元、提取辅助函数）。在测试验证下应用。
    • RISKY = 可能改变行为或破坏公共契约（N+1 重构、公共 API 重命名、内存生命周期变更）。标记给人类审查——不要自动应用。
  • 跳过吹毛求疵和纯风格上的改动。只标记能实质性改进代码的东西。

传递这四个目标（剔除用户关注范围排除的任何目标）：

审查者 1 — 代码复用

审查此 diff 中是否存在重复代码库中已有功能的情况。搜索工具模块、共享辅助函数以及相邻文件（使用 search_files / grep），寻找新代码本可以调用而不必重新实现的现有函数、常量或模式。标记：重复已有函数的新函数；现有工具已经做的手写逻辑（手动字符串/路径操作、自定义环境检查、临时代码类型守卫、重新实现的解析）。对每一条，指明要使用的现有东西以及它所在的位置。

审查者 2 — 代码质量

审查此 diff 的质量问题。寻找：冗余状态（重复或可从现有状态派生的值；不需要存在的缓存）；参数膨胀（本该重构函数时却硬塞进去的新参数）；带变化的复制粘贴（本应共享抽象的近重复代码块）；泄漏的抽象（暴露内部细节、破坏现有封装边界）；字符串类型代码（本应使用已存在的常量/枚举/注册表时却用原始字符串——标记前先检查规范注册表）；深层嵌套条件（三元链、3 层及以上的 if/else 金字塔——用守卫子句、提前返回或查找表来展平）；AI 生成的粗制滥造模式（多余注释复述显而易见的代码，比如 count++ 上方的 // increment counter；对已经验证过的输入做不必要的防御性 null 检查；绕过类型系统的 as any 强制转换；与文件其余部分不一致的模式）。对每一条，给出具体的重构方案。

审查者 3 — 效率

审查此 diff 的效率问题。寻找：不必要的工作（冗余计算、重复文件读取、重复 API 调用、N+1 访问模式）；错失的并发机会（本来独立的操作被顺序执行）；热路径臃肿（启动时或每请求路径上的繁重/阻塞工作）；TOCTOU 反模式（在操作前做存在性预检查，而不是执行操作并处理错误）；内存问题（无界增长、缺失的清理、监听器/句柄泄漏；长生命周期的回调或作为闭包构建、捕获了整个外围作用域的对象——捕获的东西只要对象活着就一直活着，所以优先用一个小类或只复制自己需要字段的显式字段结构体）；过宽的读取（一个切片就够时加载整个文件）；静默失败（空的 catch 块、被忽略的错误返回、except: pass、没有处理逻辑的 .catch(() => {})、错误传播缺口——这些会隐藏 bug，至少应该在吞掉之前记录日志）。对每一条，给出具体修复方案以及为什么它更快或更安全。

审查者 4 — 层级

审查此 diff 中实现深度错误的变更——在共享基础设施之上叠加创可贴式修补，而不是修复基础设施本身。修复过浅的迹象：在通用代码路径中为一个调用者添加的特例（一个 if (caller == X) 分支、一次类型检查、一个魔法值逃生舱口）；在调用点修补症状，而兄弟调用点仍保留同样的缺陷；在早先的变通方法之上再叠加一个变通方法；为避免触碰真正需要改变的东西而添加一个包装器；引入配置或标志来绕过损坏的默认值，而不是修复该默认值。对每一条，识别该变更正在回避的底层机制，并描述更深的修复——泛化共享路径、修复根默认值，或者修复整个 bug 类别——并诚实地说明该更深修复是否大到足以成为独立任务，而非本次清理的一部分。先阅读周边代码和 git blame：看起来像创可贴的东西有时是刻意的边界（兼容垫片、分阶段迁移、vendored 代码隔离）。不要标记这些。

阶段 3 — 汇总并应用​

等待四个审查者全部返回（批发模式下会一起返回）。

  1. 合并发现结果为一个列表，对审查者重叠的部分去重 —— 当两条发现针对同一行或同一底层机制时， 将它们合并为一条。
  2. 丢弃误报 —— 你拥有最多的上下文；你不必 与审查者争论，只需默默丢弃薄弱或错误的建议。
  3. 解决冲突。 审查者可能意见不一致（审查者 1：“使用现有的 工具 X”；审查者 3：“X 很慢，内联它”）。默认解决顺序： 正确性 > 用户声明的关注点 > 可读性/复用 > 微性能。 不要应用有损清晰度的性能“修复”，除非该路径确实是 热路径。当两个建议互斥且都站得住脚时，选择 改动代码更少的那个，并注明另一种方案。
  4. 按风险层级顺序应用：
    • 安全项优先（自动应用）：未使用的导入、被注释掉的代码、 直通包装器、多余的类型断言。之后运行测试。
    • 谨慎项其次（应用并验证，一次一个文件）：重命名 局部变量、展平三元表达式、提取辅助函数、合并重复项。每改动一个文件后 运行测试。任何导致破坏的改动都回滚。
    • 风险项最后（标记待审查 —— 不要自动应用）：N+1 重构、 公共 API 变更、并发修复、错误处理变更。逐一呈现 风险描述和测试覆盖状态。高度层级发现 通常落在这里 —— 更深的修复意味着触及共享 基础设施，因此呈现更深的修复并让用户决定 是现在做还是作为后续跟进。 如果用户选择了 dry run，呈现全部三个层级且不应用任何改动。
  5. 验证你没有破坏任何东西：对触及的文件运行项目的定向测试 （不是完整套件），并重新运行仓库使用的任何 linter/类型检查。 如果某个修复导致测试失败，回滚该修复并报告。
  6. 总结你所做的更改：按审查者类别和风险层级分组的 已应用修复简短列表，以及你有意跳过的任何发现及原因。 如果你是内联运行（无委派），在此说明。

陷阱​

  • 不要拆分超过 4 个。 更多审查者意味着更高成本和更多 需要调和相互冲突的建议，而不是更好的覆盖。四个 类别已覆盖整个空间。
  • 给每个审查者完整的 diff。 将 diff 拆分给多个审查者 会破坏设计 —— 跨文件重复和 N+1 只有在 全貌下才会显现。
  • 审查者是搜索，不是猜测。 没有指向现有 工具的引用（“这大概有个 helper”）的复用发现是噪声。要求 file:line 证据；丢弃缺少证据的发现。
  • 应用 ≠ 重写。 这是对用户最近改动的清理，不是 重构整个模块的许可。保持编辑范围在 diff 触及的内容 加上修复所需的最小周边改动。高度 层级发现是证明规则的例外：当正确的修复 比 diff 更深时，标记它 —— 不要在清理过程中单方面重建 共享机制。
  • 不要漂移进 bug 猎捕。 如果审查者浮现出一个真正的 正确性 bug，显著地报告它 —— 但作为单独的“发现了一个 bug” 备注，不要折叠进清理修复中。正确性审查是不同 的环节，有不同的验证标准。
  • 尊重项目约定。 如果仓库有 AGENTS.md / CLAUDE.md / HERMES.md 或 linter 配置，将这些规则折入审查者提示， 使建议符合项目风格而非与之对抗。
  • 巨型 diff 会撑爆上下文。 如果 diff 很大，在委派前 缩小范围 —— 四个子智能体各自携带 5000 行 diff 既昂贵又 可能截断。
  • 过度信任死代码工具。 knip、ts-prune 和 depcheck 会标记 被动态使用的导出（基于字符串的导入、反射）。移除前 始终 grep 符号名 —— 干净的工具报告不是证据。
  • 不看公共契约就重命名。 导出名、API 路由 路径、数据库列名和配置键都是契约 —— 即使名字很糟糕， 重命名也会破坏使用者。将公共契约变更标记为风险项；绝不 自动重命名它们。
  • 移除“不必要”的错误处理。 空的 catch 块或被忽略的 错误可能是有意的 —— 该错误在该上下文中是预期且无害的。 标记它，不要移除它；让人类决定。
  • 不是每个特殊情况都是创可贴。 为 vendored 代码包着的兼容垫片、 分阶段迁移和隔离层看起来像高度违规，但 是有意设计。标记前检查 git blame 和周边注释； 当意图不明时，标记 confidence: low。

相关​

如果你的安装包含 subagent-driven-development 技能（可选），它 涵盖互补的情况：实现期期间的逐任务并行审查。本技能 是独立的事后清理环节。使用 requesting-code-review 进行提交前的安全/质量门禁 —— 那是 bug 猎捕；这是清理。