{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

Simplify Code

4 个并行 agent 清理近期代码变更。

Skill 元数据

参考：完整 SKILL.md

Simplify Code——并行评审与清理

用四个并行运行的聚焦评审者评审你的近期代码变更，聚合他们的发现，并应用值得应用的修复。

这是清理一轮，不是找 bug。 你在改善已经能工作的代码质量——去重、摊平不必要复杂度、砍浪费、加深创可贴修复。不要在这里找正确性 bug；那是 requesting-code-review 的事。

核心原则： 四个窄评审者胜过一个宽评审者。每个深挖代码库找单一类问题——复用、质量、效率、高度——不把注意力摊到四类上。它们并发运行，因此你付一次评审的延迟，而非四次。

何时使用

当用户说以下任何一句时触发本 skill：

• "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. 默认：未提交工作树变更（已跟踪文件）
git diff

# 2. 若空，含暂存变更
git diff HEAD

# 3. 用户可能请求的范围变体：
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            # 特定文件

若 git diff 和 git diff HEAD 都空、且无 git 仓库或无变更，回退到用户明确点名的文件，或本会话最近创建/编辑的文件。若你真找不到任何变更代码，说明并停下——没东西可简化。

捕获完整 diff 文本。注意大小：若很大（比如 >2000 变更行），警告用户四个各带完整 diff 的子代理会很费 token，并在继续前提供收窄（按目录、按 commit）。

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

用 delegate_task 批模式——在一个 tasks 数组里传全部四个任务，使它们并发运行。四是此模式的正确扇出；在任何默认安装的 delegation.max_concurrent_children 预算内。

无委派可用？ 若你在此上下文调不了 delegate_task（你是叶子子代理、委派被禁、或预算耗尽），不要跳过评审或丢角度。自己顺序过完四个评审者角度——相同搜索标准、相同发现格式。然后在最终摘要里明确说这是单趟内联评审，而非并行扇出，让用户知道实际跑了什么。

给每个评审者完整 diff（不要片段——跨文件问题藏在缝隙里）加绝对仓库路径，让他们搜更广代码库。每个评审者得 terminal、file 和 search 工具集（因此能 git、read_file、search_files/grep）。

告诉每个评审者：

• 在既有代码库搜证据（不要只从 diff 推理）。
• 应用切斯特顿栅栏： 在标记任何东西删除前，对该行跑 git blame 理解它为何存在。若你确定不了原始用途，标 confidence: low——不要猜。
• 以结构化输出报告发现，带具体成本、置信度和风险：

  file:line → 问题 → 成本（什么重复/浪费/更难维护）→ 建议修复 | confidence: high/medium/low | risk: SAFE/CAREFUL/RISKY
  

  成本字段强迫每个发现自证——说不出问题实际代价的发现大概是 nit。

  • SAFE = 证明不影响行为（未用导入、注释掉的代码、透传包装器）。自动应用。
  • CAREFUL = 改善但不改语义（重命名局部变量、摊平嵌套三元、提取辅助）。带测试验证应用。
  • RISKY = 可能改行为或破坏公开契约（N+1 重构、公开 API 重命名、内存生命周期变更）。标记人工评审——不自动应用。
• 跳过 nit 和纯风格 churn。只标记实质改善代码的。

传这四个目标（用户聚焦排除的就丢）：

评审者 1——代码复用

评审此 diff 中重复代码库已有功能的代码。搜工具模块、共享辅助和相邻文件（用 search_files / grep）找新代码本可调用而非重写的既有函数、常量或模式。标记：复制既有函数的新函数；既有工具已做的手搓逻辑（手动字符串/路径操作、自定义 env 检查、临时类型守卫、重写的解析）。每个都命名该用的既有东西及其位置。

评审者 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) 分支、类型检查、魔值逃生舱）；在调用点修症状而兄弟调用点保留同一缺陷；堆在更早 workaround 上的 workaround；为避免碰真正该改之物而加的包装器；引入配置或旗标绕行坏默认而非修默认。每个识别变更在回避的底层机制，描述更深修复——泛化共享路径、修根默认、或修整个 bug 类——并诚实注明何时更深修复大到该自成任务、而非本清理一部分。先读周围代码和 git blame：看似创可贴的有时是有意边界（兼容垫片、分阶段迁移、vendored 代码隔离）。不要标记那些。

阶段 3——聚合与应用

等全部四个返回（批模式一起返回）。

1. 合并发现成一个列表，评审者重叠处去重——两个发现瞄准同一行或同一底层机制时，折叠成一个。
2. 丢弃误报——你有最多上下文；不必跟评审者争，静默丢掉弱或错建议。
3. 解决冲突。 评审者可能不一致（评审者 1："用既有 util X"；评审者 3："X 慢，内联它"）。默认解决顺序：正确性 > 用户声明聚焦 > 可读性/复用 > 微性能。 除非路径真热，否则不要应用损害清晰度的性能"修复"。两个建议互斥且都站得住时，选碰代码少的，并注明另一个。
4. 按风险层序应用：
   • 先 SAFE（自动应用）：未用导入、注释掉的代码、透传包装器、冗余类型断言。之后跑测试。
   • 再 CAREFUL（带验证应用，一次一文件）：重命名局部、摊平三元、提取辅助、合并重复。每文件后跑测试。打破的就回滚。
   • 最后 RISKY（标记评审——不自动应用）：N+1 重构、公开 API 变更、并发修复、错误处理变更。每个带风险描述和测试覆盖状态呈交。高度发现通常落这——加深修复意味着碰共享基础设施，因此呈交更深修复，让用户决定现在做还是后续做。 若用户选了试跑，呈交三层，什么都不应用。
5. 验证你没打破任何东西：跑项目对触及文件的目标测试（不是全套），重跑仓库用的任何 linter/类型检查。若修复打破测试，回滚那个修复并报告。
6. 摘要你改了什么：按评审者类别和风险层分组的已应用修复短列表，加任何你有意跳过的发现及原因。若你内联跑（无委派），在这里说。

常见陷阱

• 不要扇出超过 4。 更多评审者意味着更多成本和更多要调和的冲突建议，而非更好覆盖。四类覆盖该空间。
• 给每个评审者整个 diff。 跨评审者拆分 diff 违背设计——跨文件重复和 N+1 只在全貌下出现。
• 评审者搜索，不猜。 无指向既有工具的复用发现（"这大概有个 helper"）是噪声。要求 file:line 证据；缺它就丢。
• 应用 ≠ 重写。 这是用户近期变更的清理，不是重构整个模块的许可。编辑限定在 diff 触及加修复所需的最小周围变更。高度发现是证明规则的例外：正确修复比 diff 深时，标记它——不要在清理一轮内单方面重建共享机制。
• 不要漂去找 bug。 若评审者浮出真正正确性 bug，显著报告——但作为单独"发现 bug"注记，不折进清理修复。正确性评审是不同一轮，有不同验证标准。
• 尊重项目约定。 若仓库有 AGENTS.md / CLAUDE.md / HERMES.md 或 linter 配置，把那些规则折进评审者 prompt，使建议贴合家风格而非与之斗。
• 大 diff 炸上下文。 若 diff 巨大，委派前收窄——四个各带 5000 行 diff 的子代理很贵且可能截断。
• 过度信任死代码工具。 knip、ts-prune、depcheck 标记的导出其实被动态用（字符串导入、反射）。删除前总 grep 符号名——干净工具报告不是证明。
• 不查公开契约就重命名。 导出名、API 路由路径、DB 列名和配置键是契约——即使名不好，重命名破坏消费者。把公开契约变更标 RISKY；绝不自动重命名。
• 删"不必要"错误处理。 空 catch 块或忽略错误可能有意——错误在该上下文预期且良性。标记，不删；让人决定。
• 不是每个特例都是创可贴。 兼容垫片、分阶段迁移和 vendored 代码周围的隔离层看似高度违规，却是有意设计。标记前查 git blame 和周围注释；意图不清时标 confidence: low。

相关

若你的安装有 subagent-driven-development skill（可选），它覆盖互补情况：实现期间按任务并行评审。本 skill 是独立的事后清理轮。用 requesting-code-review 做提交前安全/质量门——那是找 bug；这是清理。