skill-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Skill Review

技能评审

IRON LAW: Be specific and actionable. Never say "could be improved" without stating exactly what to change and why it matters for model output quality.
铁律:要具体且可落地。绝不能只说“可以改进”,而不明确说明要改什么以及这对模型输出质量的重要性。

Workflow

工作流

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)
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)

Step 1: Load Target ⚠️ REQUIRED

步骤1:加载目标 ⚠️ 必需

Identify the skill to review. Accept:
  • Explicit path:
    /skill-review path/to/skill
  • Current directory context: if user is already in a skill folder
  • Skill name: search within the workspace for matching skill directory
Read the full SKILL.md and list all files in the skill directory. Count SKILL.md line count — this is a key metric.
确定要评审的技能。接受以下方式:
  • 明确路径:
    /skill-review path/to/skill
  • 当前目录上下文:若用户已处于技能文件夹中
  • 技能名称:在工作区内搜索匹配的技能目录
完整读取SKILL.md并列出技能目录中的所有文件。统计SKILL.md的行数——这是一个关键指标。

Step 2: Analyze ⚠️ REQUIRED

步骤2:分析 ⚠️ 必需

Load references/review-criteria.md for detailed criteria. Evaluate the skill across five dimensions:
加载references/review-criteria.md获取详细评审标准。从五个维度评估技能:

2.1 Structure Compliance

2.1 结构合规性

Questions to answer:
  • Does the directory follow the standard layout (SKILL.md, scripts/, references/, assets/)?
  • Is SKILL.md under 500 lines?
  • Does frontmatter contain only
    name
    and
    description
    (plus optional
    allowed-tools
    ,
    license
    ,
    metadata
    )?
  • Are there unnecessary files (README.md, CHANGELOG.md, LICENSE duplicates)?
  • Are references organized by domain with one level of nesting?
需解答的问题:
  • 目录是否遵循标准布局(SKILL.md、scripts/、references/、assets/)?
  • SKILL.md的行数是否在500行以内?
  • 前置元数据(frontmatter)是否仅包含
    name
    description
    (以及可选的
    allowed-tools
    license
    metadata
    )?
  • 是否存在冗余文件(README.md、CHANGELOG.md、LICENSE重复文件)?
  • 参考资料是否按领域组织且仅嵌套一层?

2.2 Description Quality

2.2 描述质量

Questions to answer:
  • Does the description include concrete trigger keywords and phrases?
  • Does it use keyword bombing (multiple phrasings of the same intent)?
  • Is it self-contained — can a router understand what this skill does without reading the body?
  • Does it avoid putting "When to Use" info in the body instead of the description?
  • Would a user's natural language query match this description?
需解答的问题:
  • 描述是否包含具体的触发关键词和短语?
  • 是否存在关键词堆砌(同一意图使用多种表述)?
  • 是否具备自包含性——路由无需阅读正文就能理解该技能的功能?
  • 是否避免将“使用场景”信息放在正文而非描述中?
  • 用户的自然语言查询是否能匹配该描述?

2.3 Workflow Design

2.3 工作流设计

Questions to answer:
  • Is there a trackable checklist with copy-paste-friendly format?
  • Are critical steps marked with ⚠️ REQUIRED or ⛔ BLOCKING?
  • Are there confirmation gates before destructive/generative operations?
  • Is the workflow linear and progressive, or does it jump around?
  • Are sub-steps used where complexity demands it?
需解答的问题:
  • 是否具备可追踪的 checklist 且格式便于复制粘贴?
  • 关键步骤是否标记了 ⚠️ REQUIRED 或 ⛔ BLOCKING?
  • 在执行破坏性/生成性操作前是否有确认环节?
  • 工作流是线性递进的,还是跳步式的?
  • 在复杂度较高的场景下是否使用了子步骤?

2.4 Token Efficiency

2.4 Token效率

Questions to answer:
  • Is there an Iron Law or core constraint at the top?
  • Does SKILL.md only contain what Claude doesn't already know?
  • Are references loaded progressively (on-demand) rather than all upfront?
  • Are instructions in imperative form (not "You should...")?
  • Are scripts executed rather than loaded into context?
  • Is there redundancy between SKILL.md and reference files?
需解答的问题:
  • 顶部是否有铁律或核心约束?
  • SKILL.md是否仅包含Claude未知的内容?
  • 参考资料是否按需渐进加载(而非一次性全部加载)?
  • 指令是否采用祈使语气(而非“你应该……”)?
  • 脚本是否执行而非加载到上下文?
  • SKILL.md与参考文件之间是否存在冗余内容?

2.5 Anti-Pattern Detection

2.5 反模式检测

Check for these known bad patterns:
  • Vague directives ("ensure good quality", "make it better")
  • Placeholder residue (TODO, FIXME, xxx, TBD)
  • Over-specification of things Claude already knows
  • No anti-patterns section (model has no guardrails against lazy defaults)
  • Missing pre-delivery checklist (no concrete verification criteria)
  • Giant monolithic SKILL.md with no reference extraction
  • Instructions that describe WHAT rather than constrain HOW
检查以下已知不良模式:
  • 模糊指令(“确保高质量”、“做得更好”)
  • 占位符残留(TODO、FIXME、xxx、TBD)
  • 过度指定Claude已知的内容
  • 缺少反模式章节(模型无防范惰性默认值的约束)
  • 缺少交付前checklist(无具体验证标准)
  • 庞大的单体式SKILL.md,未提取参考内容
  • 指令仅描述要做什么,而非约束怎么做

Step 3: Report ⚠️ REQUIRED

步骤3:生成报告 ⚠️ 必需

Output Format

输出格式

Present the review in this order:
1. Strengths — What this skill does well. Be specific: quote the actual lines or patterns that work. Minimum 2 strengths, even for weak skills (find what's salvageable).
2. Suggestions — Improvements sorted by impact (highest first). Each suggestion must include:
  • What: the specific issue found
  • Where: file and location
  • Fix: concrete actionable change (show before/after when helpful)
Group suggestions by dimension only if there are many (5+). Otherwise present as a flat prioritized list.
按以下顺序呈现评审结果:
1. 优势 —— 该技能做得好的地方。要具体:引用有效的实际行或模式。即使是质量较差的技能,也需列出至少2项优势(找出可保留的部分)。
2. 建议 —— 按影响优先级排序的改进方案。每条建议必须包含:
  • 问题:发现的具体问题
  • 位置:文件及所在位置
  • 修复方案:具体可落地的修改建议(必要时展示修改前后的对比)
仅当建议数量较多(5条及以上)时,才按维度分组。否则按优先级以扁平列表呈现。

Tone

语气

  • Direct, constructive, collegial
  • Lead with genuine strengths — not filler praise
  • Suggestions are opportunities, not failures
  • If the skill is already solid, say so briefly and move on
  • 直接、有建设性、友好协作
  • 先列出真实的优势——而非空洞的赞美
  • 将建议视为改进机会,而非错误
  • 若技能已足够完善,可简要说明后结束评审

Anti-Patterns for This Skill

本技能的反模式

  • Giving vague praise ("nice structure!") without quoting what specifically works
  • Listing problems without actionable fixes
  • Reviewing against personal taste rather than the documented principles
  • Suggesting over-engineering for simple skills
  • Flagging missing features that the skill intentionally omits (check if simplicity is the point)
  • 给出模糊的赞美(“结构不错!”)却不具体说明哪里做得好
  • 只列出问题却不提供可落地的修复方案
  • 基于个人偏好而非文档化原则进行评审
  • 建议对简单技能过度设计
  • 标记技能有意省略的功能为缺失项(需确认简洁性是否为设计初衷)