mcpField
S
simplify

simplify

github.com/karlorz开发161 次安装3 天前更新
代码仓库

关于 simplify

simplify 是一项贴合代码仓库的技能，用于审查变更代码并在不改变预期行为的前提下清理。它从复用、简化、效率和实现层次四个角度审查，并验证相关改动。

主要功能

  1. 01审查指定差异或文件
  2. 02从四个角度检查清理机会
  3. 03条件允许时并行委派审查
  4. 04去重并应用高可信修复
  5. 05执行有针对性的验证

适用场景

  1. 01提交前简化代码变更
  2. 02对比 main 审查分支差异
  3. 03清理指定文件或拉取请求

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/karlorz/agent-skills --skill simplify

安装后在 Claude Code 中输入/simplify确认已加载。

详细介绍

简化

使用此技能改进已更改的代码，同时不改变预期行为。这是一个独立编写、原生适配于代码库的语义版本，基于四个角度的 /simplify 工作流：

/simplify -> 4 cleanup agents in parallel -> apply the fixes

此适配版本不声称与某个特定 Claude Code 软件包版本完全一致，也不会复现 Anthropic 的提示词文本。官方 npm 软件包仅用于获取版本和软件包元数据；其编译内容属于专有内容，不会作为可读的提示词源代码处理或重新分发。我们于 2026-09-16 根据该元数据及可读的次级参考 Piebald（提交 c10ea52363b3fce1ebfc355565412711e9e82bc1）审查了出处。该参考指出，四角度形式始于 Claude Code 2.1.154；截至 v2.1.273 快照，其工作流在行为上始终未变。

这不是一项查找正确性缺陷的工作。请检查代码复用、简化、效率和抽象层次问题；缺陷查找应交由代码审查或调试工作流处理。

用法

/simplify                         # Review the current diff
/simplify HEAD~3                  # Review changes from HEAD~3 to HEAD
/simplify main                    # Review changes against main
/simplify path/to/file.ts         # Review an explicit file target
/simplify 123                     # Review an explicit PR target when supported
/simplify focus on error handling # Keep the same flow, with added focus

阶段 0 - 收集差异

将收集到的差异作为审查范围。

  1. 如果用户提供了 PR 编号、分支名称或文件路径，请审查该目标，而不是猜测默认范围。
  2. 否则，优先使用 git diff @{upstream}...HEAD。
  3. 如果没有上游，则依次回退到 git diff main...HEAD 和 git diff HEAD~1。
  4. 如果存在未提交更改，或所选范围的差异为空，也运行 git diff HEAD 并纳入工作树中的更改。此审查通常会在下一次提交前运行。
  5. 如果所有差异命令都没有输出，则只审查用户明确指定的文件，或当前会话中先前已更改的文件。如果仍然没有审查范围，请说明没有需要简化的已更改代码。

保持范围精简。除非用户要求进行更广泛的清理，否则不要扩展到无关文件。

阶段 1 - 审查

如果平台支持并行 Agent，请在一条消息中启动 4 个独立的审查 Agent。向每个 Agent 提供相同的差异，并且只指定一个审查角度。如果无法并行委派，则自行进行相同的四项审查，并按角度区分发现的问题。

每项发现都必须包含 file、line、一行 summary，以及具体成本：哪些内容重复了、浪费了资源或更难维护。

复用

指出新增代码中重新实现了代码库已有功能的部分。搜索共享模块或工具模块，以及与改动相邻的文件，然后指出应改用的现有辅助函数、类型、组件、常量或模式。

简化

指出差异引入的不必要复杂性：冗余或可推导的状态、仅有细微差异的复制粘贴代码、过深的嵌套、遗留死代码，以及超出行为所需复杂度的控制流。指出能实现相同行为的更简单形式。

效率

指出差异引入的资源浪费：冗余计算、重复 I/O、可并行的操作却按顺序运行，以及在启动流程或热点路径中新增的阻塞操作。还要指出由闭包或捕获的环境构造的长期存活对象，因为这些对象会在其生命周期内使封闭作用域保持存活；优先使用只复制所需字段的类、结构体或普通数据对象。指出开销更低的替代方案。

抽象层次

检查每项更改是否在正确的抽象层次实现，而非采用脆弱的临时补丁。叠加在共享基础设施上的特殊情况通常意味着修复还不够深入；应优先泛化底层机制，而不是添加一次性分支。

第 2 阶段 - 应用修复

等待四项审查全部完成。然后，将指向相同代码行或机制的发现去重，再直接修复其余有充分依据的问题。

如果修复会改变预期行为、需要大幅修改审查差异范围之外的内容，或看起来属于误报，则跳过该发现。简要说明跳过原因，不要与该发现争辩。

除非用户明确要求改变行为，否则应保留现有行为、公共 API、测试和用户可见输出。

验证

针对修改的文件，运行最精简且相关的验证：定向测试、lint、类型检查或针对性构建。如果当前没有有用的验证方式，或者成本过高，则准确说明未运行的验证。

报告

最后用简短的总结说明：

  • 修复了哪些问题。
  • 跳过了哪些问题，以及原因。
  • 是否存在实际的剩余风险或后续工作。

如果没有可执行的发现，则说明更改的代码在四个简化角度上已经没有问题。

注意事项

  • 优先遵循仓库说明和本地惯例。
  • 优先采用小而可逆的编辑，避免大范围重构。
  • 不要把明确的代码改写成巧妙或难以理解的代码。
  • 避免纯风格调整造成的改动。
  • 如果简化会降低代码的可调试性，则保留更清晰的版本。

评论

支持 Markdown