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子代理进行并行审查，之后可选择性仅应用高可信度、保留原有行为的修复方案。

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-only
    模式
  • 对于“简化”“清理”或“重构”类请求，使用
    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：并行启动四个审查子代理

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子代理进行并行审查。对于极小的diff或单个非常小的文件，也可以直接本地审查。
生成子代理时：
  • 为每个子代理分配相同的审查范围
  • 告知每个子代理仅检查其分配的审查维度
  • 要求仅返回简洁、结构化的审查结果
  • 要求每个子代理报告文件、行号或最近的符号、问题、推荐修复方案以及可信度
设置四个审查维度：

Sub-Agent 1: Code Reuse Review

子代理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. 标记应调用现有辅助函数而非重新实现的内联逻辑
推荐子代理角色：
explorer
（用于广泛查找代码库），或
reviewer
（如果需要更严格的审查而非广泛搜索）

Sub-Agent 2: Code Quality Review

子代理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. 可使用现有类型契约、枚举或常量却使用字符串类型的值
推荐子代理角色：
reviewer

Sub-Agent 3: Efficiency Review

子代理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. 代码仅需子集却进行过宽的读取或扫描
推荐子代理角色：
reviewer

Sub-Agent 4: Clarity and Standards Review

子代理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. 死代码、无用抽象或无价值的间接层
推荐子代理角色：
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.
等待所有审查子代理完成后，合并它们的结果。
将结果标准化为以下格式：
  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.
以简短的结果收尾：
  • 审查了哪些内容
  • 修复了哪些问题（如有）
  • 哪些内容有意保留未修改
  • 是否进行了验证
如果按照此标准代码已经很规范，请直接告知用户，无需强行修改。