04 · description 怎么写才会被触发
Skill 里最值钱的一格。它是系统判断"这个活要不要用你"的唯一依据——正文写得再好，这一句没写对，它一次都不会被翻开。
先理解它是怎么被用的
开机时，你所有 Skill 的 name + description 会一起被放进模型的视野里，大概长这样：
可用技能：
- meeting-notes: 把零散的会议记录整理成结构化纪要……当用户提供会议记录……时使用
- weekly-report: 把零散工作流水整理成周报……
- prd-from-prototype: 把原型描述转成 PRD……然后你说了一句话。模型拿你这句话，去跟上面每一条比对。比对的对象就是 description，不是 name，也不是正文。
所以写它的时候，脑子里要装的问题不是"我这个 Skill 是干嘛的"，而是：
用户会用什么话来提这件事？那些话里的关键词，我写进去了吗？
一条 description 必须有两半
前半：它做什么。后半：什么时候用它。
少了后半是最常见的失败：
# ❌ 只有前半，模型不知道什么场景该拿它出来
description: 整理会议纪要。
# ❌ 太笼统，跟一百个活都沾边，会在不该触发的时候触发
description: 帮助处理各类文档。
# ✅ 两半都有，关键词齐
description: 把零散的会议记录整理成结构化纪要，输出「关键结论」「带责任人的待办」
「遗留问题」三块。当用户提供会议记录、会议草稿、录音转写稿，或要求整理纪要、
提取会议待办、梳理会议结论时使用。五条写法规则
1. 用第三人称，别用第一 / 第二人称
这一句会被拼进系统提示里，人称混乱会影响判断。
- ❌ "我可以帮你整理会议纪要"
- ❌ "你可以用这个来整理会议纪要"
- ✅ "把零散的会议记录整理成结构化纪要"
2. 把用户可能说的话都塞进去
这是最实用的一招。写之前，先把你和同事真实会说的话列出来：
"帮我把这个会议记录理一下"
"整理成纪要"
"这段录音转写你看看能不能理出待办"
"把刚才会上定的事列一下"
"提取一下会议待办"然后把里面的关键词全塞进 description：会议记录、纪要、录音转写、待办、会上定的事……
别只写你自己习惯的那一种说法。 你说"整理纪要"，同事说"理一下会议内容"——两个说法差得远，都得覆盖。
3. 写清楚"不该用"的边界（可选但很值）
装的 Skill 一多，误触发就开始烦人。加一句排除条款：
description: ……当用户提供会议记录或要求整理纪要时使用。
仅用于会议类材料；整理个人工作流水用 weekly-report，
整理需求文档用 prd-from-prototype。什么时候需要写排除
装的 Skill 少于三个，通常不用。超过五个、而且有内容相近的（纪要 / 周报 / 复盘都是"整理零散信息"），就该给每个都加一句边界。
4. 具体的词优先于抽象的词
模型是拿你的话跟它比对的，具体名词的匹配度远高于抽象概括。
| 抽象（弱） | 具体（强） |
|---|---|
| 处理文档 | 处理 Word、PDF、会议记录、需求文档 |
| 数据分析 | 分析 Excel 表格、透视表、销售报表、预算偏差 |
| 内容优化 | 改写对客邮件、润色方案措辞、精简周报 |
5. 长度：够用就好，但别吝啬
上限通常很宽（一套标准是 1024 个字符），而这一格的收益极高。两三句话是常态，为了覆盖说法写到五六句也完全合理。
真正该省的是正文，不是这里。
名字也有讲究
name 不参与主要匹配，但它影响可读性和你自己的管理。约定俗成的做法：
推荐：动名词式（做什么事），或者名词短语
processing-pdfs/pdf-processingwriting-meeting-notes/meeting-notesgenerating-prd
避免：
- 含糊的：
helper、utils、tools - 太宽的：
documents、data、files - 一套 Skill 里命名风格不统一（一半动名词一半名词）
格式约束通常是：小写字母、数字、连字符，别的都不行。
一个自测方法
写完 description，做这个测试：
把你的 description 和另外三条无关的 description 混在一起，然后拿五句"用户真会说的话"去问：
下面是四个可用技能的说明：
1. 【你写的这条】
2. 【随便找的另一条】
3. 【再一条】
4. 【再一条】
对于下面每句用户请求，判断应该用哪个技能（可以是"都不用"）：
a) "帮我把这个会议记录理一下"
b) "刚才会上定了啥，列一下"
c) "这份录音转写太乱了，能整理吗"
d) "帮我写个周报" ← 期望：不选你这个
e) "把这份 PDF 转成表格" ← 期望：不选你这个
只输出编号，不要解释。前三句没选中你，就是覆盖不够——把那句话里的词加进去。后两句选中了你，就是边界太宽——加排除条款。
这个测试三分钟，能省掉你后面几周的"我的 Skill 怎么从来不触发"。
三个真实的对照
弱：
description: PDF 工具。强：
description: 从 PDF 中提取文字和表格、填写表单、合并文档。
当用户处理 PDF 文件，或提到 PDF、表单、文档内容提取时使用。弱：
description: 帮你写更好的提交信息。强：
description: 分析 git 变更内容，生成规范的提交信息。
当用户请求撰写 commit message、或要求检查已暂存的改动时使用。弱：
description: 需求文档相关。强：
description: 把功能原型的文字描述转成可交研发的 PRD，含字段、交互逻辑、
计算口径、边界异常和「待产品确认」清单。当用户提供原型描述、界面草图说明、
功能构想，或要求写 PRD、需求文档、需求评审材料时使用。规律：动词具体 + 产物具体 + 触发场景列全。