关于 simplify-code
用于检查或简化代码变更的 Codex Skill，面向需要代码审查、重构或验证的开发者。它按请求选择审查模式，并让子 Agent 并行只读检查，最终由主 Agent 应用高置信度修复。
主要功能
- 01按请求选择审查或修复模式
- 02并行运行只读子 Agent 审查
- 03按复用、质量、效率和清晰度检查
- 04仅由主 Agent 应用高置信度修复
- 05按需运行针对性验证
适用场景
- 01审查当前 Git 变更并汇总问题
- 02清理重构代码且保持行为不变
- 03修复后运行最小范围验证
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/simplify-code确认已加载。
详细介绍
简化代码
检查变更的代码，找出复用性、质量、效率和清晰度方面的问题。使用 Codex 子 Agent 并行审查，但这些子 Agent 必须保持只读：只能检查代码并向主 Agent 报告发现。只有主 Agent 可以应用高置信度且不改变行为的修复。
模式
根据用户的请求选择模式：
review-only：用户要求审查、审计或检查变更safe-fixes：用户要求简化、清理或重构变更fix-and-validate：与safe-fixes相同，但编辑后还要运行最小范围的相关验证
如果用户未指定，默认使用：
- 对“审查”“审计”或“检查”，使用
review-only - 对“简化”“清理”或“重构”，使用
safe-fixes
步骤 1：确定范围和 Diff 命令
优先按以下顺序确定范围：
- 用户明确指定的文件或路径
- 当前的 Git 变更
- 当前 Codex 轮次中较早编辑的文件
- 最近修改的受 Git 跟踪文件，仅当用户要求审查但没有 diff 时使用
如果范围不明确，请停止并简要说明。
使用 Git 变更时，根据仓库状态确定最小且正确的 diff 命令：
- 未暂存的工作：
git diff - 已暂存的工作：
git diff --cached - 用户明确要求比较分支或提交：使用指定的 diff 目标
- 已暂存和未暂存的工作混杂：两者都要审查
不要默认认为 git diff HEAD 是正确选择；有更小范围时应优先使用。
审查规范或应用修复前，先阅读仓库的本地说明文件，以及与变更区域相关的项目文档。优先参考最贴近的指导文件，例如：
AGENTS.md- 仓库工作流文档
- 变更模块的架构或风格文档
根据这些说明区分真正的问题与有意采用的本地模式。
步骤 2：并行启动四个只读审查子 Agent
如果范围足够大，适合并行审查，请使用 Codex 子 Agent。对于很小的 diff 或单个很小的文件，可以在本地审查。
启动子 Agent 时：
- 为每个子 Agent 指定相同的范围
- 告知每个子 Agent 只检查其分配的审查角色
- 告知它们正在进行只读审查
- 不要让子 Agent 编辑文件、运行
apply_patch、暂存变更、提交或执行其他会改变状态的操作 - 要求它们只返回简洁、结构化的发现
- 要求它们报告文件、行号或符号、问题、建议的修复和置信度
- 要求它们只向主 Agent 返回发现；不得自行实现修复
使用四种审查角色。
子 Agent 1：代码复用审查
检查变更中的复用机会：
- 查找已能解决同一问题的现有辅助函数、工具或共享抽象。
- 指出变更中新引入的重复函数或近似重复逻辑。
- 指出应调用现有辅助函数而不是重新实现的内联逻辑。
此子 Agent 只能读取，不得编辑文件、应用补丁或进行任何其他工作区变更。
建议的子 Agent 角色：explorer，适合广泛查找代码库；或 reviewer，适合进行更深入的审查。
子 Agent 2：代码质量审查
从代码质量角度审查相同的变更：
- 不必要的冗余状态、缓存值或派生值
- 在现有调用链中传递新增参数导致的参数膨胀
- 仅有细微差异、应抽取为共享抽象的复制粘贴代码
- 跨模块边界的抽象泄漏或所有权违规
- 在已有类型化契约、枚举或常量可用时，仍使用字符串表示的值
此子 Agent 只能读取，不得编辑文件、应用补丁或进行任何其他工作区变更。
建议的子 Agent 角色：reviewer
子 Agent 3：效率审查
检查相同的更改是否存在效率问题：
- 重复工作、重复读取、重复 API 调用或不必要的重新计算
- 可以安全并发执行却按顺序执行的工作
- 无明确必要却新增到启动、渲染、请求或其他热点路径中的工作
- 操作本身可以直接尝试并处理错误，却先检查是否存在
- 内存增长、缺少清理或监听器／订阅泄漏
- 代码只需读取部分内容，却进行范围过大的读取或扫描
此子 Agent 只读，不得编辑文件、应用补丁或对工作区进行任何其他更改。
建议的子 Agent 角色：reviewer
子 Agent 4：清晰度与规范审查
检查相同的更改是否符合清晰度、本地规范和合理性要求：
- 违反项目本地约定或模块模式
- 不必要的复杂性、过深的嵌套、不清晰的名称或冗余注释
- 过于精简或取巧，导致可读性下降的代码
- 过度简化，将不同关注点合并成一个含义不清的单元
- 死代码、无用抽象或没有价值的间接层
此子 Agent 只读，不得编辑文件、应用补丁或对工作区进行任何其他更改。
建议的子 Agent 角色：reviewer
仅报告能够实质性提升可维护性、正确性或成本效益的问题。不要为了让代码看起来不同而反复改动。
第 3 步：汇总发现
等待所有审查子 Agent 完成，然后合并其发现。
主 Agent 负责此步骤。仅将子 Agent 的输出视为审查输入，不得据此授权将代码更改委派给其他 Agent。
将发现规范化为以下格式：
- 文件及行号或最近的符号
- 类别：复用、质量、效率或清晰度
- 问题所在
- 建议的修复方法
- 置信度：高、中或低
在编辑前，舍弃依据薄弱、重复或与指令冲突的发现。
第 4 步：谨慎修复问题
在 review-only 模式下，报告发现后即停止。
在 safe-fixes 或 fix-and-validate 模式下：
- 对此技能，只有主 Agent 可以应用修复
- 仅应用高置信度且保持行为不变的修复
- 跳过需要产品或架构判断的主观重构
- 如果本地模式是有意为之或有指令依据，则予以保留
- 将编辑限制在已审查的文件内；只有正确完成修复所必需时，才进行少量相邻更改
优先考虑以下修复：
- 用现有辅助函数替换重复代码
- 删除冗余状态或死代码
- 在不改变行为的前提下简化控制流
- 缩小范围过大的操作
- 在影响范围有限时，重命名含义不清的局部变量
此技能不包含暂存、提交或推送更改。
第 5 步：在需要时进行验证
在 fix-and-validate 模式下，主 Agent 完成编辑后，应针对已修改范围运行最小必要验证。
例如：
- 针对已修改模块运行定向测试
- 对已修改目标进行类型检查或编译
- 如果格式化或 lint 检查是项目实际使用的安全门槛，则运行相应检查
优先进行快速、范围明确的验证；除非更改范围足以证明有必要，否则不要运行完整测试套件。
如果用户要求不运行验证而跳过了验证，请明确说明。
第 6 步：总结结果
用简短的总结收尾，说明：
- 审查了哪些内容
- 修复了什么（如有）
- 有意保留了什么
- 是否运行了验证
如果代码已经符合这套审查标准，请直接说明，不要凭空制造需要修改的地方。