mcpField
S
skill-optimizer

skill-optimizer

github.com/chujianyunAgent 工作流749167 次安装2 周前更新
代码仓库

关于 skill-optimizer

用于审查和改进 Agent Skill 的工具,侧重保留稳定完成任务所需的指令,并删减多余约束。它区分建议与已授权实施,限定修改范围,并规定针对性验证与交付说明。

主要功能

  1. 01检查指令缺漏与冗余
  2. 02遵守授权和修改边界
  3. 03按需选择相关参考资料
  4. 04仅在批准范围内修改
  5. 05验证修改并报告限制

适用场景

  1. 01修改前诊断某个 Skill
  2. 02实施明确授权的 Skill 修订
  3. 03检查引用、安全边界与验证方式

安装

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

$npx skills add https://github.com/chujianyun/skills --skill skill-optimizer

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

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

README.md
references/
review-checklist.md
skill-creation-best-practices-claude-api-docs.md
skill-design-review-framework.md

详细介绍

来自项目 README

Skill Optimizer

用尽量少、确实有效的指令,让 Skill 稳定完成任务。既检查缺失的保障,也检查多余的约束;保留原样可以是合理结论。

授权与边界

根据完整对话和适用的仓库规则判断授权,不依赖固定确认词:

  • 只问“怎么优化”“先看看”,或尚未授权实施:审查并给出方案,停在建议阶段。
  • 已明确授权修改或执行方案:先审查、说明改动范围,再连续完成范围内修改和必要验证,不重复请求同一授权。
  • “有道理”“我看看”等评价本身不代表授权。只有授权确实影响下一步且无法从上下文判断时,才问一个简短问题。
  • 删除、覆盖、重启、部署、外部写入、付费调用、凭据变更等操作,执行前核实对具体对象和影响的授权;缺少授权时说明影响并确认。优化技能的授权不等于执行目标技能中的业务操作。
  • 超出已授权范围的改动另列建议。遵守适用的上层安全规则,不因模型能力提升而取消必要边界。

工作流

1. 确定范围

定位目标 Skill 的来源与适用仓库规则;有源码仓库时优先修改源文件,再按约定安装。只围绕用户指定方向审查;没有指定方向时,先找最影响使用的几个问题。

明确本轮应交付建议还是修改结果。目标缺失且无法定位时,询问目标;缺少可选信息时采用合理假设并说明。复杂任务按需跟踪进度,不强制复制固定清单。

2. 审查并选择资料

先读目标 SKILL.md,再读取与本轮问题有关的资源。以下资料按条件选择,不要求每次全部加载:

当前问题读取资料
需要逐项检查触发、授权、依赖或验证行为审查清单 的相关部分
需要决定删减哪些指令、调整流程自由度或拆分结构设计评审框架
需要 Claude 平台的技能编写细节Claude 编写参考 的相关部分;平台限制和旧版本建议需按当前环境核实,不直接套为通用硬规则

审查围绕三个问题:目标行为是什么、现有指令哪里妨碍或缺少保障、改变后怎样验证。对于重复规则、通用常识、无条件加载和机械步骤,判断其增量价值;对于领域约束、真实故障经验和必要操作顺序,保留保障。

怀疑触发重叠时才看相关相邻技能的名称与描述,兼容分类目录,不全量读取技能库。发现疑似敏感信息时只报告类型和位置,不回显具体值。

3. 给出诊断与方案

简单调整用短段落或列表说明:目标与范围、问题及依据、拟改文件与预期行为、验证方式。没有问题就说明保留理由。

复杂重构再按优先级展开,并在有帮助时说明模式、依赖、风险及范围外建议。每项修改都应能解释收益;不为凑齐模板增加问题、文件或操作。依照上面的授权边界决定实施或结束本轮建议。

4. 实施

只修改已授权范围。删除或合并重复、失效、无增量价值的说明,保留有效的领域知识和安全边界。将必须遵守的约束、可靠的默认做法与可自主选择的方法区分清楚。

  • 根文档保留必要流程、边界、完成条件和资源路由;细节确实能按需加载时才拆分,并从根文档直接链接。
  • README、索引、模板、脚本按实际读者需求和仓库要求添加,不作为每个 Skill 的必备附件。
  • 需要稳定重复执行的确定性操作可脚本化;依赖应说明安装、校验和缺失时的处理方式。提供安装命令不代表获得安装或付费授权。
  • 未知模型保持通用说明;已知多模型使用时按风险选择代表场景,不以某个模型能力作为删除保障的依据。
5. 验证与收尾

检查修改涉及的 frontmatter、名称与目录一致性、触发语义、引用路径、规则冲突和仓库要求。检查真实加载路径是否减少无关内容,而非只比较正文长度。

按改动选择代表场景,验证应触发与不应触发、建议与实施授权、完成条件或失败处理;具体方法见按需加载的审查清单。纯静态审查不能证明运行效果,也不为措辞调整搭建复杂评测。

运行必要检查,修复本次引入的问题,再重跑受影响项。通过后进入收尾,不无理由扩大或重复测试。缺少工具、网络、鉴权或测试环境时,说明未验证项与原因;不得伪造结果或在失败后宣称完成。只读诊断不需要安装依赖;必需输入或授权缺失时暂停依赖它的操作。

完成标准:范围内修改已落实,相关验证有结论,适用且已授权的安装、提交和推送等交付步骤已完成。遇到无法自行解决的失败,报告已完成部分及具体阻塞,不把首版修改当作全部完成。

输出契约

  • 建议阶段:交付有依据的诊断和可执行方案,说明本轮没有修改文件。
  • 实施阶段:简要说明修改文件、行为变化、检查结果及仍未验证的部分;涉及安装或版本交付时报告实际状态。
  • 区分静态审查、场景推演和实际运行;只有实际测量后才声称触发率、完成率、耗时或上下文用量改善。

评论

支持 Markdown