name: simplify-code description: “Parallel 3-agent cleanup of recent code changes.” version: 1.0.0 author: Hermes Agent (inspired by Claude Code /simplify) license: MIT platforms: [linux, macos, windows] metadata: hermes: tags: [code-review, cleanup, refactor, delegation, subagent, parallel, simplify] related_skills: [requesting-code-review, test-driven-development, plan]

简化代码——并行审查与优化

通过同时运行三名专注的审查员来检查您最近的代码更改，汇总他们的发现，并仅应用那些确实需要修复的问题。

核心原则： 三名专注于特定领域的审查员优于一名面面俱到的审查员。每位审查员都会深入代码库，专门针对某一类问题——如代码复用、质量或效率——进行排查，而不会分散注意力。由于这些审查员是并行运行的，您只需承担一次审查的延迟，而非三次。

适用场景

当用户说出以下任意语句时，即可触发此功能：

• “简化” / “简化我的更改” / “优化这些更改”
• “审查我的代码” / “检查我最近的更改” / “优化我的更改”
• “/simplify”（适用于习惯使用 Claude Code 的用户）

用户可能还会添加一些可选参数——请予以尊重：

• 专注方向： “简化，重点关注效率” → 仅运行负责效率审查的审查员（或让汇总结果更侧重于效率方面）。支持的专注方向包括：复用、质量、效率。
• 模拟运行： “简化代码，但不要做任何修改” / “仅报告问题” → 运行三名审查员并呈现发现结果，但不实际应用任何修复。在实际应用前会先征得用户同意。
• 范围限制： “简化最后一次提交的代码” / “优化已暂存的更改” / “优化 src/foo.py 文件” → 按照要求缩小代码差异的审查范围（详见第一阶段）。

请勿在每次编辑后自动运行此功能。它需要消耗三个子智能体的计算资源——仅应在用户明确请求时才调用。

工作流程

第一阶段——确定要审查的更改

首先获取需要审查的代码差异。根据用户的请求选择对应的代码范围，默认顺序如下：

# 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 仓库也没有任何更改，那么就转而处理用户明确指定的文件，或是当前会话中最近创建/修改过的文件。如果确实找不到任何被修改的代码，请如实告知并停止操作——因为此时无需再做简化处理。

需完整捕获差异文本，并记录其大小：若文本体积极大（例如超过2000行改动），应提醒用户，同时启动三个分别处理完整差异的子智能体会消耗大量令牌，建议在继续之前缩小搜索范围（按目录或按提交来处理）。

第二阶段——并行启动三个审查智能体

使用 delegate_task 的批量模式，将三个任务一次性放入同一个 tasks 数组中，使其同步运行。对于这种处理方式而言，三个智能体是合适的数量；在任何默认配置下，这一数值都在 delegation.max_concurrent_children 的允许范围内。

需为每个审查智能体提供完整的差异内容（而非片段——跨文件的问题往往隐藏在片段间隙中），同时告知其仓库的完整路径，以便它们能搜索更广泛的代码库。每个审查智能体都会配备 terminal、file 和 search 工具集（从而能够执行 git、read_file 以及 search_files/grep 等操作）。

需告知每个审查智能体如下要求：

• 在现有代码库中搜索相关证据（切勿仅依据差异文本进行判断）；
• 遵循切斯特顿的准则：在标记任何代码需要删除之前，先对该行使用 git blame 命令，弄清楚其存在的原因。如果无法确定其最初的用途，请将其标记为 confidence: low——切勿主观猜测；
• 以结构化格式汇报检测结果，同时注明置信度和风险等级。

  file:line → problem → suggested fix | confidence: high/medium/low | risk: SAFE/CAREFUL/RISKY
  

• SAFE = 经验证不会影响代码行为（未使用的导入、被注释掉的代码、直接传递的包装器）。可自动应用这些修改。
• CAREFUL = 能在不改变语义的前提下提升代码质量（重命名局部变量、简化嵌套三元运算、提取辅助函数）。应用此类修改前需进行测试验证。
• RISKY = 可能会改变代码行为或破坏公共契约（N+1 查询结构优化、公共 API 重命名、内存生命周期变更）。此类修改需标记以便人工审核——严禁自动应用。

仅忽略无关的细节问题和纯风格层面的改动，仅标记那些能显著提升代码质量的内容。

请遵循以下三个目标（若用户未指定重点，则可省略）：

审核者 1 — 代码复用

审核该差分中是否存在重复利用代码库中已有功能的代码。通过搜索工具模块、共享辅助函数以及相关文件（可使用 search_files/grep），查找新代码可以调用而非重新实现的现有函数、常量或模式。需标记的内容包括：与现有功能重复的新函数；那些本应由现有工具处理的自定义逻辑（如手动字符串/路径操作、自定义环境检查、临时类型判断、重新实现的解析逻辑）。对于每一项，需指出应使用的现有功能及其所在位置。

审核者 2 — 代码质量

审核该差分中是否存在质量问题。重点关注：冗余状态（重复或可从现有状态推导出的值；不必要的缓存）；参数过多（本应重构函数却新增了过多参数）；类似但略有不同的复制粘贴代码（本应通过抽象共享的近似重复代码块）；存在漏洞的抽象设计（暴露内部实现，破坏现有的封装边界）；强制使用字符串类型的代码（明明已有常量/枚举/注册表却仍使用原始字符串——标记前请先查阅标准注册表）；AI 生成的低质量代码模式（如 count++ 上方出现 // increment counter 这类重复说明的注释；对已验证过的输入进行不必要的防御性空值检查；绕过类型系统的 as any 类型转换；与文件其他部分不一致的模式）。对于每一项，需给出具体的重构方案。

审核者 3 — 效率

审核该差分中是否存在效率问题。重点关注：不必要的操作（重复计算、多次读取文件、重复调用 API、N+1 访问模式）；未充分利用并发性（独立操作顺序执行）；热点路径性能低下（在启动时或每次请求时执行耗时/阻塞操作）；TOCTOU 错误模式（在操作前先进行存在性检查，而非直接执行操作并处理错误）；内存问题（内存无限制增长、缺乏清理机制、监听器/处理程序泄漏）；读取范围过宽（本只需读取部分内容却加载整个文件）；隐性故障（空的异常捕获块、被忽略的错误返回值、except: pass、.catch(() => {}) 且无处理逻辑、错误传播缺失——这些都会隐藏缺陷，至少应在吞掉错误前记录日志）。对于每一项，需给出具体的修复方案，并说明为何该方案能提升效率或安全性。

第三阶段 — 汇总与应用

等待三位审核者完成审核并返回结果（批量模式下会一次性返回所有结果）。

1. 合并各审核者的发现结果，若内容重复则去除。
2. 剔除误报——作为系统开发者，你拥有最全面的上下文，无需与审核者争论，可直接忽略那些不合理或错误的建议。
3. 解决冲突。审核者之间可能存在分歧（例如审核者 1 建议“使用现有工具 X”，而审核者 3 认为“X 效率低下，应内联处理”）。默认的解决优先级为：正确性 > 用户指定的重点 > 可读性/复用性 > 微性能优化。除非相关路径确实属于高频调用场景，否则不要为了提升性能而牺牲代码清晰度。当两个建议相互排斥但都有一定合理性时，选择改动范围更小的方案，并注明另一种方案的优缺点。
4. 按风险等级顺序应用修改：
   • 首先应用 SAFE 级别的修改（可自动应用）：未使用的导入、被注释掉的代码、直接传递的包装器、多余的类型断言。应用后需运行测试。
   • 接着应用 CAREFUL 级别的修改（应用前需验证，且每次仅处理一个文件）：重命名局部变量、简化三元运算、提取辅助函数、合并重复代码。每个文件处理完毕后需运行测试，若出现故障则恢复原状。
   • 最后处理 RISKY 级别的修改（需标记以便人工审核——严禁自动应用）：N+1 查询结构优化、公共 API 变更、并发问题修复、错误处理修改。针对每一项，需说明其风险点及测试覆盖情况。如果用户选择了试运行模式，则仅展示三个等级的修改结果，不实际应用任何修改。
5. 验证未破坏任何功能：针对被修改的文件运行项目中的相关测试（无需运行全部测试套件），并重新执行仓库中使用的所有代码检查工具和类型检查工具。如果某项修复导致了测试失败，则恢复该修改并报告问题。
6. 总结所做的更改：按审核者类别和风险等级列出已应用的修复方案，同时说明有意跳过的发现内容及其原因。

常见误区

• 审核者数量不宜超过 3 人。审核者越多，成本越高，需要协调的冲突建议也越多，反而无法实现更全面的审查。三个类别已足以覆盖所有需求。
• 需将整个差分内容提供给每位审核者。将差分拆分给不同审核者会破坏设计初衷——只有查看完整代码才能发现跨文件的重复问题及 N+1 查询问题。
• 审核者应基于实际查找，而非猜测。仅指出存在复用可能但未提供具体工具名称或文件行号的建议属于无效信息。必须要求提供 file:line 级别的证据，否则应忽略此类建议。
• 应用修改 ≠ 重新编写代码。此功能仅用于清理用户最近的修改，而非允许随意重构整个模块。所有编辑都应限制在差分涉及的范围内，以及修复方案所需的最低限度的周边改动。
• 需遵守项目规范。如果仓库中有 AGENTS.md/CLAUDE.md/HERMES.md 文件或代码检查配置文件，应将相关规则纳入审核提示中，确保建议符合项目风格，而非与之冲突。
• 过大的差分会导致上下文丢失。如果差分内容过于庞大，在分配给审核者之前应先缩小范围——让三个子代理各自处理 5000 行左右的差分既成本高昂，还可能因内容截断而影响审查效果。
• 过度依赖静态代码分析工具。knip、ts-prune 和 depcheck 等工具可能会标记出实际上会被动态使用的导出项（如基于字符串的导入、反射机制）。在删除之前，务必先通过 grep 查找该符号的实际使用位置——干净的工具报告并不能作为绝对依据。
• 重命名前需检查公共契约。导出名称、API 路径、数据库列名以及配置键值都属于公共契约的一部分——即使名称不理想，重命名仍可能影响其他模块的使用。将涉及公共契约的修改标记为 RISKY 级别，绝不能自动重命名。
• 不要随意删除“不必要的”错误处理代码。空的异常捕获块或被忽略的错误可能是有意为之——在特定场景下，该错误是预期中的且无害的。应标记此类情况而非直接删除，由人工决策如何处理。

相关内容

如果你的安装环境中包含了 subagent-driven-development 技能（可选），它可处理另一种互补场景：在实现代码的过程中，针对每个任务并行进行代码审查。该技能主要用于事后的代码清理工作。对于提交前的安全/质量检查，则应使用 requesting-code-review 功能。