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、需求文档、需求评审材料时使用。規律：動詞具體 + 產物具體 + 觸發場景列全。