关于 code-simplify
code-simplify 是一项用于提升代码可读性和可维护性的技能，要求保持行为不变。它引导编码 Agent 明确范围、先检查基线，再谨慎修改并验证。
主要功能
- 01界定安全的简化范围
- 02先检查代码、调用方和测试
- 03建立针对性验证基线
- 04进行局部可读性改进
- 05重新运行检查以确认行为
适用场景
- 01简化文件中的嵌套条件
- 02在小范围清理中移除无用代码
- 03理清难读的表达式
- 04验证小型重构未改变行为
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/code-simplify确认已加载。
附带文件references/simplification-patterns.md
详细介绍
此技能会编辑代码。以下规则不可妥协：
1. 更改任何内容前，先阅读目标代码、附近的调用方和相关测试。
2. 可行时，在编辑前确定范围最小且有用的基线检查。
3. 保持行为、副作用和错误处理不变。
4. 只有在范围不明确、简化存在风险或确实有多种选择时，才询问用户。
5. 让调用主体聚焦于简化循环；仅在需要时从参考资料中加载详细模式。
代码简化
输入
$request：可选的范围或简化指导，例如文件路径、符号名称，或类似flatten nested conditionals的说明。
目标
以最小且安全的可读性改进为目标，让目标代码更易理解和维护，同时不改变其行为。
步骤 0：明确范围并评估适用性
确定：
- 要简化的确切文件、符号或差异范围
- 用户要求的是针对性清理还是更广泛的检查
- 目标是应用代码、测试、生成代码还是性能敏感路径
在以下情况下停止或请求澄清：
- 请求过于含糊，无法安全确定目标
- 代码是生成的
- 所谓的“简化”实际上属于重新设计
- 更改显然会影响公开行为或契约
仅当歧义妨碍安全推进，或存在多个合理的简化方向时，才使用 AskUserQuestion。
成功标准：简化范围明确，并且适合局部清理工作流。
步骤 1：了解行为并建立基线
编辑前先阅读实际代码：
- 目标文件
- 附近的调用方、导出项和相邻辅助函数
- 覆盖目标行为的现有测试
然后确定：
- 输入和输出
- 副作用和持久化边界
- 错误处理和保护性条件
- 必须保持不变的外部可见契约
验证基线：
- 可行时，运行范围最小的相关测试、类型检查、Lint 目标或构建步骤
- 如果没有范围更小的验证方式，请明确说明，并以更谨慎的方式继续
运行时专属规则：
- 不要每次都机械地要求重新阅读
CLAUDE.md - Claude Code 已通过
getUserContext将CLAUDE.md层级内容注入对话上下文 - 仅当目标区域有自己的约定或周边代码存在歧义时，才额外阅读本地文档
成功标准：开始编辑前，当前行为和验证基线均已明确。
步骤 2：找出可简化之处
寻找能够降低局部复杂度、又不会演变为重新设计的更改：
- 使用保护性条件或提前返回来减少深层嵌套
- 将难以理解的表达式提取为命名变量或辅助函数
- 重命名容易误导或含义晦涩的局部符号
- 删除死代码和未使用的分支
- 合并明显重复的内容
- 简化布尔逻辑和条件分支
- 在调用位置仍然易于理解的前提下，减少参数冗余
对每个候选项记录：
- 位置
- 类别
- 风险：
low、medium或high - 所需验证
如需详细了解模式目录、反模式和风险指导，请加载 references/simplification-patterns.md。
成功标准：形成一组具体候选项，并按风险和预期收益排序。
第 3 步：选择范围最小且安全的变更集
默认行为：
- 直接应用风险低且明显有益的简化
- 按文件或紧密耦合的调用点批量处理相关编辑
- 优先进行一次小而整洁的处理，而非大范围「全部清理」式改动
在以下情况下，继续前先询问用户：
- 最佳简化路径并不明确
- 变更风险中等或较高
- 存在多个互不相关的清理机会，需要确定范围
- 重命名或提取会影响广泛的公共接口
对于简单且明显安全的清理，不要要求用户走形式化的变更前后审批流程。
成功标准：预期编辑范围有限、理由充分，且与用户请求相称。
第 4 步：应用简化
按最安全的顺序进行变更：
- 移除死代码并进行简单的布尔逻辑清理
- 展平结构并提取局部代码
- 合并重复内容
- 进行范围更广的重命名或提取小型辅助函数
编辑期间遵循以下规则：
- 除非用户明确要求进行更大范围的清理，否则保留函数签名
- 保留错误处理和可观察到的副作用
- 重命名共享符号前先搜索其引用
- 如果必须创建辅助文件，将其放在相邻位置，并严格限制其作用范围
- 如果清理开始演变为架构改造，就停止
成功标准：已实现所请求的简化，且未意外扩大范围。
第 5 步：验证行为是否保留
重新运行第 1 步中最相关、范围最窄的检查：
- 优先运行针对性测试
- 适用时进行类型检查或编译
- 仅在受影响区域需要时运行更全面的检查
然后确认：
- 基线检查仍然通过
- 未引入新的类型错误或语法错误
- 代码确实更清晰，而不只是更短
如果简化导致回归或影响不明确：
- 撤销最近一次有风险的变更
- 保留安全的改进
- 报告受阻的候选项，不要强行推进
成功标准：验证结果达到或优于基线，且行为未发生变化。
防护原则
- 不要主动将此技能用于无关工作。
- 不要以简化为名添加功能、注释或架构重构。
- 不要简化生成的代码。
- 除非用户明确要求清理测试，否则不要简化测试。
- 不要以减少行数为目标；应以降低认知负担为目标。
- 不要添加
disable-model-invocation；用户明确要求简化时，模型必须能够调用此技能。 - 不要添加
context: fork；此工作流会编辑当前工作上下文，适合内联执行。 - 不要添加
paths:；这是通用工作流技能，不是按路径激活的领域参考资料。 - 不要将完整的模式目录内联保留在
SKILL.md中。
何时加载参考资料
references/simplification-patterns.md当目标代码并不简单时，用于查阅详细的模式示例、风险指导、反模式和升级处理启发式规则。
输出约定
报告：
- 已确定的范围
- 已运行的基线检查，或明确说明验证缺口
- 按文件和类别列出的已应用简化
- 验证结果
- 跳过或延期的机会及原因
评论
支持 Markdown