用途
Simplify Code 用于审查变更代码（diff），从复用、质量、效率和清晰度四个角度找出问题，并在需要时应用高置信度、保持行为不变的修复。触发场景：用户要求简化、清理、重构或审查变更代码；或希望对限定范围内的 diff 做高置信度、不改变行为的改进。
模式
根据用户请求选择模式：
- review-only：用户要求 review、audit 或 check 变更时使用。
- safe-fixes：用户要求 simplify、clean up 或 refactor 变更时使用。
- fix-and-validate：与 safe-fixes 相同，但编辑后额外运行最小相关验证。
若用户未指定，默认规则：出现 review、audit、check 用 review-only；出现 simplify、clean up、refactor 用 safe-fixes。
使用方式
第 1 步：确定范围与 diff 命令
范围优先级：用户明确指定的文件或路径 → 当前 git 变更 → 本轮 Codex 中先前编辑过的文件 → 最近修改的已跟踪文件（仅当用户要求审查但没有 diff 时）。若无明确范围，停止并简短说明。
使用 git 变更时，依据仓库状态选择最小的正确 diff 命令：未暂存改动用 git diff；已暂存改动用 git diff --cached；用户明确要求的分支或提交比较使用该确切 diff 目标；暂存与未暂存混合时两者都审查。当存在更小的 diff 时，不要默认使用 git diff HEAD。
审查或应用修复前，先阅读仓库本地指令文件和相关项目文档，优先使用最贴近的相关指引，例如 AGENTS.md、仓库工作流文档、被触及模块的架构或风格文档，以此区分真实问题与有意的本地模式。
第 2 步：并行启动四个审查子代理
当范围足够大、并行审查有帮助时使用 Codex 子代理；对于极小的 diff 或很小的单个文件，也可以本地审查。启动子代理时：给每个子代理相同范围；告知每个子代理只检查其被分配的审查角色；只要求简洁、结构化的发现；要求每个子代理报告文件、行或符号、问题、建议修复和置信度。
四个审查角色：
- 代码复用审查：搜索已解决同一问题的现有 helper、工具函数或共享抽象；标记变更中引入的重复函数或近乎重复的逻辑；标记应调用现有 helper 而非重新实现的内联逻辑。建议子代理角色：explorer（广泛代码库查找）或 reviewer。
- 代码质量审查：多余的状态、缓存值或派生的值被不必要地存储；为在已有调用链中贯穿新参数而导致的参数泛滥；应成为共享抽象的、只有细微差异的复制粘贴；跨模块边界的泄漏抽象或归属违规；在已有类型契约、枚举或常量存在时仍使用字符串类型值。建议子代理角色：reviewer。
- 效率审查：重复工作、重复读取、重复 API 调用或不必要的重算；本可安全并发执行的顺序工作；在启动、渲染、请求或其他热路径中无明确必要地新增工作；当操作本身可直接尝试并处理错误时仍做存在性预检查；内存增长、缺失清理或监听器/订阅泄漏；代码只需子集时却做过于宽泛的读取或扫描。建议子代理角色：reviewer。
- 清晰度与规范审查：违反本地项目约定或模块模式；不必要的复杂性、深层嵌套、弱命名或冗余注释；过于紧凑或机巧而降低可读性的代码；把本应分离的关注点压缩进一个不清晰单元的过度简化；死代码、死抽象或无价值的间接层。建议子代理角色：reviewer。
只报告能实质改善可维护性、正确性或成本的问题，不要仅为让代码看起来不同而制造改动。
第 3 步：汇总发现
等待所有审查子代理完成，然后合并其发现，统一为：文件与行或最近符号；类别（reuse、quality、efficiency、clarity）；为何是问题；建议的修复；置信度（high、medium、low）。编辑前丢弃薄弱、重复或与指令冲突的发现。
第 4 步：谨慎修复
review-only 模式下，报告完发现即停止。在 safe-fixes 或 fix-and-validate 模式下：只应用高置信度、保持行为不变的修复；跳过需要产品或架构判断的主观重构；当本地模式是有意或由指令支持时予以保留；除非完成修复确需小的相邻改动，否则将编辑限定在被审查文件内。优先采用如下修复：用现有 helper 替换重复代码；移除冗余状态或死代码；在不改变行为的前提下简化控制流；收窄过于宽泛的操作；在作用域可控时重命名不清晰的局部变量。不要作为本技能的一部分暂存、提交或推送变更。
第 5 步：需要时验证
fix-and-validate 模式下，编辑后对被触及范围运行最小的相关验证，例如：被触及模块的定向测试；被触及目标的类型检查或编译；若那是项目真正的安全关卡，则运行格式化或 lint 检查。除改动广度需要更多验证外，优先快速、限定范围的验证而非全量套件。若因用户要求不运行而跳过验证，需明确说明。
第 6 步：总结结果
结尾简述：审查了什么；修复了什么（如有）；有意保持不变的部分；是否运行了验证。如果按此标准代码已干净，直接说明，而不是制造编辑。
示例
用户请求：简化变更代码并保持行为，然后运行聚焦测试以证明重构安全。
限制
仅当任务明确匹配上述范围时使用本技能。不要将其输出当作环境特定验证、测试或专家审查的替代品。若缺少必需输入、权限、安全边界或成功标准，应停止并请求澄清。