# Simplify Code

> 审查代码差异的清晰度和安全性简化，然后可选择性地应用低风险修复。触发词：代码简化、代码审查、代码清理、代码重构、diff审查

- Skill: `kscz0000/simplify-code` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kscz0000/simplify-code`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/simplify-code/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kscz0000 (https://skillmd.com/u/kscz0000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kscz0000/simplify-code

---


# 代码简化

审查变更代码的复用性、质量、效率和清晰度问题。使用 Codex 子代理并行审查，然后可选择性地仅应用高置信度、行为保持的修复。

## 使用场景
- 当用户要求简化、清理、重构或审查变更代码时
- 当你需要对限定范围的 diff 进行高置信度、行为保持的改进时

## 模式

根据用户请求选择模式：

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

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

- 对于"审查"、"审计"或"检查"使用 `review-only`
- 对于"简化"、"清理"或"重构"使用 `safe-fixes`

## 步骤 1：确定范围和 Diff 命令

优先使用此范围顺序：

1. 用户明确指定的文件或路径
2. 当前 git 变更
3. 当前 Codex 轮次中编辑过的文件
4. 最近修改的跟踪文件（仅当用户要求审查但没有 diff 时）

如果没有明确范围，请简短说明。

使用 git 变更时，根据仓库状态确定最小正确的 diff 命令：

- 未暂存的工作：`git diff`
- 已暂存的工作：`git diff --cached`
- 用户明确请求的分支或提交比较：使用该确切的 diff 目标
- 混合暂存和未暂存的工作：同时审查两者

当有更小的 diff 可用时，不要假设 `git diff HEAD` 是正确的默认值。

在审查标准或应用修复之前，读取仓库的本地指令文件和相关项目文档（针对涉及的区域）。优先使用最接近的适用指导，例如：

- `AGENTS.md`
- 仓库工作流文档
- 涉及模块的架构或样式文档

使用这些指令来区分真正的问题和有意的本地模式。

## 步骤 2：并行启动四个审查子代理

当范围足够大时，使用 Codex 子代理进行并行审查。对于极小的 diff 或单个非常小的文件，可以在本地审查。

生成子代理时：

- 给每个子代理相同的范围
- 告诉每个子代理只检查其分配的审查角色
- 只要求简洁、结构化的发现
- 要求每个子代理报告文件、行或符号、问题、推荐修复和置信度

使用四个审查角色。

### 子代理 1：代码复用审查

审查变更的复用机会：

1. 搜索已有的辅助函数、工具或共享抽象，看是否已解决相同问题
2. 标记变更中引入的重复函数或近乎重复的逻辑
3. 标记应该调用现有辅助函数而不是重新实现的内联逻辑

推荐的子代理角色：`explorer` 用于广泛的代码库查找，或 `reviewer` 用于更强的审查。

### 子代理 2：代码质量审查

审查相同变更的代码质量问题：

1. 冗余状态、缓存值或不必要的派生值存储
2. 通过现有调用链传递新参数导致的参数膨胀
3. 应该成为共享抽象的略有变化的复制粘贴
4. 跨模块边界的泄漏抽象或所有权违规
5. 在已有类型契约、枚举或常量存在时使用字符串类型值

推荐的子代理角色：`reviewer`

### 子代理 3：效率审查

审查相同变更的效率问题：

1. 重复工作、重复读取、重复 API 调用或不必要的重新计算
2. 可以安全并发运行的顺序工作
3. 在启动、渲染、请求或其他热路径中添加的新工作（无明确需求）
4. 当操作本身可以直接尝试并处理错误时，进行存在性预检查
5. 内存增长、缺少清理或监听器/订阅泄漏
6. 代码只需要子集时进行过于宽泛的读取或扫描

推荐的子代理角色：`reviewer`

### 子代理 4：清晰度和标准审查

审查相同变更的清晰度、本地标准和平衡性：

1. 违反本地项目约定或模块模式
2. 不必要的复杂性、深层嵌套、弱命名或冗余注释
3. 过于紧凑或巧妙的代码降低可读性
4. 过度简化将不同的关注点合并为一个不清晰的单元
5. 死代码、死抽象或无价值的间接引用

推荐的子代理角色：`reviewer`

只报告能实质性提高可维护性、正确性或成本的问题。不要仅仅为了看起来不同而折腾代码。

## 步骤 3：汇总发现

等待所有审查子代理完成，然后合并它们的发现。

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

1. 文件和行或最近符号
2. 类别：复用、质量、效率或清晰度
3. 为什么是问题
4. 推荐修复
5. 置信度：高、中或低

在编辑前丢弃弱的、重复的或与指令冲突的发现。

## 步骤 4：谨慎修复问题

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

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

- 仅应用高置信度、行为保持的修复
- 跳过需要产品或架构判断的主观重构
- 当本地模式是有意的或有指令支持时，保留它们
- 将编辑范围限制在审查的文件内，除非需要小的相邻更改来正确完成修复

优先进行以下修复：

- 用现有辅助函数替换重复代码
- 移除冗余状态或死代码
- 简化控制流而不改变行为
- 缩小过于宽泛的操作
- 在范围可控时重命名不清晰的局部变量

不要将暂存、提交或推送变更作为此技能的一部分。

## 步骤 5：需要时进行验证

在 `fix-and-validate` 模式下，编辑后为涉及的范围运行最小相关验证。

示例：

- 针对涉及模块的测试
- 针对涉及目标的类型检查或编译
- 如果格式化或 lint 检查是项目的真正安全门，则运行它们

除非变更范围证明需要更多，否则优先使用快速、范围限定的验证而非全套运行。

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

## 步骤 6：总结结果

以简短结果结束：

- 审查了什么
- 修复了什么（如果有）
- 有意保留了什么
- 是否运行了验证

如果代码在此评分标准下已经是干净的，直接说明，而不是制造编辑。

## 限制
- 仅当任务明确匹配上述范围时使用此技能
- 不要将输出视为环境特定验证、测试或专家审查的替代品
- 如果缺少所需输入、权限、安全边界或成功标准，请停下来请求澄清