如果你每週都在 Claude 裡重貼同一段提示詞，例如「把會議逐字稿整理成客戶可讀的紀錄」「把英文技術文改成繁中教學」「替每篇文章檢查標題、內連與語氣」，真正消耗時間的是流程漂移：這次少了授權檢查，下次忘了輸出格式，第三次又把不該公開的欄位寫進成品。
Claude Skills 的價值在這裡。它把一套可重複的工作方法收成資料夾與 SKILL.md，讓 Claude 在相關任務出現時載入那套流程，降低每次憑記憶貼長 prompt 的遺漏風險。讀完這篇，你應該能判斷哪種工作值得做成 Skill、哪種應該留在 CLAUDE.md、Claude Projects 或 MCP，並用一個小範圍範本完成第一次冷啟動測試。
先判斷：你的流程需要 Skill 嗎？
最適合做成 Skill 的任務，通常有三個特徵。第一，它會重複出現，而且每次步驟大致相同；第二，結果有明確格式或品質標準；第三，流程太長，不適合每次塞進對話。內容編輯的改稿規範、客戶會議紀錄、月報摘要、資料清理、文件轉檔檢查，都屬於這一類。
不適合的情境也要先說清楚。一次性的靈感發想、今天才有的臨時背景、需要連外部系統的資料讀寫，通常先留在其他地方。臨時背景放在對話裡就好；專案固定規矩放在 CLAUDE.md 或 Projects；需要讀 Notion、資料庫、Slack、GitHub 或內部 API 時，先看 MCP 或更完整的 AI Agent 自建流程。如果你還在建立本機 coding agent 習慣，先把 Claude Code 基礎流程 補好，再把重複 SOP 封裝成 Skill。
一個實用的判斷法是問：「如果我請同事照這份流程做三次，第三次仍應該長得差不多嗎？」如果答案是肯定，而且你能寫出通過標準，就值得考慮 Skill。
Claude Skills 是什麼：一個會被載入的工作手冊
Anthropic 在〈Equipping agents for the real world with Agent Skills〉中把 Skills 描述成一組資料夾：裡面可以有 instructions、scripts 和 resources。最小單位是一個含有 SKILL.md 的資料夾；SKILL.md 透過 frontmatter 告訴 Claude 這個 Skill 何時該用，正文則放實際執行方法。
這和把長 prompt 存起來不同。Claude Code 文件說，Skill 的正文只有在相關時才載入；如果流程需要更多資料，可以把範例、術語表、檢查清單或腳本放在同一個資料夾裡，讓 SKILL.md 指向它們。Anthropic 工程文章稱這是 progressive disclosure：先讓模型知道有哪些 Skill，再在需要時讀完整步驟，最後才讀更細的 references 或 scripts。
因此，Skill 的核心是工作方法分層。description 要足夠清楚，讓 Claude 判斷何時啟用；正文要足夠短，讓 Claude 讀完就能做；references 則保留長規範、範例與邊界。
Skills、MCP、CLAUDE.md、Projects 怎麼分工
很多人第一次接觸 Skills，會把它和 MCP、Subagents、slash commands、CLAUDE.md 混在一起。先用這張表把選擇縮小，再決定要不要動手寫。
| 你要解的任務 | 先用哪個 | 為什麼 |
|---|---|---|
| 每次都照同一套 SOP 產出文章、紀錄、報告或檢查清單 | Claude Skill | 流程可重複，且需要在相關任務時自動載入 |
| 讓 Claude 讀寫外部系統，例如資料庫、Notion、Slack、檔案系統 | MCP server | 這是工具存取與權限問題，做事方法只是一部分 |
| 專案裡的命名規則、測試命令、風格紅線 | CLAUDE.md 或 Project instructions | 這些規矩應該長期存在於專案脈絡 |
想輸入 /deploy、/review 立刻啟動固定流程 | Skill 或既有 command | Claude Code 文件說 custom commands 已併入 Skills；舊 .claude/commands/ 仍可運作 |
| 想讓另一個 agent 分工處理研究、測試或審稿 | Subagent / agent workflow | 這是任務拆分與隔離問題，Skill 可以提供其中一段 SOP |
實務上常見組合是：CLAUDE.md 放專案共同規矩，Skill 放一套可重複流程，MCP 提供外部資料或工具，Subagent 負責把某一段工作隔離出去。不要把所有事都塞進 Skill；那會讓觸發變模糊，也讓日後維護變難。
一個最小 Skill 長什麼樣
在 Claude Code 裡，一個專案 Skill 可以放在 .claude/skills/<skill-name>/SKILL.md。Claude Code 文件也提到，專案會從起始目錄與父層的 .claude/skills/ 探索 Skills；大型 monorepo 還可以在子資料夾放更局部的 Skills。第一次練習時，不必先做全公司共用，從單一專案開始比較安全。
最小骨架可以這樣寫：
---
name: client-meeting-summary
description: Turn a client meeting transcript into a Traditional Chinese follow-up note with decisions, action items, open questions, and risks. Use when the user provides a meeting transcript and asks to 整理會議紀錄, 摘要會議, or 寫 follow-up.
---
Goal: create a client-ready meeting note that is shorter than the transcript and safe to send.
Input: transcript, meeting topic, client name if provided, and any promised deadline.
Process: identify decisions first, then action items, then unresolved questions, then risks. Do not invent owners or dates. Mark missing owner or due date as TBD.
Output: concise Traditional Chinese note with sections for decisions, action items, open questions, and next meeting preparation.這份範本刻意很短，因為第一個 Skill 的目標是測出 Claude 能否在正確情境啟用它，而非一次收進所有規範。若未來需要品牌語氣、範例或客戶分類，再把長內容移到 references/voice-guide.md、references/example-output.md 之類的檔案。
第一次建立 Skill：用五步驟收斂範圍
先選一個低風險、每週都會重複的任務。不要從「幫我經營整個內容部門」開始，改成「把會議逐字稿整理成客戶 follow-up」「把英文產品更新改成繁中重點摘要」「把文章草稿做上線前檢查」。範圍越小，越容易驗收。
第二步，把使用者會怎麼開口寫進 description。Claude 會用這段判斷是否該啟用 Skill，所以描述不能只寫「幫我整理內容」。比較好的寫法會包含任務、輸入、輸出和觸發詞，例如「當使用者貼上會議逐字稿並要求整理會議紀錄時使用」。
第三步，把執行流程寫成少數清楚段落。先講目標，再講輸入，再講流程，再講輸出格式與不能做的事。若流程超過一頁，通常代表該拆 references，繼續把正文加長會讓觸發與維護都變差。
第四步，準備一個成功案例和一個失敗案例。成功案例讓 Claude 知道什麼叫合格輸出；失敗案例可以是過度腦補、缺少 owner、把內部備註寄給客戶、或把英文術語硬翻成不自然中文。這些案例放在 references 裡，比塞在正文更好維護。
第五步，開一個全新的 Claude session 做冷啟動測試。不要沿用剛寫 Skill 的對話，因為那裡已有上下文。用真實使用者會說的話測一次，例如「幫我整理這段客戶會議逐字稿」，看 Claude 是否真的啟用 Skill、是否照流程產出、是否在資料不足時標示 TBD。
官方 Skills repo 怎麼看：先找範例，不要全裝
Anthropic 官方 GitHub repo anthropics/skills 目前把 Skills 分成多種範例。README 說，這些 Skills 展示了 Claude Skills 系統的可能性，也包含 docx、pdf、pptx、xlsx 等文件能力的參考實作；同時也提醒，這些範例用於示範與教育，實際行為可能和 Claude 產品內建能力不同，正式使用前仍要在自己的環境測試。
對一般工作流最有參考價值的是找出接近你任務的結構，不要一次裝滿 17 個。處理 Word、PDF、簡報、試算表的人，可以研究 docx、pdf、pptx、xlsx；想讓 Claude 幫你寫 Skill，可以看 skill-creator；想做工具串接，可以看 mcp-builder；要做前端或測試流程，可以看 frontend-design、webapp-testing。它們示範的是資料夾如何拆分、instructions 怎麼寫、何時需要 scripts；多數團隊只需要挑少數範例學架構。
如果只是內容、行銷、營運或顧問工作，第一個自訂 Skill 通常比安裝一堆範例更有用。先把自己的 SOP 寫好，跑過三次真實任務，再回頭參考官方 repo 的架構；若你想把 Skills 放回整個 Claude 生態裡比較，可接著看 Claude 全產品地圖 或 Claude Memory 的分工。
三個繁中工作流範本可以怎麼改
下面三個範本提供可改寫的骨架。複製前先換掉 name、description、輸入來源、輸出格式與不能做的事，避免不同專案共用同一套模糊指令。
內容編輯 Skill 適合每週都有文章草稿、電子報或社群長文要整理的人。它可以要求 Claude 先確認讀者問題，再檢查事實、語氣、標題、內連與最後行動。若你在做技術文章，references 可以放術語表與成功文章；若在做品牌內容，references 可以放語氣範例與禁用詞。
---
name: zh-tw-editorial-polish
description: Improve a Traditional Chinese article draft for reader clarity, factual caution, headline fit, and next action. Use when the user asks to 潤稿, 改稿, 編輯, or 上線前檢查 a zh-TW article draft.
---
Goal: make the draft useful to a cold reader without changing unsupported facts.
Process: check reader problem, first screen, factual caveats, examples, links, tone, and final action.
Output: revised draft plus a short change note.客戶會議 Skill 適合顧問、接案者、業務與 PM。重點放在承諾邊界：未定事項不要寫成已承諾，owner、due date 或待補資料也不能漏。若會議常涉及機密，可以在 Skill 裡要求先遮罩個資，或只處理客戶允許放進 Claude 的內容。
---
name: client-follow-up-note
description: Convert a client meeting transcript into a follow-up note with decisions, owners, due dates, risks, and questions. Use when the user pastes transcript or rough notes and asks for 會議紀錄 or follow-up.
---
Goal: produce a note that can be checked before sending to the client.
Rules: do not invent decisions, owners, deadlines, prices, or legal commitments.
Output: decisions, action items, open questions, risks, and suggested next message.資料整理 Skill 適合營運、研究、內容索引或客戶名單清理。它不需要一開始就接 MCP；如果資料是使用者貼上或匯出的 CSV 摘要，Skill 先把分類規則、錯誤處理與輸出欄位固定下來。等流程穩定，再考慮用 MCP 或腳本自動化。
---
name: csv-cleanup-plan
description: Turn messy CSV columns or pasted tabular data into a cleanup plan with field mapping, validation rules, and manual review points. Use when the user asks to 整理資料, 清 CSV, 欄位對照, or 資料清理.
---
Goal: reduce manual cleanup while preserving uncertain rows for review.
Process: map fields, flag missing values, detect duplicates, propose validation rules, and mark rows that need human review.
Output: cleanup plan, field mapping, and risk notes.常見失敗：觸發不到、觸發太多、結果漂移
觸發不到通常是 description 太抽象。Claude Code 文件的 troubleshooting 也建議檢查 description 是否包含使用者自然會說的關鍵詞、Skill 是否真的出現在可用清單、以及請求語句是否和描述相符。修法很直接：刪掉空泛形容詞，把任務、輸入、輸出與觸發詞講具體。
觸發太多則是邊界太寬。例如「Use when writing」會搶到太多任務；「Use when rewriting a Traditional Chinese B2B product article before publication」就清楚得多。若只想手動呼叫，可以參考 Claude Code docs 的 frontmatter 設定，讓 Skill 不由模型自動觸發。
結果漂移通常代表正文太像理念，缺少驗收標準。把「寫得更好」改成可檢查條件：有沒有先點出讀者問題、有沒有標示未知資料、有沒有列 action items、有沒有保留人工覆核、有沒有輸出成指定格式。真正穩定的 Skill，會讓你在三次不同輸入中得到同一種結構，避免只產生三篇語氣相近的自由發揮。
什麼時候先別做 Skills
如果你的流程還沒跑過三次，先不要急著封裝。先在普通對話裡完成幾次，觀察哪幾步每次都會重複，哪幾步其實因情境不同而變動。過早封裝會把錯誤流程固定下來，之後更難修。
如果核心價值是資料存取，也先別用 Skill 硬扛。舉例來說，Claude 需要查 Notion 知識庫、讀 GitHub issues、拿 CRM 客戶狀態或寫入表單時，問題在權限、資料邊界、API 與審核。這時應該設計 MCP server、工具權限與人工確認點，Skill 只負責「拿到資料後怎麼處理」。
如果涉及法律、醫療、財務、資安或客戶機密，Skill 可以放檢查流程，但不能把責任交給 Claude。應該在 Skill 裡明寫「不得給最終專業意見」「不得自動送出」「不足資料要標示」與「需要人工覆核」，並把敏感資料處理規則放在更高層的專案或公司政策裡。
FAQ
Claude Skills 跟長 prompt 最大差異是什麼？
長 prompt 依賴使用者每次記得貼、貼對、貼完整；Skill 讓流程變成可被 Claude 探索與載入的檔案。它更適合重複任務，尤其是需要固定輸出格式、references、範例或腳本的工作。
Skills 跟 MCP 差在哪？
Skills 告訴 Claude「這件事該怎麼做」；MCP 讓 Claude 取得或操作外部工具與資料。若只是會議紀錄、改稿、檢查清單，用 Skill 就夠；若需要讀寫 Notion、資料庫、Slack、GitHub 或內部系統，通常要 MCP 或其他工具層。
我需要會寫程式才能用 Claude Skills 嗎？
不一定。最小 Skill 是 markdown 加 YAML frontmatter，內容可以完全是文字 SOP。只有當你需要 scripts、自動測試、資料處理或外部工具整合時，才需要程式能力。
官方 repo 裡的 Skills 可以直接用嗎？
可以參考，也可以依 README 的方式透過 Claude Code plugin marketplace 安裝部分技能組；但官方 README 明確把 repo 定位為示範與教育用途，正式放進工作流前要在自己的資料、權限與輸出標準下測試。
第一次做 Skill，最重要的驗收是什麼？
開新 session 做冷啟動測試。用自然語言提出真實任務，確認 Claude 會在正確情境啟用 Skill、會照輸出格式做、資料不足時不腦補，並且結果比你每次貼 prompt 更一致。