skill-review

技能审查

铁律：具体且可执行。不要只说“可以改进”，而不明确指出要改什么，以及这对模型输出质量为何重要。

工作流

Skill Review Progress:

- [ ] Step 1: Load Target ⚠️ REQUIRED
  - [ ] 1.1 Identify skill path
  - [ ] 1.2 Read SKILL.md and inventory all files
- [ ] Step 2: Analyze ⚠️ REQUIRED
  - [ ] 2.1 Structure compliance
  - [ ] 2.2 Description quality
  - [ ] 2.3 Workflow design
  - [ ] 2.4 Token efficiency
  - [ ] 2.5 Anti-pattern detection
- [ ] Step 3: Report ⚠️ REQUIRED
  - [ ] 3.1 Strengths (what's done well)
  - [ ] 3.2 Suggestions (prioritized improvements)

步骤 1：加载目标 ⚠️ REQUIRED

确定要审查的技能。接受以下方式：

• 明确路径：/skill-review path/to/skill
• 当前目录上下文：用户已在某个技能文件夹中
• 技能名称：在工作区中搜索匹配的技能目录

阅读完整的 SKILL.md，并列出技能目录中的所有文件。统计 SKILL.md 的行数——这是一个关键指标。

步骤 2：分析 ⚠️ REQUIRED

加载 references/review-criteria.md，查看详细标准。从以下五个维度评估技能：

2.1 结构合规性

需要回答的问题：

• 目录是否遵循标准布局（SKILL.md、scripts/、references/、assets/）？
• SKILL.md 是否少于 500 行？
• frontmatter 是否只包含 name 和 description（以及可选的 allowed-tools、license、metadata）？
• 是否存在不必要的文件（README.md、CHANGELOG.md、重复的 LICENSE）？
• references 是否按领域组织，且嵌套不超过一层？

2.2 描述质量

需要回答的问题：

• 描述是否包含具体的触发关键词和短语？
• 是否存在关键词堆砌（同一意图的多种表述）？
• 描述是否自包含——路由器能否不阅读正文就理解该技能的用途？
• 是否避免把“何时使用”的信息放在正文中，而不是描述中？
• 用户的自然语言查询能否匹配此描述？

2.3 工作流设计

需要回答的问题：

• 是否有便于跟踪、可直接复制粘贴的清单？
• 关键步骤是否标记为 ⚠️ REQUIRED 或 ⛔ BLOCKING？
• 在执行破坏性或生成性操作前，是否设置了确认关卡？
• 工作流是线性渐进的，还是会跳来跳去？
• 复杂处是否使用了子步骤？

2.4 Token 效率

需要回答的问题：

• 开头是否有铁律或核心约束？
• SKILL.md 是否只包含 Claude 尚不了解的内容？
• 是否按需渐进加载 references，而不是一开始就全部加载？
• 指令是否采用祈使句（而不是“You should...”）？
• 是否通过执行脚本，而不是将脚本内容加载到上下文中？
• SKILL.md 与参考文件之间是否存在冗余？

2.5 反模式检测

检查以下已知的不良模式：

• 模糊指令（“确保质量良好”“让它更好”）
• 占位内容残留（TODO、FIXME、xxx、TBD）
• 对 Claude 已经了解的内容过度规定
• 缺少反模式部分（模型没有防止使用懒惰默认做法的约束）
• 缺少交付前检查清单（没有具体的验证标准）
• SKILL.md 过于庞大且一体化，没有提取参考内容
• 描述“做什么”而非约束“如何做”的指令

步骤 3：报告 ⚠️ REQUIRED

输出格式

按以下顺序呈现审查结果：

1. 优势——说明该技能哪些方面做得好。具体指出有效的实际行文或模式。至少列出 2 项优势，即使技能较弱也要找出可取之处。

2. 建议——按影响从高到低排序。每项建议必须包括：

• 问题：发现的具体问题
• 位置：文件和位置
• 改进方法：具体且可执行的修改（必要时展示修改前后对比）

只有在建议较多（5 项以上）时，才按维度分组；否则按优先级平铺列出。

语气

直接、建设性、友善协作。 先说明真实的优势——不要空泛地称赞。 建议应视为改进机会，而非失败。如果技能已经完善，简要说明后即可。

此技能的反模式

• 只给出含糊的赞扬（“结构不错！”），却不引用具体优点
• 只列出问题，却不提供可执行的修复建议
• 根据个人偏好而非文档中说明的原则进行评审
• 建议为简单的技能过度设计
• 指出技能有意省略的功能缺失（请先确认保持简洁是否是设计目的）