kscz0000 代码简化
审查变更代码的复用性、质量、效率和清晰度问题。使用 Codex 子代理并行审查，然后可选择性地仅应用高置信度、行为保持的修复。
使用场景
- 当用户要求简化、清理、重构或审查变更代码时
- 当你需要对限定范围的 diff 进行高置信度、行为保持的改进时
模式
根据用户请求选择模式：
review-only：用户要求审查、审计或检查变更safe-fixes：用户要求简化、清理或重构变更fix-and-validate：与safe-fixes相同，但编辑后还会运行最小相关验证
如果用户未指定，默认为：
- 对于"审查"、"审计"或"检查"使用
review-only - 对于"简化"、"清理"或"重构"使用
safe-fixes
步骤 1：确定范围和 Diff 命令
优先使用此范围顺序：
- 用户明确指定的文件或路径
- 当前 git 变更
- 当前 Codex 轮次中编辑过的文件
- 最近修改的跟踪文件（仅当用户要求审查但没有 diff 时）
如果没有明确范围，请简短说明。
使用 git 变更时，根据仓库状态确定最小正确的 diff 命令：
- 未暂存的工作：
git diff - 已暂存的工作：
git diff --cached - 用户明确请求的分支或提交比较：使用该确切的 diff 目标
- 混合暂存和未暂存的工作：同时审查两者
当有更小的 diff 可用时，不要假设 git diff HEAD 是正确的默认值。
在审查标准或应用修复之前，读取仓库的本地指令文件和相关项目文档（针对涉及的区域）。优先使用最接近的适用指导，例如：
AGENTS.md- 仓库工作流文档
- 涉及模块的架构或样式文档
使用这些指令来区分真正的问题和有意的本地模式。
步骤 2：并行启动四个审查子代理
当范围足够大时，使用 Codex 子代理进行并行审查。对于极小的 diff 或单个非常小的文件，可以在本地审查。
生成子代理时：
- 给每个子代理相同的范围
- 告诉每个子代理只检查其分配的审查角色
- 只要求简洁、结构化的发现
- 要求每个子代理报告文件、行或符号、问题、推荐修复和置信度
使用四个审查角色。
子代理 1：代码复用审查
审查变更的复用机会：
- 搜索已有的辅助函数、工具或共享抽象，看是否已解决相同问题
- 标记变更中引入的重复函数或近乎重复的逻辑
- 标记应该调用现有辅助函数而不是重新实现的内联逻辑
推荐的子代理角色：explorer 用于广泛的代码库查找，或 reviewer 用于更强的审查。
子代理 2：代码质量审查
审查相同变更的代码质量问题：
- 冗余状态、缓存值或不必要的派生值存储
- 通过现有调用链传递新参数导致的参数膨胀
- 应该成为共享抽象的略有变化的复制粘贴
- 跨模块边界的泄漏抽象或所有权违规
- 在已有类型契约、枚举或常量存在时使用字符串类型值
推荐的子代理角色：reviewer
子代理 3：效率审查
审查相同变更的效率问题：
- 重复工作、重复读取、重复 API 调用或不必要的重新计算
- 可以安全并发运行的顺序工作
- 在启动、渲染、请求或其他热路径中添加的新工作（无明确需求）
- 当操作本身可以直接尝试并处理错误时，进行存在性预检查
- 内存增长、缺少清理或监听器/订阅泄漏
- 代码只需要子集时进行过于宽泛的读取或扫描
推荐的子代理角色：reviewer
子代理 4：清晰度和标准审查
审查相同变更的清晰度、本地标准和平衡性：
- 违反本地项目约定或模块模式
- 不必要的复杂性、深层嵌套、弱命名或冗余注释
- 过于紧凑或巧妙的代码降低可读性
- 过度简化将不同的关注点合并为一个不清晰的单元
- 死代码、死抽象或无价值的间接引用
推荐的子代理角色：reviewer
只报告能实质性提高可维护性、正确性或成本的问题。不要仅仅为了看起来不同而折腾代码。
步骤 3：汇总发现
等待所有审查子代理完成，然后合并它们的发现。
将发现规范化为以下格式：
- 文件和行或最近符号
- 类别：复用、质量、效率或清晰度
- 为什么是问题
- 推荐修复
- 置信度：高、中或低
在编辑前丢弃弱的、重复的或与指令冲突的发现。
步骤 4：谨慎修复问题
在 review-only 模式下，报告发现后停止。
在 safe-fixes 或 fix-and-validate 模式下：
- 仅应用高置信度、行为保持的修复
- 跳过需要产品或架构判断的主观重构
- 当本地模式是有意的或有指令支持时，保留它们
- 将编辑范围限制在审查的文件内，除非需要小的相邻更改来正确完成修复
优先进行以下修复：
- 用现有辅助函数替换重复代码
- 移除冗余状态或死代码
- 简化控制流而不改变行为
- 缩小过于宽泛的操作
- 在范围可控时重命名不清晰的局部变量
不要将暂存、提交或推送变更作为此技能的一部分。
步骤 5：需要时进行验证
在 fix-and-validate 模式下，编辑后为涉及的范围运行最小相关验证。
示例：
- 针对涉及模块的测试
- 针对涉及目标的类型检查或编译
- 如果格式化或 lint 检查是项目的真正安全门，则运行它们
除非变更范围证明需要更多，否则优先使用快速、范围限定的验证而非全套运行。
如果因为用户要求不运行而跳过验证，请明确说明。
步骤 6：总结结果
以简短结果结束：
- 审查了什么
- 修复了什么（如果有）
- 有意保留了什么
- 是否运行了验证
如果代码在此评分标准下已经是干净的，直接说明，而不是制造编辑。
限制
- 仅当任务明确匹配上述范围时使用此技能
- 不要将输出视为环境特定验证、测试或专家审查的替代品
- 如果缺少所需输入、权限、安全边界或成功标准，请停下来请求澄清