code-simplify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

<EXTREMELY-IMPORTANT> This skill edits code. Non-negotiable rules: 1. Read the target code, nearby callers, and relevant tests before changing anything. 2. Establish the narrowest useful baseline check before edits when feasible. 3. Preserve behavior, side effects, and error handling. 4. Ask the user only when the scope is ambiguous, the simplification is risky, or there are real alternatives. 5. Keep the invocation body focused on the simplification loop; load detailed patterns from references only when needed. </EXTREMELY-IMPORTANT>

<EXTREMELY-IMPORTANT> 此技能用于编辑代码。以下规则不可协商： 1. 在进行任何修改前，先阅读目标代码、相关调用方及关联测试。 2. 若可行，在编辑前建立最窄范围的有效基线检查。 3. 保留代码行为、副作用及错误处理逻辑。 4. 仅当范围模糊、简化存在风险或有实际替代方案时，才向用户询问。 5. 保持调用主体聚焦于简化循环；仅在需要时从参考资料中加载详细模式。 </EXTREMELY-IMPORTANT>

Code Simplify

代码简化

Inputs

输入

```
$request
```
: Optional scope or simplification guidance such as a file path, symbol name, or a note like
```
flatten nested conditionals
```
.

```
$request
```
：可选的范围或简化指导，例如文件路径、符号名称，或类似
```
flatten nested conditionals
```
的说明。

Goal

目标

Apply the smallest safe set of readability-focused changes that makes the target code easier to understand and maintain without changing what it does.

应用最小且安全的可读性优化变更，使目标代码更易于理解和维护，同时不改变其功能。

Step 0: Resolve scope and suitability

步骤0：确定范围与适用性

Determine:

the exact file, symbol, or diff scope to simplify
whether the user asked for a narrow cleanup or a broader pass
whether the target is application code, tests, generated code, or a performance-sensitive path

Stop or clarify if:

the request is too vague to identify the target safely
the code is generated
the requested "simplification" is actually a redesign
the change would obviously alter public behavior or contracts

Use

AskUserQuestion

only when ambiguity blocks safe progress or when there are multiple legitimate simplification directions.

Success criteria: The simplification scope is explicit and appropriate for a local cleanup workflow.

需明确：

要简化的具体文件、符号或差异范围
用户要求的是窄范围清理还是更全面的优化
目标代码是应用代码、测试代码、生成代码还是性能敏感路径

若出现以下情况，需停止操作或向用户澄清：

请求过于模糊，无法安全确定目标范围
代码为生成代码
请求的“简化”实际上是重新设计
变更明显会改变公共行为或契约

仅当模糊性阻碍安全推进，或存在多种合理简化方向时，才使用

AskUserQuestion

。

成功标准：简化范围明确，且适用于本地清理工作流。

Step 1: Understand behavior and establish a baseline

步骤1：理解行为并建立基线

Read the real code before editing:

target file or files
nearby callers, exports, and adjacent helpers
existing tests covering the target behavior

Then identify:

inputs and outputs
side effects and persistence boundaries
error handling and guard clauses
externally visible contracts that must not change

Verification baseline:

run the narrowest relevant tests, type check, lint target, or build step when feasible
if no narrow verification exists, state that explicitly and proceed more conservatively

Runtime-specific rule:

do not mechanically block on rereading
```
CLAUDE.md
```
every time
Claude Code already injects the
```
CLAUDE.md
```
hierarchy into conversation context via
```
getUserContext
```
read extra local docs only when the target area has its own conventions or the surrounding code is ambiguous

Success criteria: The current behavior and the verification baseline are clear before edits begin.

在编辑前阅读实际代码：

目标文件或多个文件
相关调用方、导出内容及相邻辅助函数
覆盖目标行为的现有测试

随后明确：

输入与输出
副作用与持久化边界
错误处理与防护语句
必须保持不变的外部可见契约

验证基线：

若可行，运行最相关的窄范围测试、类型检查、目标代码 lint 或构建步骤
若不存在窄范围验证方式，需明确说明并更保守地推进

运行时特定规则：

无需每次都机械地重新阅读
```
CLAUDE.md
```
Claude Code 已通过
```
getUserContext
```
将
```
CLAUDE.md
```
层级注入对话上下文
仅当目标区域有自身约定或周边代码存在歧义时，才需阅读额外的本地文档

成功标准：在开始编辑前，明确当前行为及验证基线。

Step 2: Identify simplification candidates

步骤2：识别简化候选项

Look for changes that reduce local complexity without turning into a redesign:

flatten deep nesting with guard clauses or early returns
extract hard-to-read expressions into named variables or helpers
rename misleading or cryptic local symbols
eliminate dead code and unused branches
consolidate obvious duplication
simplify boolean logic and conditional branching
reduce parameter sprawl where call sites stay understandable

For each candidate, record:

location
category
risk:
```
low
```
,
```
medium
```
, or
```
high
```
required verification

Load

references/simplification-patterns.md

for the detailed pattern catalog, anti-patterns, and risk guidance.

Success criteria: A concrete candidate set exists, ordered by risk and expected value.

寻找可降低本地复杂度且不会演变为重新设计的变更：

使用防护语句或提前返回扁平化深层嵌套
将难以阅读的表达式提取为命名变量或辅助函数
重命名具有误导性或晦涩的本地符号
移除死代码和未使用的分支
合并明显重复的代码
简化布尔逻辑和条件分支
在调用方仍可理解的前提下减少参数冗余

针对每个候选项，记录：

位置
类别
风险等级：
```
low
```
、
```
medium
```
或
```
high
```
所需的验证方式

加载

references/simplification-patterns.md

以获取详细的模式目录、反模式及风险指导。

成功标准：存在具体的候选项集合，并按风险和预期价值排序。

Step 3: Choose the smallest safe change set

步骤3：选择最小且安全的变更集合

Default behavior:

apply low-risk and clearly beneficial simplifications directly
batch related edits by file or tightly coupled call sites
prefer one small clean pass over a broad "cleanup everything" sweep

Ask the user before proceeding when:

the best simplification path is not obvious
the change is medium/high risk
multiple unrelated cleanup opportunities are present and scope needs a choice
a rename or extraction crosses a broad public surface

Do not require a ceremonial before/after approval step for trivial, obviously safe cleanups.

Success criteria: The intended edits are limited, justifiable, and proportionate to the user request.

默认行为：

直接应用低风险且明显有益的简化操作
按文件或紧密耦合的调用方批量处理相关编辑
优先选择一次小规模清理，而非全面的“清理所有内容”

出现以下情况时，需先询问用户再推进：

最佳简化路径不明确
变更为中/高风险
存在多个不相关的清理机会，需要选择范围
重命名或提取操作涉及广泛的公共接口

对于微小且明显安全的清理操作，无需进行正式的前后确认步骤。

成功标准：预期编辑操作范围有限、合理，且与用户请求相称。

Step 4: Apply the simplifications

步骤4：应用简化操作

Make changes in the safest order:

dead code removal and trivial boolean cleanup
flattening and local extraction
duplication consolidation
broader renames or small helper extraction

Rules during editing:

preserve function signatures unless the user explicitly wants broader cleanup
preserve error handling and observable side effects
search for references before renaming shared symbols
if a helper file must be created, keep it adjacent and narrowly scoped
stop if the cleanup starts cascading into architecture work

Success criteria: The requested simplifications are implemented without unintended scope expansion.

按最安全的顺序进行变更：

移除死代码和简化简单布尔逻辑
扁平化嵌套和本地提取
合并重复代码
更广泛的重命名或提取小型辅助函数

编辑时的规则：

除非用户明确要求更全面的清理，否则保留函数签名
保留错误处理和可观察的副作用
重命名共享符号前先搜索引用
若必须创建辅助文件，需将其放在相邻位置且范围狭窄
若清理开始演变为架构层面的工作，需停止操作

成功标准：已实现请求的简化操作，且未出现意外的范围扩展。

Step 5: Verify behavior is preserved

步骤5：验证行为未改变

Rerun the narrowest relevant checks from Step 1:

targeted tests first
type check or compile step if relevant
broader checks only if the touched area requires them

Then confirm:

the baseline still passes
no new type or syntax errors were introduced
the code is actually clearer, not just shorter

If a simplification causes regressions or ambiguous fallout:

revert the last risky change
keep the safe improvements
report the blocked candidate instead of forcing it through

Success criteria: Verification matches or improves on the baseline without behavior changes.

重新运行步骤1中最相关的窄范围检查：

优先运行目标测试
若相关，运行类型检查或编译步骤
仅当受影响区域需要时，才进行更广泛的检查

随后确认：

基线检查仍通过
未引入新的类型或语法错误
代码确实更清晰，而非仅仅更简短

若简化操作导致回归或歧义影响：

撤销最后一次高风险变更
保留安全的优化改进
报告受阻的候选项，而非强行推进

成功标准：验证结果与基线一致或更优，且未改变代码行为。

Guardrails

约束规则

Do not use this skill proactively for unrelated work.
Do not add features, comments, or architectural refactors under the label of simplification.
Do not simplify generated code.
Do not simplify tests unless the user asked for test cleanup specifically.
Do not optimize for fewer lines; optimize for lower cognitive load.
Do not add
```
disable-model-invocation
```
; the model must be able to invoke this skill when the user explicitly asks for simplification.
Do not add
```
context: fork
```
; this workflow edits the current working context and benefits from inline execution.
Do not add
```
paths:
```
; this is a generic workflow skill, not a path-activated domain reference.
Do not keep the full pattern catalog inline in
```
SKILL.md
```
.

不得主动将此技能用于无关工作。
不得在“简化”的名义下添加功能、注释或架构重构。
不得简化生成代码。
除非用户明确要求清理测试代码，否则不得简化测试代码。
不得为减少代码行数而优化；应针对降低认知负荷进行优化。
不得添加
```
disable-model-invocation
```
；当用户明确要求简化时，模型必须能够调用此技能。
不得添加
```
context: fork
```
；此工作流编辑当前工作上下文，内联执行更有利。
不得添加
```
paths:
```
；这是通用工作流技能，而非路径激活的领域参考资料。
不得在
```
SKILL.md
```
中保留完整的模式目录。

When To Load References

何时加载参考资料

```
references/simplification-patterns.md
```
Use for detailed pattern examples, risk guidance, anti-patterns, and escalation heuristics when the target code is non-trivial.

```
references/simplification-patterns.md
```
当目标代码非琐碎时，使用此资料获取详细的模式示例、风险指导、反模式及升级启发式规则。

Output Contract

输出约定

Report:

resolved scope
baseline checks run, or explicit verification gap
simplifications applied by file and category
verification results
skipped or deferred opportunities and why

需报告：

已确定的范围
已运行的基线检查，或明确的验证缺口
按文件和类别划分的已应用简化操作
验证结果
已跳过或延迟的优化机会及原因