Back to Details

simplify-code

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Simplify Code

代码简化

Review changed code for reuse, quality, efficiency, and clarity issues. Use Codex sub-agents to review in parallel, then optionally apply only high-confidence, behavior-preserving fixes.
检查变更代码的复用性、质量、效率和清晰度问题。使用Codex子Agent并行开展审查，之后可选择仅应用高置信度、不改变原有行为的修复。

When to Use

适用场景

  • When the user asks to simplify, clean up, refactor, or review changed code.
  • When you want high-confidence, behavior-preserving improvements on a scoped diff.
  • 当用户要求简化、清理、重构或审查变更代码时
  • 当你需要针对限定范围内的diff做高置信度、不改变原有行为的优化时

Modes

模式

Choose the mode from the user's request:
  • review-only
    : user asks to review, audit, or check the changes
  • safe-fixes
    : user asks to simplify, clean up, or refactor the changes
  • fix-and-validate
    : same as 
    safe-fixes
    , but also run the smallest relevant validation after edits
If the user does not specify, default to:
  • review-only
    for "review", "audit", or "check"
  • safe-fixes
    for "simplify", "clean up", or "refactor"
根据用户请求选择对应模式：
  • review-only
    ：用户要求审查、审计或检查变更
  • safe-fixes
    ：用户要求简化、清理或重构变更
  • fix-and-validate
    ：与
    safe-fixes
    功能一致，但在编辑完成后还会执行最小范围的相关验证
如果用户未明确指定，默认规则如下：
  • 涉及“review”、“audit”、“check”请求时默认使用
    review-only
  • 涉及“simplify”、“clean up”、“refactor”请求时默认使用
    safe-fixes

Step 1: Determine the Scope and Diff Command

步骤1：确定范围与Diff命令

Prefer this scope order:
  1. Files or paths explicitly named by the user
  2. Current git changes
  3. Files edited earlier in the current Codex turn
  4. Most recently modified tracked files, only if the user asked for a review but there is no diff
If there is no clear scope, stop and say so briefly.
When using git changes, determine the smallest correct diff command based on the repo state:
  • unstaged work: 
    git diff
  • staged work: 
    git diff --cached
  • branch or commit comparison explicitly requested by the user: use that exact diff target
  • mixed staged and unstaged work: review both
Do not assume 
git diff HEAD
is the right default when a smaller diff is available.
Before reviewing standards or applying fixes, read the repo's local instruction files and relevant project docs for the touched area. Prefer the closest applicable guidance, such as:
  • AGENTS.md
  • repo workflow docs
  • architecture or style docs for the touched module
Use those instructions to distinguish real issues from intentional local patterns.
优先遵循以下范围优先级：
  1. 用户明确指定的文件或路径
  2. 当前git变更
  3. 当前Codex会话中之前编辑过的文件
  4. 仅当用户要求审查但无可用diff时，选取最近修改的已跟踪文件
如果没有明确的范围，直接终止并简要告知用户。
使用git变更时，根据仓库状态确定最小范围的正确diff命令：
  • 未暂存的工作：
    git diff
  • 已暂存的工作：
    git diff --cached
  • 用户明确要求分支或提交对比：使用用户指定的diff目标
  • 暂存与未暂存工作混合：同时审查两者
如果存在更小范围的diff，不要默认使用
git diff HEAD
。
在审查规范或应用修复前，读取仓库本地说明文件与变更区域相关的项目文档，优先遵循最贴近的适用规范，例如：
  • AGENTS.md
  • 仓库工作流文档
  • 变更模块的架构或风格文档
根据这些说明区分真实问题和有意为之的本地代码风格。

Step 2: Launch Four Review Sub-Agents in Parallel

步骤2：并行启动4个审查子Agent

Use Codex sub-agents when the scope is large enough for parallel review to help. For a tiny diff or one very small file, it is acceptable to review locally instead.
When spawning sub-agents:
  • give each sub-agent the same scope
  • tell each sub-agent to inspect only its assigned review role
  • ask for concise, structured findings only
  • ask each sub-agent to report file, line or symbol, problem, recommended fix, and confidence
Use four review roles.
当范围足够大，并行审查能提升效率时使用Codex子Agent。如果是极小的diff或单个很小的文件，也可以直接本地审查。
创建子Agent时：
  • 给每个子Agent分配相同的审查范围
  • 告知每个子Agent仅检查其分配的审查角色对应的内容
  • 要求仅返回简洁、结构化的审查结果
  • 要求每个子Agent上报文件、行号或符号、问题、建议修复方案以及置信度
共设置4个审查角色：

Sub-Agent 1: Code Reuse Review

子Agent 1：代码复用审查

Review the changes for reuse opportunities:
  1. Search for existing helpers, utilities, or shared abstractions that already solve the same problem.
  2. Flag duplicated functions or near-duplicate logic introduced in the change.
  3. Flag inline logic that should call an existing helper instead of re-implementing it.
Recommended sub-agent role: 
explorer
for broad codebase lookup, or 
reviewer
if a stronger review pass is more useful than wide search.
检查变更中的复用机会：
  1. 搜索是否已有工具函数、工具类或共享抽象可以解决相同问题
  2. 标记变更中引入的重复函数或高度相似的逻辑
  3. 标记本可以调用现有工具函数却重新实现的内联逻辑
推荐子Agent角色：需要大范围检索代码库时用
explorer
，相比广域检索更需要深度审查时用
reviewer

Sub-Agent 2: Code Quality Review

子Agent 2：代码质量审查

Review the same changes for code quality issues:
  1. Redundant state, cached values, or derived values stored unnecessarily
  2. Parameter sprawl caused by threading new arguments through existing call chains
  3. Copy-paste with slight variation that should become a shared abstraction
  4. Leaky abstractions or ownership violations across module boundaries
  5. Stringly-typed values where existing typed contracts, enums, or constants already exist
Recommended sub-agent role: 
reviewer
检查相同变更中的代码质量问题：
  1. 不必要存储的冗余状态、缓存值或派生值
  2. 在现有调用链中传递新参数导致的参数膨胀
  3. 可提炼为共享抽象的少量修改后的复制粘贴代码
  4. 跨模块边界的抽象泄露或所有权违规
  5. 已有类型契约、枚举或常量却使用字符串类型的值
推荐子Agent角色：
reviewer

Sub-Agent 3: Efficiency Review

子Agent 3：效率审查

Review the same changes for efficiency issues:
  1. Repeated work, duplicate reads, duplicate API calls, or unnecessary recomputation
  2. Sequential work that could safely run concurrently
  3. New work added to startup, render, request, or other hot paths without clear need
  4. Pre-checks for existence when the operation itself can be attempted directly and errors handled
  5. Memory growth, missing cleanup, or listener/subscription leaks
  6. Overly broad reads or scans when the code only needs a subset
Recommended sub-agent role: 
reviewer
检查相同变更中的效率问题：
  1. 重复执行的工作、重复读取、重复API调用或不必要的重复计算
  2. 可安全并发执行的串行任务
  3. 无明确必要就添加到启动、渲染、请求或其他热路径中的新逻辑
  4. 可直接尝试操作并处理错误却提前做存在性检查的逻辑
  5. 内存增长、缺失清理或监听器/订阅泄露
  6. 仅需子集数据却执行大范围读取或扫描的逻辑
推荐子Agent角色：
reviewer

Sub-Agent 4: Clarity and Standards Review

子Agent 4：清晰度与规范审查

Review the same changes for clarity, local standards, and balance:
  1. Violations of local project conventions or module patterns
  2. Unnecessary complexity, deep nesting, weak names, or redundant comments
  3. Overly compact or clever code that reduces readability
  4. Over-simplification that collapses separate concerns into one unclear unit
  5. Dead code, dead abstractions, or indirection without value
Recommended sub-agent role: 
reviewer
Only report issues that materially improve maintainability, correctness, or cost. Do not churn code just to make it look different.
检查相同变更中的清晰度、本地规范与平衡性问题：
  1. 违反本地项目约定或模块模式的内容
  2. 不必要的复杂度、深层嵌套、命名不清晰或冗余注释
  3. 过度紧凑或取巧导致可读性下降的代码
  4. 过度简化将不同关注点合并为一个不清晰单元的内容
  5. 死代码、无用抽象或无价值的间接层
推荐子Agent角色：
reviewer
仅上报能实质性提升可维护性、正确性或降低成本的问题，不要为了修改而修改代码。

Step 3: Aggregate Findings

步骤3：汇总审查结果

Wait for all review sub-agents to complete, then merge their findings.
Normalize findings into this shape:
  1. File and line or nearest symbol
  2. Category: reuse, quality, efficiency, or clarity
  3. Why it is a problem
  4. Recommended fix
  5. Confidence: high, medium, or low
Discard weak, duplicative, or instruction-conflicting findings before editing.
等待所有审查子Agent执行完成后合并结果。
将结果标准化为以下格式：
  1. 文件和行号或最近的符号
  2. 类别：复用、质量、效率或清晰度
  3. 问题原因
  4. 建议修复方案
  5. 置信度：高、中、低
编辑前丢弃无效、重复或与说明冲突的结果。

Step 4: Fix Issues Carefully

步骤4：谨慎修复问题

In 
review-only
mode, stop after reporting findings.
In 
safe-fixes
or 
fix-and-validate
mode:
  • Apply only high-confidence, behavior-preserving fixes
  • Skip subjective refactors that need product or architectural judgment
  • Preserve local patterns when they are intentional or instruction-backed
  • Keep edits scoped to the reviewed files unless a small adjacent change is required to complete the fix correctly
Prefer fixes like:
  • replacing duplicated code with an existing helper
  • removing redundant state or dead code
  • simplifying control flow without changing behavior
  • narrowing overly broad operations
  • renaming unclear locals when the scope is contained
Do not stage, commit, or push changes as part of this skill.
在
review-only
模式下，上报结果后即可终止。
在
safe-fixes
或
fix-and-validate
模式下：
  • 仅应用高置信度、不改变原有行为的修复
  • 跳过需要产品或架构判断的主观重构
  • 如果本地模式是有意设计或有说明支撑则保留
  • 除非修复必须对相邻文件做少量修改，否则仅在审查的文件范围内修改
优先采用以下类型的修复：
  • 用现有工具函数替换重复代码
  • 移除冗余状态或死代码
  • 不改变行为的前提下简化控制流
  • 缩小过度宽泛的操作范围
  • 当范围可控时重命名不清晰的局部变量
本技能不会暂存、提交或推送变更。

Step 5: Validate When Required

步骤5：按需验证

In 
fix-and-validate
mode, run the smallest relevant validation for the touched scope after edits.
Examples:
  • targeted tests for the touched module
  • typecheck or compile for the touched target
  • formatter or lint check if that is the project's real safety gate
Prefer fast, scoped validation over full-suite runs unless the change breadth justifies more.
If validation is skipped because the user asked not to run it, say so explicitly.
在
fix-and-validate
模式下，编辑完成后针对变更范围执行最小范围的相关验证。
示例：
  • 针对变更模块的定向测试
  • 变更目标的类型检查或编译
  • 如果项目的安全校验包含格式化或lint检查则执行
优先使用快速、限定范围的验证，除非变更范围足够大需要全量验证。
如果因用户要求跳过验证，需明确告知用户。

Step 6: Summarize Outcome

步骤6：总结结果

Close with a brief result:
  • what was reviewed
  • what was fixed, if anything
  • what was intentionally left alone
  • whether validation ran
If the code is already clean for this rubric, say that directly instead of manufacturing edits.
最后输出简要的结果说明：
  • 审查的内容
  • 修复的内容（如有）
  • 有意保留未修改的内容
  • 是否执行了验证
如果代码按本规范已经足够整洁，直接说明即可，无需人为制造修改。