怎麼判斷一件事值不值得做成 Skill，是不是任何重複的任務都該打包？
判準不是「這件事重複了幾次」，而是「每次交代這件事時，講的內容是不是高度相似」。如果一件事雖然常做，但每次的判斷邏輯都不太一樣（例如每次審查文案的重點會依產品、受眾大幅調整），打包成固定的 Skill 反而可能限制了原本需要的彈性；相反的，如果每次交代的規則幾乎一模一樣，只是懶得每次重打一遍，這種情況才是 Skill 真正省時間的地方。
一個簡單的自我測試：試著回想最近兩三次做這件事時，你跟 Claude 說的話有多少比例是重複的。如果重複比例很高，代表這些內容已經是穩定的規則,值得寫下來；如果每次都不太一樣，代表這件事本身需要的是臨場判斷，不適合寫死成一份固定文件。
Skill.md 裡的 description 欄位要寫多長，寫太簡短會不會讓 Claude 誤判什麼時候該用？
description 欄位官方建議上限是 1,024 個字元，但重點不在字數，而在於是否同時涵蓋「這個 Skill 做什麼」跟「什麼情境該用它」這兩件事。只寫「整理會議記錄」這種單純描述功能的寫法，容易讓 Claude 在情境不夠明確時漏掉觸發；比較穩妥的寫法是同時列出具體的觸發情境，例如「當使用者提到會議記錄、行動項目、或要求整理會議重點時使用」，把使用者可能講出來的關鍵詞也一併寫進去。
另外要注意用第三人稱撰寫（「處理 XX」而不是「我可以幫你處理 XX」），因為 description 會被直接放進系統提示裡，人稱不一致容易造成 Claude 判斷時的混淆。如果實際使用後發現 Skill 該觸發卻沒有觸發，通常第一個該檢查的地方就是 description 有沒有把觸發情境寫得夠具體。
Skill 裡的規則要用條列式還是完整段落？寫法上有沒有比較有效的格式？
這取決於規則本身的性質，可以參考「自由度」這個概念來決定：如果規則之間彼此獨立、判斷方式接近勾選清單（例如「檢查有沒有負責人」「檢查有沒有期限」），條列式最清楚，Claude 可以逐項核對；如果規則需要一定的判斷邏輯、有先後順序或條件分支（例如「先判斷這是不是行動項目，是的話再決定該放進哪一類」），用帶編號的步驟或流程說明會比條列式更能傳達邏輯關係。
另一個實用技巧是提供具體的輸入輸出範例，而不是只用文字描述規則。例如與其寫「負責人欄位不要留空」，不如直接示範一個具體案例：「輸入：『討論行銷預算，大家都覺得需要重新規劃』→ 輸出：負責人欄位標記『待認領』，因為沒有人被指派」。範例往往比抽象描述更能讓 Claude 掌握你要的精確標準,尤其是判斷邊界比較模糊的規則。
如果我照著這個流程寫了一個 Skill，用了幾次之後發現有些情況它判斷得不太準，該怎麼修正比較有效率？
比較有效率的修正方式，不是憑印象猜測哪裡有問題，而是拿實際發生落差的那次案例，回頭具體指出「哪個環節判斷錯了」。例如你發現 Claude 把一則單純的資訊分享誤判成了行動項目，先確認原本 Skill.md 裡「純粹資訊分享不列入清單」這條規則是不是寫得不夠清楚，或者這次的內容剛好落在規則沒有明確涵蓋到的灰色地帶——如果是後者，代表你需要新增一個更具體的判斷準則或範例，而不是重寫整條規則。
這個修正過程可以借助 Claude 本身：把目前的 SKILL.md 內容跟這次判斷錯誤的具體案例一起貼給 Claude，直接請它幫忙分析「這次的判斷錯誤，可能是 SKILL.md 裡哪個地方不夠明確造成的」，通常能得到具體可操作的修改建議，比自己從頭重新設計規則更快找到問題所在。
判斷值不值得做一個 Skill，有一個很簡單的檢查方法：回想這一週，有沒有哪件事你已經跟 Claude 交代過至少兩三次、每次講的內容大同小異。如果有，這就是一個值得打包成 Skill 的候選——與其每次重新描述一遍，不如把這份說明寫成一份文件，之後只要任務符合，Claude 就會自動套用。
以下用一個常見情境示範完整流程：假設你每週都要幫团隊把零散的會議記錄整理成統一格式的行動項目清單，每次都要跟 Claude 重新說明一次「用什麼欄位、怎麼分類」。
在動手寫 Skill 之前，先用平常的方式跟 Claude 完成一次這個任務，把過程中你實際講出來的規則都記下來。以整理會議記錄為例，你可能在對話裡講了類似這些話：「每個行動項目要包含負責人、期限、目前狀態這三個欄位」「沒有明確負責人的項目要特別標記『待認領』」「純粹的資訊分享、沒有後續動作的內容不用列進行動項目清單」。這些你在對話裡臨時講出來的規則，就是這份 Skill 該包含的核心內容。
一個 Skill 最基本的形式，是一份包含 YAML frontmatter（記錄名稱與描述）加上內文說明的 Markdown 檔案。以剛才的例子為例，內容大致長這樣：
SKILL.md 範例：
「---
name: organizing-meeting-action-items
description: 把會議記錄整理成統一格式的行動項目清單。當使用者提到會議記錄、行動項目、或要求整理會議重點時使用。
---
## 整理規則
每個行動項目包含三個欄位：負責人、期限、目前狀態。
沒有明確負責人的項目，在負責人欄位標記「待認領」，不要留空或用「未指定」。
純粹的資訊分享、沒有要求任何人採取行動的內容，不列入行動項目清單，可以另外整理成「會議紀要」區塊。
輸出格式使用表格，欄位順序固定為：行動項目、負責人、期限、狀態。」
這份 Skill 描述的重點在 description 這一欄——它決定了 Claude 什麼時候會主動想到要用這個 Skill，所以要具體寫出「這個 Skill 做什麼」以及「什麼情境該用它」，而不是只寫一句模糊的「整理會議記錄」。
寫完之後，找一份實際的會議記錄丟給 Claude 測試，看它是不是真的照這些規則整理。如果發現某個規則被漏掉了（例如負責人欄位還是留空、沒有標記「待認領」），代表這條規則在 SKILL.md 裡寫得不夠明確或不夠醒目，回頭調整用詞、或把重要規則往前移，再測一次。這個「測試—發現落差—修正」的循環，通常要跑個兩三輪才會穩定。
Skill 真正省下的時間，不是打字的時間，而是「每次都要重新想一遍該怎麼描述這個規則」的心力。一旦寫成 Skill，這份判斷邏輯就變成一個可以重複調用、也可以分享給團隊其他人使用的資產。開始的門檻很低——不需要一次寫出完美版本，先用一次正常對話把規則講清楚、抄下來、存成一份 Markdown 檔案，這就是最基本可用的 Skill 雛形，之後有需要再慢慢補齊細節。