kscz0000 审查与简化变更
何时使用
当你需要审查 git diff 或指定文件范围内的代码复用、质量、效率、清晰度和规范问题，然后可选地应用安全的 Codex 驱动修复时使用此技能。当用户要求"简化代码""审查变更代码""检查代码复用""审查代码质量""审查……"时触发。
审查变更代码中的复用、质量、效率和清晰度问题。使用 Codex 子代理并行审查，但保持这些子代理为只读：它们只能检查代码并将发现反馈给主代理。只有主代理可以应用高置信度、行为保持不变的修复。
模式
根据用户请求选择模式：
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 目标
- 混合暂存和未暂存的工作：两者都审查
不要假设 git diff HEAD 是正确的默认值，当更小的 diff 可用时应优先使用更小的 diff。
在审查规范或应用修复之前，读取仓库的本地指令文件和受影响区域的相关项目文档。优先使用最接近的适用指导，例如：
AGENTS.md- 仓库工作流文档
- 受影响模块的架构或风格文档
使用这些指令来区分真实问题和有意的本地模式。
步骤 2：并行启动四个只读审查子代理
当范围足够大时，使用 Codex 子代理进行并行审查。对于极小的 diff 或非常小的单个文件，可以在本地审查。
生成子代理时：
- 给每个子代理相同的范围
- 告诉每个子代理只检查其被分配的审查角色
- 告诉每个子代理它正在执行只读审查
- 不允许子代理编辑文件、运行
apply_patch、暂存变更、提交或执行其他状态变更操作 - 要求仅返回简洁、结构化的发现
- 要求每个子代理报告文件、行号或符号、问题、建议修复和置信度
- 要求每个子代理仅将发现返回给主代理；它们不得自行实施修复
使用四个审查角色。
子代理 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：总结结果
以简要结果收尾：
- 审查了什么
- 修复了什么（如果有）
- 有意保留不改的是什么
- 是否运行了验证
如果代码在此审查标准下已经干净，直接说明，而不是制造编辑。
局限性
- 仅当任务明确匹配其上游来源和本地项目上下文时使用此技能。
- 在应用变更之前，验证命令、生成的代码、依赖项、凭证和外部服务行为。
- 不要将示例替代为环境特定的测试、安全审查或用户对破坏性或高成本操作的批准。