simplify-code

简化代码

检查已更改的代码，找出复用、质量、效率和清晰度方面的问题。使用 Codex 子 Agent 并行审查，然后可选择只应用高置信度且不改变行为的修复。

适用场景

• 用户要求简化、清理、重构或审查已更改的代码时。
• 希望针对范围明确的差异，进行高置信度且不改变行为的改进时。

模式

根据用户的请求选择模式：

• review-only：用户要求审查、审核或检查更改
• safe-fixes：用户要求简化、清理或重构更改
• fix-and-validate：与 safe-fixes 相同，但还要在编辑后运行最小范围的相关验证

如果用户未指定，默认选择：

• 对于“审查”“审核”或“检查”，选择 review-only
• 对于“简化”“清理”或“重构”，选择 safe-fixes

步骤 1：确定范围和差异命令

优先按以下顺序确定范围：

1. 用户明确指定的文件或路径
2. 当前 Git 更改
3. 当前 Codex 回合中较早编辑的文件
4. 最近修改过的已跟踪文件，仅当用户要求审查但没有差异时

如果范围不明确，请停止并简要说明。

使用 Git 更改时，根据仓库状态确定最小且正确的差异命令：

• 未暂存的工作：git diff
• 已暂存的工作：git diff --cached
• 用户明确要求比较分支或提交：使用指定的差异目标
• 同时有已暂存和未暂存的工作：两者都要审查

如果有更小范围的差异可用，不要默认使用 git diff HEAD。

在审查规范或应用修复之前，请阅读仓库的本地说明文件，以及与修改区域相关的项目文档。优先参考最贴近的适用指南，例如：

• AGENTS.md
• 仓库工作流程文档
• 修改模块的架构或风格文档

使用这些说明来区分实际问题与有意采用的本地模式。

步骤 2：使用四种审查视角

仅当当前用户或仓库说明明确授权委派时，才启动子 Agent。否则，请自行应用四种审查视角。Agent 角色名称取决于宿主环境；不要覆盖用户选择的模型，也不要在未经授权的情况下向外部审查者披露代码。

当范围足够大、并行审查能带来帮助时，使用 Codex 子 Agent。对于很小的差异或单个很小的文件，可以自行审查。

启动子 Agent 时：

• 为每个子 Agent 提供相同的范围
• 要求每个子 Agent 只检查分配给它的审查职责
• 要求仅报告简洁、结构化的发现
• 要求每项发现说明文件、行号或符号、问题、建议的修复方案及置信度

使用以下四种审查职责。

子 Agent 1：代码复用审查

检查更改中的复用机会：

1. 搜索已有的辅助函数、实用工具或共享抽象，确认是否已有方案能解决同一问题。
2. 指出更改中引入的重复函数或近似重复逻辑。
3. 指出应调用现有辅助函数，而不是重新实现的内联逻辑。

建议的子 Agent 角色：explorer，适合广泛搜索代码库；或者使用 reviewer，在广泛搜索之外进行更深入的审查。

子 Agent 2：代码质量审查

从代码质量角度审查相同的更改：

1. 多余的状态、缓存值或不必要地存储的派生值
2. 通过现有调用链传递新参数所导致的参数泛滥
3. 只有细微差异的复制粘贴代码，是否应提取为共享抽象
4. 抽象泄漏或跨模块边界的所有权违规
5. 当现有类型化契约、枚举或常量已存在时，仍使用字符串表示的值

建议的子 Agent 角色：reviewer

子 Agent 3：效率审查

审查相同变更的效率问题：

1. 重复工作、重复读取、重复 API 调用或不必要的重复计算
2. 本可安全并发执行的顺序工作
3. 在启动、渲染、请求或其他热路径中新增了没有明确需要的工作
4. 在操作本身可直接尝试并处理错误时，却预先检查是否存在
5. 内存增长、缺少清理或监听器/订阅泄漏
6. 当代码只需要一个子集时，读取或扫描范围过大

推荐的子 Agent 角色：reviewer

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

审查相同变更的清晰度、本地规范与平衡性：

1. 违反本地项目约定或模块模式
2. 不必要的复杂性、过深的嵌套、命名不清晰或冗余注释
3. 过度紧凑或过度取巧而降低可读性的代码
4. 过度简化，将彼此独立的关注点合并为一个含义不清的单元
5. 死代码、无用的抽象或没有价值的间接层

推荐的子 Agent 角色：reviewer

只报告那些能实质性提升可维护性、正确性或成本的问题。不要仅仅为了让代码看起来不同而随意改动代码。

第 3 步：汇总发现

等待所有审查子 Agent 完成，然后合并它们的发现。

将发现规范化为以下形式：

1. 文件及行号或最近的符号
2. 类别：复用、质量、效率或清晰度
3. 为什么这是一个问题
4. 推荐的修复方式
5. 置信度：高、中或低

在编辑前，丢弃薄弱、重复或与指令冲突的发现。

第 4 步：谨慎修复问题

在 review-only 模式下，报告发现后即停止。

在 safe-fixes 或 fix-and-validate 模式下：

• 仅应用高置信度、保持行为的修复
• 跳过需要产品或架构判断的主观重构
• 当本地模式是有意为之或有指令支持时，予以保留
• 除非需要一小处相邻改动才能正确完成修复，否则将编辑范围限定在已审查的文件内

优先采用如下修复：

• 用现有辅助函数替换重复代码
• 移除冗余状态或死代码
• 在不改变行为的前提下简化控制流
• 缩小范围过大的操作
• 在作用域可控时重命名不清晰的局部变量

不要在此技能中暂存、提交或推送变更。

第 5 步：在需要时进行验证

在 fix-and-validate 模式下，编辑后针对所涉范围运行最小的相关验证。

示例：

• 针对所涉模块的定向测试
• 针对所涉目标的类型检查或编译
• 如果格式化程序或 lint 检查是项目真正的安全门槛，则运行它

优先选择快速、范围限定的验证，而非全量测试套件，除非变更范围足以证明需要更多验证。

如果因用户要求不运行而跳过了验证，请明确说明。

第 6 步：总结结果

以简要结果收尾：

• 审查了什么
• 修复了什么（如有）
• 有意保持原样的部分
• 是否运行了验证

如果代码在此标准下已经足够干净，请直接说明，而不要为了修改而制造编辑。

示例

用户请求：

在不改变行为的前提下简化已变更的代码，然后运行定向测试以证明重构是安全的。

限制

• 仅当任务与上述范围明确匹配时，才使用此技能。
• 不要将此技能的输出视为环境特定验证、测试或专家审查的替代品。
• 如果缺少所需输入、权限、安全边界或成功标准，请停下来并请求澄清。