SkillsAdd

modelscope.cn

skill-optimizer

审查并优化现有 skill 的触发语义、工作流、确认门槛、资源组织、安?

Installation

$ npx skills add https://modelscope.cn
View on skills.sh ↗ Website ↗

Also in this package

Other skills from modelscope.cn · top by installs.

npx skills add https://modelscope.cn
skill-creator 2K frontend-design 1.9K pptx-generator 1.3K minimax-docx 1.2K find-skills 1.1K minimax-xlsx 1.2K minimax-pdf 1.2K docx 942 self-improvement 932 pdf 914

Browse all from modelscope.cn

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 9,256 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Skill Optimizer

先审查，再规划，最后在确认后修改。

设计模式

本 skill 主要采用：

  • Reviewer：先判断目标 skill 的问题，再给诊断
  • Inversion：先出计划并等待确认，不直接改文件
  • Generator（轻度）：在用户确认后，输出更清晰的 skill 结构或工作流

Gotchas

  • 不要把“审查结论”和“直接开始改文件”混成一步
  • 不要为了显得全面就偷偷扩大改动面
  • 不要在没确认前修改目标 skill
  • 不要为了“审查完整”而把无关 reference 全部读进上下文
  • 如果用户明确只要某个方向优化，先围绕这个方向，不要擅自重构整个 skill
  • 如果发现疑似敏感信息，不要在回复里回显完整内容，只描述类型、位置和风险
  • 如果发现高副作用操作，不要默认放行；要补确认门槛或显式提醒用户

工作流

复制此清单并跟踪进度：

优化进度：
- [ ] 步骤 1：Scope（确定范围）
- [ ] 步骤 2：Review（审查目标 skill）
- [ ] 步骤 3：Plan（输出优化计划并等待确认）
- [ ] 步骤 4：Implement（确认后实施）
- [ ] 步骤 5：Verify（校验结果）

Step 1: Scope（确定范围）

先确认目标 skill 和本次优化范围。

  • 优先采用用户明确提出的优化方向，例如触发词、description、结构拆分、脚本化、确认流程、安全边界、README/索引设计。
  • 如果用户只说“优化这个 skill”，先做完整审查，再给出分优先级计划。
  • 如果目标 skill 不明确，只问一个最短问题，不要一次追问很多细节。

Step 2: Review（审查目标 skill）

先读目标 skill 的 SKILL.md，再按需读取它直接链接的 references/、scripts/、assets/、README.md。

  • 默认使用 [references/review-checklist.md](references/review-checklist.md) 做审查基线。
  • 默认再结合 [references/skill-design-review-framework.md](references/skill-design-review-framework.md) 判断模式是否匹配、设计是否合理。
  • 需要判断最佳实践取舍时，再读取 [references/skill-creation-best-practices-claude-api-docs.md](references/skill-creation-best-practices-claude-api-docs.md)。
  • 不要为了“审查完整”而把无关 reference 全部读入上下文。
  • 如果目标 skill 的上层目录名是 skills，可额外查看同级目录名与必要的 description，判断是否存在应合并、复用或避免抢触发的相邻 skill；不要把所有同级 skill 全量读进上下文。

重点检查：

  • 触发语义是否清楚：name、目录名、description 是否一致，且便于触发
  • 工作流是否可靠：步骤是否清晰，是否存在必须确认却没卡住的环节
  • 异常处理是否充分：缺文件、缺输入、命令失败、网络失败、鉴权失败、空结果等场景是否有降级或停机策略
  • 输出契约是否明确：审查结论、优化计划、最终修改结果是否分开
  • 结构是否合适：正文是否过胖，是否应拆到 references/ / scripts/ / assets/
  • 渐进式加载是否顺手：文件较多时，是否提供根目录或子目录索引，帮助按需加载
  • 设计是否合理：模式是否匹配，是否存在过度设计、脚本缺失或资源组织问题
  • 外部依赖是否可安装：若依赖外部 skill、CLI、服务或运行时，是否写清安装、校验和自动安装命令
  • 是否包含敏感信息：例如 API Key、Token、Cookie、账号、私有地址或其他不应随 skill 分发的内容
  • 是否包含敏感操作：删除、覆盖、部署、发送消息、批量写入、付费调用、联网改状态等高副作用操作，是否需要确认或额外提醒
  • Skill 粒度是否合理：是否过粗导致职责混杂，或过细导致触发分散、维护成本过高
  • README / SKILL 分工是否清楚：README.md 面向人，SKILL.md 面向 AI，内容是否重复或错位
  • 进度跟踪是否必要：多步骤工作流是否适合用 markdown checkbox 清单跟踪进度，若目标 skill 缺少且有必要，则提议增加

如果用户只要求微调某一部分（例如只改 description、只补 references、只修确认门槛），优先做局部审查，不要擅自把任务升级成整 skill 重构。

Step 3: Plan（输出优化计划并等待确认）

先给诊断，再给计划，不要直接改文件。

输出必须包含两个部分：

# Skill 审查结论

## 审查对象
- 目标 skill：...
- 本次范围：...

## 模式判断
- 主模式：...
- 次模式：...
- 当前判断：模式匹配 / 模式错位 / 模式不清

## 安全与依赖
- 敏感信息：未发现 / 存疑 / 已发现（仅描述类型与位置，不回显具体值）
- 敏感操作：低 / 中 / 高风险；是否需要确认门槛：是 / 否
- 外部依赖：无 / 有；安装说明是否完整：完整 / 不完整

## 高优先级
- [问题] 影响触发、正确性或执行稳定性

## 中优先级
- [问题] 影响可维护性、可复用性或上下文成本

## 低优先级
- [问题] 体验提升项，可选

## 不改动项
- ...

## 额外建议
- ...

# 优化计划
1. 修改 [目标文件路径]
   - 变更内容：
   - 原因：
   - 是否受用户指定方向驱动：是/否

仅当用户明确回复“按计划执行”“开始修改”“确认修改”等开始执行类确认语时，才能进入实施阶段。

规则：

  • 如果用户明确给了优化方向，先围绕这些方向出计划，再补充少量高价值附加建议。
  • 如果发现超出本次范围的大问题，单独列为“额外建议”，不要偷偷扩大改动面。
  • 未获得确认前，不要修改目标 skill。
  • “我看看”“有道理”“先这样”不算确认；只有明确开始执行类确认语才算进入 Step 4。
  • 如果发现疑似敏感信息或高风险副作用，计划里要单列风险与处理方案；必要时要求用户额外确认。

Step 4: Implement（确认后实施）

在用户确认后，再修改目标 skill。

  • 优先改动计划中已确认的文件。
  • 尽量小步重构；仅在确有收益时拆分新的 references/、scripts/、assets/。
  • 如果新增引用文件，确保它们都直接从目标 SKILL.md 链接，避免深层跳转。
  • 如果目标 skill 缺少 README.md，补一份面向人的 README，重点说明使用场景、主要功能、风险和边界；不要把执行细则原样复制自 SKILL.md。
  • 如果目标 skill 文件较多且不便按需加载，补充根目录或子目录索引文件，说明何时读取哪个文件。
  • 如果 skill 依赖外部 skill、CLI、服务或运行时，补上可直接执行的安装 / 校验指令，便于 AI 自动安装。
  • 如果发现疑似敏感信息，先提醒并确认，再决定删除、迁移到配置或改成占位说明。
  • 如果存在高副作用操作，补确认门槛、风险提示和禁止默认执行的规则。
  • 保留用户原有有效内容；只删除重复、失效或与新流程冲突的部分。
  • 如果用户确认语义含糊，继续停留在 Step 3，不要自行解释成“已确认”。

Step 5: Verify（校验结果）

改完后至少完成这些校验：

  • frontmatter 只包含 name 和 description
  • name、目录名、触发语义一致
  • description 能独立表达触发条件
  • SKILL.md 主体比改动前更短、更清晰，且工作流可执行
  • 新增 references/ 是否只承载细节，没有和 SKILL.md 重复大段内容
  • 文件较多时是否存在索引，且索引能帮助渐进式加载
  • 异常场景是否有处理策略或显式停止条件
  • 外部依赖是否附带安装 / 校验命令，便于自动安装
  • 是否移除了明文敏感信息，或至少显式提醒不要直接分发
  • 敏感操作是否有确认门槛、风险提示和默认禁止条件
  • Skill 粒度是否合适；若位于 skills/ 下，是否已评估同级 skill 的合并空间
  • README.md 是否存在，且明确与 SKILL.md 的分工不同
  • 如有“先审查后确认再修改”的门槛，是否在说明里写清楚
  • Step 3 模板是否明确写出范围、不改动项和可接受确认语

最后向用户汇报：

  • 已修改的文件
  • 已落实的优化方向
  • 是否新增 README / 索引 / 安装说明 / 风险确认门槛
  • 仍保留的风险或后续建议

审查标准

需要快速判定时，直接按这组优先级处理：

  1. 先修敏感信息泄露、敏感操作失控、触发失败、确认缺失、流程不可执行的问题
  2. 再修异常处理缺失、依赖不可安装、结构臃肿、重复内容、资源组织混乱的问题
  3. 最后处理粒度微调、README/索引补充、措辞润色、示例补充、可读性增强