Back to Details

simplify

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Simplify

代码简化

Use this skill to improve recently changed code without changing what it does.
本技能用于在不改变代码功能的前提下，优化近期修改的代码。

Usage

使用方式

Use the current uncommitted diff by default.
If the caller provides a base ref, compare that ref to 
HEAD
before reviewing. Typical refs:
  • HEAD~3
  • main
  • a specific commit SHA
When the runtime exposes a 
/simplify
command, inputs like 
/simplify HEAD~3
and 
/simplify main
should map to that same workflow. Otherwise, treat the requested ref as the review base inside this portable skill.
默认使用当前未提交的代码差异。
如果调用者提供了基准引用（ref），则在审查前将该引用与
HEAD
进行对比。常见的引用包括：
  • HEAD~3
  • main
  • 特定提交SHA值
当运行环境提供
/simplify
命令时，
/simplify HEAD~3
和
/simplify main
这类输入应映射到相同的工作流程。否则，在本可移植技能中，将请求的引用视为审查基准。

Workflow

工作流程

1. Scope the review

1. 确定审查范围

  • If a base ref was provided, use 
    git diff <base-ref>..HEAD
    to review all changes from that reference to 
    HEAD
    .
  • Otherwise, prefer the current diff first.
  • Use 
    git diff
    for unstaged changes, or 
    git diff HEAD
    when staged changes exist and you want the full working-tree delta.
  • If there are no git changes, review files the user named or files you edited earlier in the session.
  • Keep the scope narrow unless the user asks for a broader refactor.
  • 如果提供了基准引用，使用
    git diff <base-ref>..HEAD
    来审查从该引用到
    HEAD
    的所有变更。
  • 否则，优先使用当前的代码差异。
  • 对于未暂存的变更，使用
    git diff
    ；如果存在已暂存的变更，且需要查看完整工作区的差异，则使用
    git diff HEAD
    。
  • 如果没有Git变更，则审查用户指定的文件或会话中之前编辑过的文件。
  • 除非用户要求更广泛的重构，否则保持审查范围尽可能狭窄。

2. Run three review passes

2. 执行三轮审查

Use parallel sub-agents when available. Give each pass the full diff or exact changed files plus enough surrounding context to make concrete recommendations. If parallel delegation is unavailable, do the same passes yourself sequentially.
若支持并行子Agent，则使用并行方式执行。为每一轮审查提供完整的代码差异或具体的变更文件，以及足够的上下文信息，以提出具体的改进建议。若不支持并行委托，则依次执行三轮审查。

Pass A: Reuse

A阶段：复用性优化

  • Search for existing helpers, utilities, shared components, common types, and adjacent patterns before keeping new code.
  • Replace duplicated or near-duplicate logic with an existing abstraction when that reduces complexity.
  • Prefer existing constants, enums, shared helpers, and common validation/parsing code over new ad hoc logic.
  • 在保留新代码之前，先查找现有的辅助函数、工具类、共享组件、通用类型和类似的实现模式。
  • 当可以降低复杂度时，用现有的抽象逻辑替换重复或近乎重复的代码。
  • 优先使用现有的常量、枚举、共享辅助函数和通用验证/解析代码，而非新增临时逻辑。

Pass B: Quality

B阶段：代码质量优化

  • Remove redundant state, cached values that can be derived, unnecessary observers/effects, and dead branches.
  • Reduce parameter sprawl. Prefer reshaping interfaces over threading more booleans, flags, or one-off options.
  • Collapse copy-paste variants into a shared abstraction when it improves readability.
  • Fix leaky abstractions, unclear naming, and control flow that is harder to follow than necessary.
  • Prefer explicit, readable code over clever compression.
  • Avoid style-only churn that does not improve maintainability.
  • 移除冗余状态、可推导的缓存值、不必要的观察者/副作用以及无效分支。
  • 减少参数冗余。优先调整接口设计，而非添加更多布尔值、标志位或一次性选项。
  • 将复制粘贴的变体代码整合为共享抽象，以提升可读性。
  • 修复抽象泄露、命名模糊以及难以理解的控制流。
  • 优先选择明确、易读的代码，而非巧妙但晦涩的压缩写法。
  • 避免仅修改代码风格但未提升可维护性的无意义变更。

Pass C: Efficiency

C阶段：性能效率优化

  • Remove repeated work, duplicate I/O, N+1 patterns, and redundant computation.
  • Parallelize independent operations when the codebase and runtime make that safe.
  • Keep hot paths lean: startup code, request handlers, render paths, tight loops, and frequently called helpers.
  • Avoid pre-checking file or resource existence when it is cleaner to perform the operation and handle the error directly.
  • Watch for unbounded collections, missing cleanup, leaked listeners, and long-lived resources that never get released.
  • 移除重复操作、重复I/O、N+1查询模式以及冗余计算。
  • 在代码库和运行时支持的情况下，并行化独立操作。
  • 保持热点路径精简：启动代码、请求处理器、渲染路径、循环密集型代码以及频繁调用的辅助函数。
  • 当直接执行操作并处理错误更简洁时，避免预先检查文件或资源是否存在。
  • 注意无界集合、缺失的清理操作、泄露的监听器以及从未释放的长期资源。

3. Fix worthwhile issues directly

3. 直接修复有价值的问题

  • Aggregate the findings and fix high-confidence issues that materially improve the code.
  • Skip false positives, speculative architecture changes, and low-value nits.
  • Preserve behavior, public APIs, tests, and user-visible output unless the user explicitly asked for behavioral changes.
  • 汇总审查结果，修复那些能切实提升代码质量的高可信度问题。
  • 跳过误报、推测性架构变更以及低价值的细微问题。
  • 除非用户明确要求变更功能，否则保留原有行为、公共API、测试和用户可见的输出。

4. Validate the result

4. 验证结果

  • Run focused validation for the touched area when practical: relevant tests, lint, typecheck, or a targeted build step.
  • Prefer the smallest validation that can catch likely regressions.
  • If validation is unavailable or too expensive for the moment, say what you did not run.
  • 若可行，对修改区域进行针对性验证：相关测试、代码检查、类型校验或定向构建步骤。
  • 优先选择能够发现潜在回归问题的最小验证范围。
  • 如果暂时无法进行验证或验证成本过高，说明未执行的验证操作。

5. Report clearly

5. 清晰汇报

  • Summarize what you simplified.
  • Note any findings you intentionally skipped.
  • Call out remaining risks or follow-up work only if they are real and actionable.
  • 总结所做的代码简化工作。
  • 记录有意跳过的审查发现。
  • 仅当存在真实且可执行的风险或后续工作时，才指出剩余风险或待办事项。

Guardrails

约束规则

  • Follow the repository's own instructions and conventions first.
  • Prefer smaller, reversible edits over sweeping refactors.
  • Do not widen the change into unrelated files unless required.
  • If a simplification would make the code more magical, less debuggable, or less explicit, do not do it.
  • When in doubt, choose clarity over terseness.
  • 首先遵循仓库自身的规范和约定。
  • 优先选择小型、可回滚的修改，而非大规模重构。
  • 除非必要，否则不要将变更扩展到无关文件。
  • 如果某项简化会让代码变得更“魔法化”、更难调试或不够明确，则不要执行该操作。
  • 如有疑问，优先选择清晰性而非简洁性。

Delegation Template

子Agent委托模板

When spawning sub-agents, each pass should get:
  • the full diff or exact changed files
  • one clear objective: 
    reuse
    , 
    quality
    , or 
    efficiency
  • instructions to return only actionable findings with file references
  • instructions to avoid speculative redesigns outside the changed scope
当生成子Agent时，每一轮审查应获得：
  • 完整的代码差异或具体的变更文件
  • 一个明确的目标：
    reuse
    （复用）、
    quality
    （质量）或
    efficiency
    （效率）
  • 仅返回带有文件引用的可执行审查结果的指令
  • 避免对变更范围外的代码进行推测性重新设计的指令