simplify-code

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Simplify Code — Parallel Review & Cleanup

简化代码——并行审查与清理

Review your recent code changes with four focused reviewers running in parallel, aggregate their findings, and apply the fixes worth applying.

This is a cleanup pass, not a bug hunt. You are improving the quality of code that already works — removing duplication, flattening needless complexity, cutting waste, and deepening band-aid fixes. Do not go hunting for correctness bugs here; that's what

requesting-code-review

is for.

Core principle: Four narrow reviewers beat one broad reviewer. Each one deeply searches the codebase for a single class of problem — reuse, quality, efficiency, altitude — without diluting its attention across all four. They run concurrently, so you pay the latency of one review, not four.

通过四个专注的审查者并行运行，审查您近期的代码变更，汇总他们的发现，并应用值得修复的内容。

这是一次清理操作，而非漏洞排查。 您正在改进已正常运行代码的质量——消除重复代码、简化不必要的复杂度、削减冗余内容，并优化临时修复。请勿在此处排查正确性漏洞；那是

requesting-code-review

的用途。

核心原则： 四个专注的审查者胜过一个宽泛的审查者。每个审查者深入搜索代码库以寻找单一类型的问题——复用性、质量、效率、层级——不会分散注意力同时处理四类问题。他们并行运行，因此您只需承担一次审查的延迟，而非四次。

When to Use

适用场景

Trigger this skill when the user says any of:

"simplify" / "simplify my changes" / "simplify these changes"
"review my code" / "review my recent changes" / "clean up my changes"
"/simplify" (if they're carrying the Claude Code habit over)

Optional modifiers the user may add — honor them:

Focus: "simplify focus on efficiency" → run only the efficiency reviewer (or weight the aggregation toward it). Recognized focuses:
```
reuse
```
,
```
quality
```
(also accepts
```
simplification
```
),
```
efficiency
```
,
```
altitude
```
.
Dry run: "simplify but don't change anything" / "just report" → run the four reviewers, present findings, apply NOTHING. Ask before applying.
Scope: "simplify the last commit" / "simplify staged" / "simplify src/foo.py" → narrow the diff source accordingly (see Phase 1).

Do NOT auto-run this after every edit or tack it onto the end of unrelated tasks. It costs four subagents' worth of tokens — invoke it only when the user explicitly asks.

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

"简化" / "简化我的变更" / "简化这些变更"
"审查我的代码" / "审查我近期的变更" / "清理我的变更"
"/simplify"（如果用户延续了Claude Code的使用习惯）

用户可能添加的可选修饰词——请予以尊重：

聚焦： "简化时聚焦效率" → 仅运行效率审查者（或在汇总时侧重该审查结果）。可识别的聚焦方向：
```
reuse
```
（复用）、
```
quality
```
（质量，也接受
```
simplification
```
（简化））、
```
efficiency
```
（效率）、
```
altitude
```
（层级）。
试运行： "简化但不要修改任何内容" / "仅报告结果" → 运行四个审查者，展示发现，但不应用任何修改。应用前需询问用户。
范围： "简化最后一次提交" / "简化暂存的变更" / "简化src/foo.py" → 相应缩小差异源范围（参见阶段1）。

请勿在每次编辑后自动运行此技能，也不要将其附加到无关任务的末尾。这会消耗相当于四个子Agent的令牌——仅当用户明确请求时才调用它。

The Process

流程

Phase 1 — Identify the changes

阶段1——识别变更

Capture the diff to review. Pick the source by what the user asked for, in this default order:

bash

undefined

捕获需要审查的代码差异。根据用户的请求选择差异源，默认顺序如下：

bash

undefined

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

1. 默认：未提交的工作树变更（已跟踪文件）

git diff

2. If that's empty, include staged changes

2. 如果上述为空，则包含暂存的变更

git diff HEAD

3. Scoped variants the user may request:

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 # specific file(s)


If `git diff` and `git diff HEAD` are both empty and there's no git repo or no
changes, fall back to the files the user explicitly named or that were
recently created/edited in this session. If you genuinely can't find any
changed code, say so and stop — there's nothing to simplify.

Capture the full diff text. Note its size: if it's very large (say >2000
changed lines), warn the user that four subagents each carrying the full diff
will be token-heavy, and offer to scope it down (per-directory, per-commit)
before proceeding.

git diff --staged # "暂存的变更" git diff HEAD~1 # "最后一次提交" git diff main...HEAD # "此分支" / "我的PR" git diff -- src/foo.py # 指定文件


如果`git diff`和`git diff HEAD`均为空，且不存在git仓库或无变更，则退回到用户明确指定的文件，或本次会话中最近创建/编辑的文件。如果确实找不到任何变更的代码，请告知用户并停止——没有可简化的内容。

捕获完整的差异文本。注意其大小：如果差异非常大（例如超过2000行变更代码），请警告用户，四个子Agent各自携带完整差异会消耗大量令牌，并提议在继续之前缩小范围（按目录、按提交）。

Phase 2 — Launch four reviewers in parallel

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

Use

delegate_task

batch mode — pass all four tasks in one

tasks

array so they run concurrently. Four is the right fan-out for this pattern; it's within the

delegation.max_concurrent_children

budget on any default install.

No delegation available? If you can't call

delegate_task

in this context (you're a leaf subagent, delegation is disabled, or the budget is exhausted), do NOT skip the review or drop angles. Work through all four reviewer angles yourself, sequentially, in this context — same search standards, same finding format. Then say clearly in your final summary that this was a single-pass inline review, not the parallel fan-out, so the user knows what actually ran.

Give every reviewer the complete diff (not fragments — cross-file issues hide in the gaps) plus the absolute repo path so they can search the wider codebase. Each reviewer gets

terminal

file

, and

search

toolsets (so they can

git

read_file

, and

search_files

/grep).

Tell each reviewer to:

Search the existing codebase for evidence (don't reason from the diff alone).
Apply Chesterton's Fence: before flagging anything for removal, run
```
git blame
```
on the line to understand why it exists. If you can't determine the original purpose, mark it
```
confidence: low
```
— don't guess.
Report findings as structured output with the concrete cost, confidence, and risk:
```
file:line → problem → cost (what's duplicated/wasted/harder to maintain) → suggested fix | confidence: high/medium/low | risk: SAFE/CAREFUL/RISKY
```
The cost field forces each finding to justify itself — a finding that can't articulate what the problem actually costs is probably a nit.
- SAFE = proven not to affect behavior (unused imports, commented-out code, pass-through wrappers). Auto-apply these.
- CAREFUL = improves without changing semantics (rename local variable, flatten nested ternary, extract helper). Apply with test verification.
- RISKY = may change behavior or breaks public contracts (N+1 restructuring, public API rename, memory lifecycle change). Flag for human review — do NOT auto-apply.
Skip nits and style-only churn. Only flag things that materially improve the code.

Pass these four goals (drop any the user's focus excludes):

Reviewer 1 — Code Reuse

Review this diff for code that duplicates functionality already in the codebase. Search utility modules, shared helpers, and adjacent files (use search_files / grep) for existing functions, constants, or patterns the new code could call instead of reimplementing. Flag: new functions that duplicate existing ones; hand-rolled logic that an existing utility already does (manual string/path manipulation, custom env checks, ad-hoc type guards, re-implemented parsing). For each, name the existing thing to use and where it lives.

Reviewer 2 — Code Quality

Review this diff for quality problems. Look for: redundant state (values that duplicate or could be derived from existing state; caches that don't need to exist); parameter sprawl (new params bolted on where the function should have been restructured); copy-paste-with-variation (near-duplicate blocks that should share an abstraction); leaky abstractions (exposing internals, breaking an existing encapsulation boundary); stringly-typed code (raw strings where a constant/enum/registry already exists — check the canonical registries before flagging); deeply nested conditionals (ternary chains, 3+-level if/else pyramids — flatten with guard clauses, early returns, or a lookup table); AI-generated slop patterns (extra comments restating obvious code like
// increment counter
above
count++
; unnecessary defensive null-checks on already-validated inputs;
as any
casts that bypass the type system; patterns inconsistent with the rest of the file). For each, give the concrete refactor.

Reviewer 3 — Efficiency

Review this diff for efficiency problems. Look for: unnecessary work (redundant computation, repeated file reads, duplicate API calls, N+1 access patterns); missed concurrency (independent ops run sequentially); hot-path bloat (heavy/blocking work on startup or per-request paths); TOCTOU anti-patterns (existence pre-checks before an op instead of doing the op and handling the error); memory issues (unbounded growth, missing cleanup, listener/handle leaks; long-lived callbacks or objects built as closures that capture the whole enclosing scope — everything captured stays alive as long as the object does, so prefer a small class or explicit-fields struct that copies only what it needs); overly broad reads (loading whole files when a slice would do); silent failures (empty catch blocks, ignored error returns,
except: pass
,
.catch(() => {})
with no handling, error propagation gaps — these hide bugs and should at minimum log before swallowing). For each, give the concrete fix and why it's faster or safer.

Reviewer 4 — Altitude

Review this diff for changes implemented at the wrong depth — band-aids layered on top of shared infrastructure instead of fixes to the infrastructure itself. Signs of a too-shallow fix: a special case added to a generic code path to handle one caller (an
if (caller == X)
branch, a type check, a magic-value escape hatch); a symptom patched at the call site while sibling call sites keep the same flaw; a workaround stacked on an earlier workaround; a wrapper added to avoid touching the thing that actually needs changing; configuration or flags introduced to route around a broken default instead of fixing the default. For each, identify the underlying mechanism the change is dodging and describe the deeper fix — generalize the shared path, fix the root default, or fix the whole bug class — and honestly note when the deeper fix is large enough that it should be its own task rather than part of this cleanup. Read the surrounding code and
git blame
first: what looks like a band-aid is sometimes a deliberate boundary (compat shims, staged migrations, vendored-code isolation). Don't flag those.

使用

delegate_task

的批量模式——将四个任务一次性传入

tasks

数组，以便它们并发运行。四个是此模式的合适数量；在任何默认安装中，这都在

delegation.max_concurrent_children

的预算范围内。

无法使用委托？ 如果在此环境中无法调用

delegate_task

（您是叶子子Agent、委托已禁用，或预算已耗尽），请勿跳过审查或省略审查角度。在此环境中依次完成所有四个审查者的角度——遵循相同的搜索标准和发现格式。然后在最终摘要中明确说明这是一次单遍内联审查，而非并行分支审查，以便用户了解实际运行的流程。

为每个审查者提供完整的差异（而非片段——跨文件问题隐藏在片段间隙中）以及绝对仓库路径，以便他们搜索更广泛的代码库。每个审查者拥有

terminal

、

file

和

search

工具集（因此他们可以执行

git

命令、

read_file

以及

search_files

/grep）。

告知每个审查者：

搜索现有代码库以寻找证据（不要仅根据差异进行推理）。
遵循切斯特顿栅栏原则（Chesterton's Fence）： 在标记任何内容以进行移除之前，对该行执行
```
git blame
```
以了解其存在的原因。如果无法确定原始用途，标记为
```
confidence: low
```
——请勿猜测。
以结构化输出报告发现，包含具体成本、可信度和风险：
```
file:line → 问题 → 成本（重复/冗余/维护难度增加的内容）→ 建议修复 | confidence: high/medium/low | risk: SAFE/CAREFUL/RISKY
```
成本字段要求每个发现都能证明自身的合理性——无法明确说明实际问题成本的发现可能只是细枝末节。
- SAFE（安全） = 已证明不会影响行为（未使用的导入、注释掉的代码、透传包装器）。自动应用这些修复。
- CAREFUL（谨慎） = 在不改变语义的情况下进行改进（重命名局部变量、扁平化嵌套三元表达式、提取辅助函数）。应用后需进行测试验证。
- RISKY（风险） = 可能改变行为或破坏公共契约（N+1重构、公共API重命名、内存生命周期变更）。标记为需要人工审查——请勿自动应用。
跳过细枝末节和仅涉及风格的变更。仅标记能实质性提升代码质量的内容。

传递以下四个审查目标（排除用户聚焦方向之外的目标）：

审查者1——代码复用性

审查此差异中存在的、重复代码库中已有功能的代码。搜索工具模块、共享辅助函数和相邻文件（使用search_files / grep），寻找新代码可以调用而非重新实现的现有函数、常量或模式。标记：重复现有函数的新函数；现有工具已实现的手动编写逻辑（手动字符串/路径处理、自定义环境检查、临时类型守卫、重新实现的解析逻辑）。对于每个标记项，指明要使用的现有内容及其位置。

审查者2——代码质量

审查此差异中的质量问题。寻找：冗余状态（重复或可从现有状态派生的值；无需存在的缓存）；参数膨胀（在应重构函数的地方添加新参数）；复制粘贴变体（应共享抽象的近乎重复的代码块）；抽象泄漏（暴露内部实现、破坏现有封装边界）；字符串类型代码（应使用常量/枚举/注册表的原始字符串——标记前请检查规范注册表）；深度嵌套条件（三元表达式链、3层及以上的if/else金字塔——使用守卫子句、提前返回或查找表进行扁平化）；AI生成的冗余模式（在
count++
上方添加
// increment counter
这类复述明显代码的额外注释；对已验证输入进行不必要的空值检查；绕过类型系统的
as any
类型断言；与文件其余部分不一致的模式）。对于每个标记项，给出具体的重构方案。

审查者3——效率

审查此差异中的效率问题。寻找：不必要的操作（冗余计算、重复文件读取、重复API调用、N+1访问模式）；错失的并发机会（独立操作按顺序运行）；热路径膨胀（启动或每个请求路径上的繁重/阻塞操作）；TOCTOU反模式（操作前进行存在性预检查，而非执行操作并处理错误）；内存问题（无限制增长、缺失清理、监听器/句柄泄漏；作为闭包构建的长期回调或对象捕获整个封闭作用域——捕获的所有内容会与对象一样长时间存活，因此首选复制仅需内容的小型类或显式字段结构体）；过度宽泛的读取（仅需切片时加载整个文件）；静默失败（空catch块、忽略错误返回、
except: pass
、无处理的
.catch(() => {})
、错误传播间隙——这些会隐藏漏洞，至少应在吞掉错误前进行日志记录）。对于每个标记项，给出具体的修复方案以及为何它更快或更安全。

审查者4——层级合理性

审查此差异中在错误层级实现的变更——在共享基础设施之上添加临时修复，而非修复基础设施本身。修复过浅的迹象：在通用代码路径中添加特殊情况以处理一个调用方（
if (caller == X)
分支、类型检查、魔术值逃生舱口）；在调用站点修补症状，而其他调用站点仍存在相同缺陷；在早期临时修复之上叠加新的临时修复；添加包装器以避免修改实际需要变更的内容；引入配置或标志以规避损坏的默认值，而非修复默认值。对于每个标记项，识别变更所规避的底层机制，并描述更深入的修复方案——泛化共享路径、修复根本默认值或修复整个漏洞类别——并如实说明当更深入的修复足够大时，应将其作为单独任务而非此次清理的一部分。先阅读周围代码和
git blame
：看似临时修复的内容有时是故意设置的边界（兼容性垫片、分阶段迁移、第三方代码隔离层）。请勿标记这些内容。

Phase 3 — Aggregate and apply

阶段3——汇总与应用

Wait for all four to return (batch mode returns them together).

Merge the findings into one list, deduping where reviewers overlap — when two findings target the same line or the same underlying mechanism, collapse them into one.
Discard false positives — you have the most context; you don't have to argue with a reviewer, just drop weak or wrong suggestions silently.
Resolve conflicts. Reviewers can disagree (Reviewer 1: "use existing util X"; Reviewer 3: "X is slow, inline it"). Default resolution order: correctness > the user's stated focus > readability/reuse > micro-perf. Don't apply a perf "fix" that hurts clarity unless the path is genuinely hot. When two suggestions are mutually exclusive and both defensible, pick the one that touches less code and note the alternative.
Apply in risk-tier order:
- SAFE first (auto-apply): unused imports, commented-out code, pass-through wrappers, redundant type assertions. Run tests after.
- CAREFUL next (apply with verification, one file at a time): rename locals, flatten ternaries, extract helpers, consolidate dupes. Run tests after each file. Revert any that break.
- RISKY last (flag for review — do NOT auto-apply): N+1 restructuring, public API changes, concurrency fixes, error-handling changes. Present each with risk description and test coverage status. Altitude findings usually land here — deepening a fix means touching shared infrastructure, so present the deeper fix and let the user decide whether to do it now or as a follow-up. If the user opted for a dry run, present all three tiers and apply nothing.
Verify you didn't break anything: run the project's targeted tests for the touched files (not the full suite), and re-run any linter/type check the repo uses. If a fix breaks a test, revert that one fix and report it.
Summarize what you changed: a short list of applied fixes grouped by reviewer category and risk tier, plus any findings you deliberately skipped and why. If you ran inline (no delegation), say so here.

等待所有四个审查者返回结果（批量模式会一并返回）。

合并发现结果为一个列表，去除审查者之间重叠的内容——当两个发现针对同一行或同一底层机制时，将它们合并为一项。
丢弃误报——您拥有最多上下文；无需与审查者争论，只需默默删除薄弱或错误的建议。
解决冲突。审查者可能存在分歧（审查者1：“使用现有工具X”；审查者3：“X速度慢，内联实现”）。默认解决顺序：正确性 > 用户指定的聚焦方向 > 可读性/复用性 > 微性能。除非路径确实是热路径，否则不要应用损害清晰度的性能“修复”。当两个建议互斥且均合理时，选择修改代码更少的那个，并注明替代方案。
按风险层级顺序应用：
- 先应用SAFE（安全）级修复（自动应用）：未使用的导入、注释掉的代码、透传包装器、冗余类型断言。应用后运行测试。
- 接下来应用CAREFUL（谨慎）级修复（逐一文件应用并验证）：重命名局部变量、扁平化三元表达式、提取辅助函数、合并重复代码。每个文件应用后运行测试。回滚任何导致失败的修复。
- 最后处理RISKY（风险）级修复（标记为需要审查——请勿自动应用）：N+1重构、公共API变更、并发修复、错误处理变更。每个修复都需附带风险描述和测试覆盖状态。层级合理性发现通常属于此类——深化修复意味着修改共享基础设施，因此需展示更深入的修复方案，让用户决定是现在进行还是作为后续任务。如果用户选择试运行，展示所有三个层级的发现但不应用任何修复。
验证未破坏任何内容：针对修改的文件运行项目的针对性测试（而非完整测试套件），并重新运行仓库使用的任何代码检查工具/类型检查工具。如果某个修复导致测试失败，回滚该修复并报告。
总结所做的变更：按审查者类别和风险层级分组的已应用修复简短列表，以及您故意跳过的任何发现及其原因。如果您运行的是内联审查（无委托），请在此处说明。

Pitfalls

注意事项

Don't fan out wider than 4. More reviewers means more cost and more conflicting suggestions to reconcile, not better coverage. The four categories cover the space.
Give the WHOLE diff to each reviewer. Splitting the diff across reviewers defeats the design — cross-file duplication and N+1s only show up with the full picture.
Reviewers search, they don't guess. A reuse finding with no pointer to the existing utility ("there's probably a helper for this") is noise. Require
```
file:line
```
evidence; drop findings that lack it.
Apply ≠ rewrite. This is cleanup of the user's recent changes, not a license to refactor the whole module. Keep edits scoped to what the diff touched plus the minimal surrounding change a fix requires. Altitude findings are the exception that proves the rule: when the right fix is deeper than the diff, FLAG it — don't unilaterally rebuild the shared mechanism inside a cleanup pass.
Don't drift into bug-hunting. If a reviewer surfaces a genuine correctness bug, report it prominently — but as a separate "found a bug" note, not folded into cleanup fixes. Correctness review is a different pass with different verification standards.
Respect project conventions. If the repo has AGENTS.md / CLAUDE.md / HERMES.md or a linter config, fold those rules into the reviewer prompts so suggestions match house style instead of fighting it.
Large diffs blow context. If the diff is huge, scope it down before delegating — four subagents each carrying a 5000-line diff is expensive and may truncate.
Over-trusting dead code tools.
```
knip
```
,
```
ts-prune
```
, and
```
depcheck
```
flag exports that ARE used dynamically (string-based imports, reflection). Always grep for the symbol name before removing — a clean tool report is not proof.
Renaming without checking public contracts. Export names, API route paths, DB column names, and config keys are contracts — even if the name is bad, renaming breaks consumers. Tag public-contract changes as RISKY; never auto-rename them.
Removing "unnecessary" error handling. An empty catch block or ignored error might be intentional — the error is expected and benign in that context. Flag it, don't remove it; let the human decide.
Not every special case is a band-aid. Compat shims, staged migrations, and isolation layers around vendored code look like altitude violations but are deliberate design. Check
```
git blame
```
and surrounding comments before flagging; when the intent is unclear, mark
```
confidence: low
```
.

分支数量不要超过4个。更多审查者意味着更高的成本和更多需要调和的冲突建议，而非更好的覆盖范围。这四个类别已涵盖所有场景。
为每个审查者提供完整的差异。将差异拆分给不同审查者违背了设计初衷——跨文件重复和N+1问题只有在完整视图下才会显现。
审查者需搜索，而非猜测。没有指向现有工具的复用性发现（“可能有一个辅助函数可以处理这个”）是无效信息。要求提供
```
file:line
```
证据；删除缺乏证据的发现。
应用≠重写。这是对用户近期变更的清理，而非重构整个模块的许可。保持编辑范围仅限于差异涉及的内容，以及修复所需的最小周边变更。层级合理性发现是例外中的规则：当正确的修复比差异更深入时，标记它——不要在清理操作中单方面重建共享机制。
不要陷入漏洞排查。如果审查者发现真正的正确性漏洞，请突出报告——但作为单独的“发现漏洞”说明，而非纳入清理修复中。正确性审查是不同的流程，有不同的验证标准。
尊重项目约定。如果仓库有AGENTS.md / CLAUDE.md / HERMES.md或代码检查配置，请将这些规则纳入审查者提示中，使建议符合项目风格而非与之冲突。
大型差异会超出上下文范围。如果差异非常大，请在委托前缩小范围——四个子Agent各自携带5000行差异的成本很高，且可能被截断。
不要过度信任死代码工具。
```
knip
```
、
```
ts-prune
```
和
```
depcheck
```
会标记动态使用的导出（基于字符串的导入、反射）。删除前始终grep搜索符号名称——工具的干净报告并非证明。
重命名前检查公共契约。导出名称、API路由路径、数据库列名和配置键都是契约——即使名称不佳，重命名也会破坏消费者。将公共契约变更标记为RISKY；永远不要自动重命名它们。
不要删除“不必要的”错误处理。空catch块或忽略错误可能是故意的——在该上下文中错误是预期且无害的。标记它，不要删除；让人工决定。
并非所有特殊情况都是临时修复。兼容性垫片、分阶段迁移和第三方代码隔离层看似违反层级合理性，但却是故意的设计。标记前请检查
```
git blame
```
和周围注释；当意图不明确时，标记为
```
confidence: low
```
。