review-and-simplify-changes

审查并简化变更

审查变更的代码，查找复用性、质量、效率和清晰度方面的问题。使用 Codex 子 Agent 并行审查，但让这些子 Agent 保持只读：它们只能检查代码并将发现反馈给主 Agent。只有主 Agent 可以应用高置信度且不改变行为的修复。

模式

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

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

如果用户未指定，默认使用：

• 对“审查”“审计”或“检查”请求使用 review-only
• 对“简化”“清理”或“重构”请求使用 safe-fixes

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

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

1. 用户明确指定的文件或路径
2. 当前 Git 变更
3. 本次 Codex 对话中较早编辑的文件
4. 仅当用户要求审查但没有差异时，才使用最近修改的受 Git 跟踪文件

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

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

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

不要默认认为 git diff HEAD 是正确的选择；有范围更小的命令时应优先使用。

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

• AGENTS.md
• 仓库工作流文档
• 变更模块的架构或风格文档

根据这些指引区分实际问题和有意采用的本地模式。

第 2 步：并行启动四个只读审查子 Agent

当范围足够大、并行审查能提高效率时，使用 Codex 子 Agent。对于很小的差异或单个小文件，可以在本地审查。

启动子 Agent 时：

• 为每个子 Agent 提供相同的范围
• 告知每个子 Agent 只检查其分配的审查方向
• 告知每个子 Agent 当前进行的是只读审查
• 不允许子 Agent 编辑文件、运行 apply_patch、暂存变更、提交或执行其他会改变状态的操作
• 要求只返回简洁、结构化的发现
• 要求每条发现包含文件、行号或符号、问题、建议修复方案和置信度
• 要求子 Agent 只向主 Agent反馈发现；不得自行实施修复

采用以下四种审查方向。

子 Agent 1：代码复用审查

从复用角度审查变更：

1. 查找现有的辅助函数、工具或共享抽象，确认它们是否已能解决同一问题。
2. 指出变更中引入的重复函数或高度相似的逻辑。
3. 指出应调用现有辅助函数而非重新实现的内联逻辑。

该子 Agent 只读，不得编辑文件、应用补丁或以其他方式更改工作区。

建议的子 Agent 角色：适合广泛搜索代码库的 explorer，或适合深入审查的 reviewer。

子 Agent 2：代码质量审查

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

1. 冗余状态、不必要的缓存值或派生值
2. 在现有调用链中传递新参数导致的参数膨胀
3. 仅有细微差异、应提取为共享抽象的复制粘贴代码
4. 跨模块边界的抽象泄漏或所有权问题
5. 在已有类型化契约、枚举或常量的情况下仍使用字符串表示的值

该子 Agent 只读，不得编辑文件、应用补丁或以其他方式更改工作区。

建议的子 Agent 角色：reviewer

子 Agent 3：效率审查

检查相同的更改是否存在效率问题：

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

此子 Agent 只读，不得编辑文件、应用补丁或对工作区进行任何其他更改。

建议的子 Agent 角色：reviewer

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

检查相同的更改是否符合清晰度、本地规范和合理性要求：

1. 违反项目本地约定或模块模式
2. 不必要的复杂性、过深的嵌套、不清晰的名称或冗余注释
3. 过于精简或取巧，导致可读性下降的代码
4. 过度简化，将不同关注点合并成一个含义不清的单元
5. 死代码、无用抽象或没有价值的间接层

此子 Agent 只读，不得编辑文件、应用补丁或对工作区进行任何其他更改。

建议的子 Agent 角色：reviewer

仅报告能够实质性提升可维护性、正确性或成本效益的问题。不要为了让代码看起来不同而反复改动。

第 3 步：汇总发现

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

主 Agent 负责此步骤。仅将子 Agent 的输出视为审查输入，不得据此授权将代码更改委派给其他 Agent。

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

1. 文件及行号或最近的符号
2. 类别：复用、质量、效率或清晰度
3. 问题所在
4. 建议的修复方法
5. 置信度：高、中或低

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

第 4 步：谨慎修复问题

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

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

• 对此技能，只有主 Agent 可以应用修复
• 仅应用高置信度且保持行为不变的修复
• 跳过需要产品或架构判断的主观重构
• 如果本地模式是有意为之或有指令依据，则予以保留
• 将编辑限制在已审查的文件内；只有正确完成修复所必需时，才进行少量相邻更改

优先考虑以下修复：

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

此技能不包含暂存、提交或推送更改。

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

在 fix-and-validate 模式下，主 Agent 完成编辑后，应针对已修改范围运行最小必要验证。

例如：

• 针对已修改模块运行定向测试
• 对已修改目标进行类型检查或编译
• 如果格式化或 lint 检查是项目实际使用的安全门槛，则运行相应检查

优先进行快速、范围明确的验证；除非更改范围足以证明有必要，否则不要运行完整测试套件。

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

第 6 步：总结结果

用简短的总结收尾，说明：

• 审查了哪些内容
• 修复了什么（如有）
• 有意保留了什么
• 是否运行了验证

如果代码已经符合这套审查标准，请直接说明，不要凭空制造需要修改的地方。