Back to Details

review-and-simplify-changes

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review and Simplify Changes

审查并简化变更

Review changed code for reuse, quality, efficiency, and clarity issues. Use Codex sub-agents to review in parallel, but keep those sub-agents read-only: they should only inspect code and send findings back to the main agent. Only the main agent may apply high-confidence, behavior-preserving fixes.
审查变更代码的复用性、质量、效率及清晰度问题。使用Codex子Agent并行开展审查，但需保持这些子Agent为只读状态：它们仅可检查代码并将结果返回给主Agent，仅主Agent可应用高置信度、不改变原有行为的修复。

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 Read-Only 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
  • tell each sub-agent it is operating in a read-only review pass
  • do not let sub-agents edit files, run 
    apply_patch
    , stage changes, commit, or perform other state-mutating actions
  • ask for concise, structured findings only
  • ask each sub-agent to report file, line or symbol, problem, recommended fix, and confidence
  • ask each sub-agent to return findings to the main agent only; they must not implement fixes themselves
Use four review roles.
当审查范围足够大、并行审查能提升效率时使用Codex子Agent，若diff范围极小或仅涉及一个很小的文件，也可直接在本地完成审查。
创建子Agent时需遵循以下规则：
  • 给所有子Agent分配相同的审查范围
  • 告知每个子Agent仅检查其分配的审查维度
  • 告知每个子Agent处于只读审查阶段
  • 不允许子Agent编辑文件、运行
    apply_patch
    、暂存变更、提交或执行其他会变更状态的操作
  • 仅要求子Agent返回简洁、结构化的审查结果
  • 要求每个子Agent上报文件、行号/对应符号、问题描述、修复建议和置信度
  • 要求每个子Agent仅将结果返回给主Agent，不得自行实现修复
共设置4个审查角色：

Sub-Agent 1: Code Reuse Review

子Agent1：代码复用审查

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.
This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.
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为只读状态，不得编辑文件、应用补丁或修改工作区的任何内容。
推荐子Agent角色：用于全代码库检索的
explorer
，若强审查比广范围检索更重要则使用
reviewer
。

Sub-Agent 2: Code Quality Review

子Agent2：代码质量审查

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
This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.
Recommended sub-agent role: 
reviewer
审查相同变更中的代码质量问题：
  1. 冗余状态、缓存值或不必要存储的派生值
  2. 因在现有调用链中新增参数导致的参数膨胀
  3. 应该抽象为共享逻辑的小幅修改复制粘贴代码
  4. 模块边界的抽象泄漏或所有权违规
  5. 已有类型契约、枚举或常量可用时，仍使用字符串类型值
本子Agent为只读状态，不得编辑文件、应用补丁或修改工作区的任何内容。
推荐子Agent角色：
reviewer

Sub-Agent 3: Efficiency Review

子Agent3：效率审查

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
This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.
Recommended sub-agent role: 
reviewer
审查相同变更中的效率问题：
  1. 重复操作、重复读取、重复API调用或不必要的重复计算
  2. 可安全并发运行的串行操作
  3. 无明确必要就添加到启动、渲染、请求等热点路径的新逻辑
  4. 可直接尝试操作并处理错误、却额外增加存在性预检查的逻辑
  5. 内存增长、缺失清理逻辑或监听器/订阅泄漏
  6. 仅需要部分数据时却执行范围过大的读取或扫描
本子Agent为只读状态，不得编辑文件、应用补丁或修改工作区的任何内容。
推荐子Agent角色：
reviewer

Sub-Agent 4: Clarity and Standards Review

子Agent4：清晰度与规范审查

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
This sub-agent is read-only. It must not edit files, apply patches, or make any other workspace changes.
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为只读状态，不得编辑文件、应用补丁或修改工作区的任何内容。
推荐子Agent角色：
reviewer
仅上报能显著提升可维护性、正确性或降低成本的问题，不要为了改动而改动代码。

Step 3: Aggregate Findings

步骤3：汇总审查结果

Wait for all review sub-agents to complete, then merge their findings.
The main agent owns this step. Treat sub-agent output as review input only, not as permission to delegate code changes back out.
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执行完成后，合并它们的审查结果。
本步骤由主Agent负责，子Agent的输出仅作为审查输入，不得作为将代码变更委托给子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:
  • Only the main agent applies fixes for this skill
  • 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
模式下：
  • 仅主Agent可执行本功能的修复操作
  • 仅应用高置信度、不改变原有行为的修复
  • 跳过需要产品或架构判断的主观重构
  • 当本地模式是有意设计或有规范依据时，保留原有实现
  • 除非完成修复需要少量相邻文件改动，否则仅在被审查的文件范围内修改
优先选择以下类型的修复：
  • 用现有辅助函数替换重复代码
  • 移除冗余状态或死代码
  • 在不改变行为的前提下简化控制流
  • 缩小范围过大的操作
  • 当作用域可控时重命名含义模糊的局部变量
本功能的执行过程中不要暂存、提交或推送变更。

Step 5: Validate When Required

步骤5：按需执行验证

In 
fix-and-validate
mode, after the main agent finishes edits, run the smallest relevant validation for the touched scope.
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
模式下，主Agent完成编辑后，针对变更范围运行最小范围的相关验证。
示例：
  • 运行变更模块的针对性测试
  • 对变更目标执行类型检查或编译
  • 若项目的安全校验要求格式化或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.
最后输出简短的执行结果：
  • 审查了哪些内容
  • 修复了哪些问题（如有）
  • 哪些问题有意保留未处理
  • 是否执行了验证
如果代码已经符合本规范的所有要求，直接说明即可，不要人为制造修改。