Deepseek-V4
Minimax-M2.7
Kimi-k2.6简化代码
并行使用 3 个代理清理最近的代码更改。
技能元数据
| 来源 | 捆绑（默认安装） |
| 路径 | skills/software-development/simplify-code |
| 版本 | 1.0.0 |
| 作者 | Hermes Agent（灵感来自 Claude Code /simplify） |
| 许可证 | MIT |
| 平台 | linux, macos, windows |
| 标签 | code-review, cleanup, refactor, delegation, subagent, parallel, simplify |
| 相关技能 | requesting-code-review, test-driven-development, plan |
参考：完整 SKILL.md
以下是触发此技能时 Hermes 加载的完整技能定义。这是技能激活时代理看到的指令。
简化代码 — 并行审查与清理
通过三个专注的审查者并行运行，审查你最近的代码更改，汇总他们的发现，并应用值得应用的修复。
核心原则： 三个狭窄的审查者胜过一个是宽泛的审查者。每个审查者深入搜索代码库以查找单一类别的问题——复用、质量、效率——而不会将注意力分散到所有三个方面。它们并发运行，因此你只需支付一次审查的延迟，而不是三次。
何时使用
当用户说出以下任何内容时，触发此技能：
- "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（质量）、efficiency（效率）。 - 干跑： "simplify but don't change anything" / "just report"（简化但不要更改任何内容 / 仅报告）→ 运行三个审查者，展示发现，不应用任何更改。在应用前询问。
- 范围： "simplify the last commit" / "simplify staged" / "simplify src/foo.py"（简化最后一次提交 / 简化暂存区 / 简化 src/foo.py）→ 相应地缩小差异源（参见阶段 1）。
不要在每次编辑后自动运行此技能。它会消耗相当于三个子代理的 token —— 仅在用户明确要求时才调用它。
流程
阶段 1 — 识别更改
捕获要审查的差异。根据用户的要求，按以下默认顺序选择源：
# 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 行更改），警告用户三个子代理各自携带完整差异将会消耗大量 token，并在继续之前提供缩小范围（按目录、按提交）的选项。
阶段 2 — 并行启动三个审查者
使用 delegate_task 批处理模式 —— 将所有三个任务在一个 tasks 数组中传递，以便它们并发运行。对于这种模式，三个是合适的扇出数量；在任何默认安装中，这都在 delegation.max_concurrent_children 预算范围内。
给每个审查者提供完整的差异（不是片段——跨文件问题隐藏在间隙中）以及绝对仓库路径，以便他们可以搜索更广泛的代码库。每个审查者获得 terminal、file 和 search 工具集（以便他们可以使用 git、read_file 和 search_files/grep）。
告诉每个审查者：
- 搜索现有代码库以获取证据（不要仅从差异中进行推理）。
- 将发现报告为具体列表：
file:line → problem → suggested fix（文件:行号 → 问题 → 建议修复）。 - 对每个发现排名
high/medium/low（高 / 中 / 低）置信度。 - 跳过吹毛求疵和仅涉及风格的变动。仅标记那些能实质性改进代码的内容。
传递这三个目标（删除用户焦点排除的任何目标）：
审查者 1 — 代码复用
审查此差异，查找重复代码库中已有功能的代码。搜索实用模块、共享辅助程序和相邻文件（使用 search_files / grep）以查找现有函数、常量或模式，新代码可以调用它们而不是重新实现。标记：重复现有函数的新函数；现有实用程序已经完成的手写逻辑（手动字符串/路径操作、自定义环境检查、临时类型守卫、重新实现的解析）。对于每个标记，命名要使用的现有事物及其位置。
Reviewer 2 — 代码质量
审查此差异（diff）中的质量问题。查找：冗余状态（重复或可从现有状态派生的值；不必要的缓存）；参数蔓延（在应重构函数的地方强行添加新参数）；带变体的复制粘贴（应共享抽象的近重复代码块）；泄露的抽象（暴露内部实现，破坏现有的封装边界）；字符串类型化代码（在已有常量/枚举/注册表的情况下使用原始字符串——在标记前请检查规范注册表）。针对每一项，给出具体的重构方案。
Reviewer 3 — 效率
审查此差异（diff）中的效率问题。查找：不必要的工作（冗余计算、重复文件读取、重复 API 调用、N+1 访问模式）；错失的并发机会（独立操作顺序执行）；热点路径膨胀（启动时或每个请求路径上的繁重/阻塞工作）；TOCTOU 反模式（在执行操作前进行存在性预检查，而不是直接执行操作并处理错误）；内存问题（无限制增长、缺少清理、监听器/句柄泄漏）；过于宽泛的读取（加载整个文件，而实际上只需切片部分）。针对每一项，给出具体的修复方案，并说明为何它更快或更轻量。
阶段 3 — 汇总与应用
等待所有三个评审员返回（批处理模式会一起返回它们）。
- 合并发现结果到一个列表中，去除评审员重叠部分的重复项。
- 丢弃误报——你拥有最多的上下文；无需与评审员争辩，只需静默地丢弃薄弱或错误的建议。
- 解决冲突。 评审员可能会意见相左（评审员 1：“使用现有工具 X”；评审员 3：“X 很慢，将其内联”）。默认解决顺序为：正确性 > 用户声明的重点 > 可读性/复用性 > 微性能。 除非路径确实是热点，否则不要应用损害清晰度的性能“修复”。当两个建议互斥且都有道理时，选择触及代码较少的那个，并注明替代方案。
- 应用保留下来的修复，直接使用
patch/write_file——除非用户要求干跑（dry run），在这种情况下，先呈现列表并询问。 - 验证你没有破坏任何内容：运行受触文件的针对性测试（而非全套测试），并重新运行仓库使用的任何 linter/类型检查。如果某个修复破坏了测试，回滚该修复并报告。
- 总结你所做的更改：按评审员类别分组的已应用修复简短列表，以及你故意跳过的任何发现及其原因。
陷阱
- 不要将范围扩大到超过 ~3 个评审员。 更多的评审员意味着更高的成本和更多需要协调的冲突建议，而不是更好的覆盖率。三个类别足以覆盖该空间。
- 将完整的 diff 提供给每个评审员。 将 diff 拆分给不同评审员会违背设计初衷——跨文件重复和 N+1 问题只有在查看全貌时才会显现。
- 评审员进行搜索，而非猜测。 没有指向现有实用程序的指针的复用发现（“可能有为此准备的辅助函数”）是噪音。要求提供
file:line证据；丢弃缺乏此类证据的发现。 - 应用 ≠ 重写。 这是对用户最近更改的清理，而非重构整个模块的许可。保持编辑范围局限于 diff 触及的内容以及修复所需的最小周围更改。
- 尊重项目约定。 如果仓库有 AGENTS.md / CLAUDE.md / HERMES.md 或 linter 配置，将这些规则纳入评审员提示中，以便建议符合内部风格，而不是与之冲突。
- 大型 diff 会撑爆上下文。 如果 diff 巨大，在委托之前先缩小范围——三个子代理各自携带 5000 行的 diff 既昂贵又可能导致截断。
相关
如果你的安装包含 subagent-driven-development 技能（可选），它涵盖了互补的情况：在实现过程中并行审查，按任务进行。本技能是独立的事后清理步骤。使用 requesting-code-review 作为提交前的安全/质量门禁。