Claude 社区注册了 80,000+ 个 Skills。

大多数都很糟糕。

它们在错误的请求时触发，输出不一致，在边缘情况下崩溃，写得太模糊导致 Claude 每次解读都不同。那些真正可靠的 Skills——每次都能产生高质量、一致输出的——都共享相同的设计模式。这个指南教你这些模式。

Skills 是什么

一个 Claude Skill 是一个叫 SKILL.md 的 markdown 文件，教会 Claude 如何执行特定任务。可以把它想象成给新员工的培训手册。

my-skill/ ├── SKILL.md → 指令 └── references/ → 可选支撑文件 ├── examples.md └── template.md

整个结构就这么简单。但 SKILL.md 内部的质量决定了这个 Skill 是无用的还是无价的。

可靠 Skills 的五个组成部分

每个可靠的 Skill 都有五个组成部分。跳过任何一个，输出就不一致。

1. YAML Header：精准触发

文件顶部的 YAML 元数据告诉 Claude 何时激活这个 Skill。

---
name: proposal-generator
description: >
  Generates professional business proposals from basic project details.
  Use this skill whenever the user says 'write a proposal', 'draft a
  proposal', 'create a proposal', 'I need a proposal for', or 'proposal
  for [client name]'. Also activate when the user provides project scope
  and asks for a client-ready document. Do NOT use for internal project
  plans, SOWs, or technical specifications — those are different
  document types.
---

description 是整个 Skill 里最重要的一行。太弱 → Skill 从不触发；太宽 → 在不该触发时触发。

三条规则：

规则 1：触发词要"令人尴尬地"明确。 至少列出 5-7 个用户可能说的触发短语。Claude 很保守，不明确匹配就不会触发。

规则 2：写负面边界。 告诉 Claude 什么时候不要触发："Do NOT use for X, Y, or Z." 这防止 Skill 劫持无关对话。

规则 3：用第三人称写。 "Generates proposals..." 而非 "I can help you with proposals..." 第三人称是 Claude 最可靠处理 Skill 描述的方式。

2. Overview

YAML Header 下方，一段概述，告诉 Claude 这个 Skill 做什么、什么时候激活。用 Claude 的视角写，不是给人类读者。

3. Workflow：编号顺序步骤

Skill 的核心。把任务分解为编号的、顺序的步骤。每条步骤必须：

  • 一个清晰的动作
  • 用祈使句（"Read the file..." 而非 "The file should be read..."）
  • 足够具体，只有唯一一种解读方式

4. Output Format：可测试的格式定义

告诉 Claude 输出的样子要精确到可以测试。"Format nicely" 无法测试；"Use H2 headings for each section, bold the first sentence of each section, keep paragraphs under 3 sentences" 是可测试的。这个区别决定输出是一致还是随机的。

5. Examples：价值五十行指令的一个示例

## Examples

### Good Output Example:
**Input:** "Proposal for Acme Corp, website redesign, 3 months, $15,000"
**Output:**
[展示你想要的完整输出——正确的语气、格式、细节层次、结构]

### Edge Case Example:
**Input:** "Proposal for a client, not sure about pricing yet"
**Expected behavior:** 生成除定价外的所有章节，加一条注释："[Pricing to be discussed]"

至少两个示例：happy path（正常输入/输出）和 edge case（异常输入/如何处理）。3-5 个更好。

五种典型失败

Failure 1: Silent Skill（从不触发） 诊断：YAML description 太弱，没有包含用户输入的词汇。 修复：加更多触发短语。如果用户说"clean up this CSV"但 description 只写了"spreadsheet processing"，加上"clean up"、"fix"、"CSV"、"data file"。

Failure 2: The Hijacker（在错误请求时触发） 诊断：description 太宽或缺少负面边界。 修复：加明确的负面边界，收紧触发短语。

Failure 3: The Drifter（正确触发，错误输出） 诊断：指令模糊，存在多种解读方式。 修复：把每条模糊指令替换为可测试的具体指令。"Handle appropriately" 变成"If the input is missing a required field, ask the user for it before proceeding."

Failure 4: The Fragile Skill（有时能用，边缘情况崩溃） 诊断：edge case 处理不完整。 修复：喂给 Skill 最坏的输入：缺失字段、错误格式、矛盾指令。针对每个失败点加具体处理指令。

Failure 5: The Overachiever（添加了没要求的内容） 诊断：指令说了要做什么，但没说不要做什么。 修复：加明确的范围约束："Output ONLY the [specified format]. Do NOT add explanatory text, commentary, or suggestions unless explicitly asked."

五步测试协议

在部署任何 Skill 前，跑这个测试：

  1. Happy path：完整干净的输入，期望输出正确
  2. Minimal input：绝对最少的信息，Skill 是否正确请求缺失信息
  3. Edge case input：矛盾需求、超长/超短输入、不同语言、拼写错误
  4. Negative test：发送一个不应该触发 Skill 的请求，Skill 是否正确沉默
  5. Repeat test：同一条输入跑三次，输出是否一致

修复每个失败点，更新 SKILL.md，重新测试。直到全部通过。

两小时建立你的第一个 Skill

停止阅读，开始构建。选一个你每周至少做一次的任务，用五组件结构写 SKILL.md。用 5 种不同输入测试，修复所有问题。

两小时内，你会有一个已部署的工作 Skill。然后明天建第二个，后天建第三个。一个月后你会有一个处理大多数重复工作的 Skills 库——自动地、一致地、按你定义的质量标准。

这不是一个工具。这是一个每周都在复利的竞争优势。