嗨，我是 Lena。第一次設定 SKILL.md 檔案時，我總覺得哪裡有點不對。不是做錯了，只是和我原本以為的不太一樣。我把說明讀完，把檔案放進正確的目錄裡，Claude 也順利讀到了它。但接著我開始想：我到底給了它什麼？知識？一種習慣？還是某種可以繼續傳遞下去的東西？
這個問題我想了一陣子。以下是我目前的一些觀察。
什麼是 Claude Skills？
Claude skills 是模組化、可重複使用的能力包。它們通常以資料夾形式組織，為 Claude Agent 提供特定領域的說明、上下文，以及可選腳本。每個 skill 的核心都是一個 SKILL.md 檔案。
如果你正在用 Claude Code 或 Claude API 開發，這大概已經是你熟悉的模式，或者很快就會遇到。
SKILL.md 如何運作
每個 skill 都放在自己的目錄裡。裡面的 SKILL.md 檔案分成兩個部分：最上方是 YAML frontmatter，下面是 markdown 正文。
frontmatter 很精簡。它告訴 Claude 這個 skill 叫什麼、該在什麼時候使用，也就是 Claude 啟動時會先讀到的一小段說明。真正的操作說明寫在 markdown 正文裡：該做什麼、輸出如何格式化、有哪些邊界情況要留意、需要載入哪些輔助檔案。
啟動時，Agent 會先把所有已安裝 skills 的名稱和描述預先載入 system prompt。這層中繼資料是漸進式揭露的第一層：它只給 Claude 足夠的資訊，好讓它知道什麼情況下該使用哪個 skill，而不用一開始就把所有內容塞進上下文。
這點當時讓我覺得設計得很用心。Claude 一開始不會把整份 skill 檔案都讀進來，只會先讀 frontmatter。只有當某個 skill 變得相關時，它才會載入更細的內容。這表示你可以安裝很多 skills，而不用持續吃掉 context window 的空間。
你可以把哪些行為編碼進去
實際上，範圍很廣。Skills 可以承載：
- 分步操作說明 — 如何處理某一類檔案、某種 review 模式，或特定輸出格式
- 領域慣例 — 命名標準、專案特定規則、偏好的函式庫
- 輔助檔案 — 模板、範例輸出、Claude 可以執行的 Python 腳本
- 條件式子文件 — 只有在 Claude 判定它們相關時才會載入的更深入參考資料
Skills 的作用，是讓 Claude 為解決某個問題做好準備，而不是直接代替它把問題解完。這和傳統工具很不一樣，傳統工具是執行後直接回傳結果。
這一點對我來說很重要。skill 本身不會執行。它提供的是說明，真正進行推理的仍然是 Claude。
如何設定並使用 Claude Skills
檔案位置與格式
如果是個人跨所有專案共用的 skills，就放在 ~/.claude/skills/。如果是透過 Git 分享的專案層 skills，路徑則是 .claude/skills/。每個 skill 都需要自己的子目錄，目錄裡再放一個 SKILL.md。
格式本身很直接。建立 skill 很簡單，本質上就是一個資料夾，裡面放一個包含 YAML frontmatter 與操作說明的 SKILL.md 檔案。Anthropic's official skills repository on GitHub 裡有可以直接起步的模板 skill，也包含支援 Claude 內建 PDF、Word 與 PowerPoint 處理能力的 source-available document creation skills。
Claude 如何讀取並套用 Skill 說明
一旦 skill 安裝完成，Claude 會監看進來的任務，並將它們和 skill description 進行比對。匹配到之後，它就會把 SKILL.md 的內容載入上下文，接著依照裡面的說明行事。
你也可以用斜線指令手動呼叫，例如 /<skill-name>，或者讓 Claude 依任務上下文自動決定是否使用。兩種模式在底層的運作方式其實一樣。
我在這裡注意到一件很有意思的事：當 Claude 使用某個 skill 時，它不是單純「已經知道」這些說明，而是每次都會重新讀取它，就像在查一份文件。這點的影響，我後面還會再回來談。
Claude Skills 擅長的地方
領域知識與專案慣例
這大概是 skills 最能發揮價值的地方。如果你的團隊有一套特定的程式設計標準、偏好的除錯流程，或者固定的輸出要求，把這些寫進 skill 檔案裡，Claude 就能穩定套用，而不用你每次開新會話都再重講一次。
我在幾個不同專案裡試過幾次。和單純依賴 CLAUDE.md 說明，或是在 prompts 裡反覆重述相比，一致性明顯更好。Claude 會讀這份 skill、照著執行，輸出也更可預期。
一致的輸出格式
對結構化輸出來說，像是技術文件、程式碼審查或 API 文件，skills 很適合拿來當格式契約。你把預期結構寫清楚，Claude 載入之後，輸出就更容易穩定貼合。
Claude Code skills 遵循 Agent Skills 開放標準，這套格式可以跨多個 AI 工具使用。Claude Code 也在這個標準上擴充了額外能力，例如 invocation control、subagent execution，以及 dynamic context injection。
這種跨平台相容性很值得注意。如果你同時在多個 Agent 工具上建構工作流程，同一種 SKILL.md 格式是可以重用的。
Claude Skills 的上限在哪裡
這也是我開始意識到，它和我最初想像的東西其實不太一樣的地方。
靜態檔案 vs. 動態學習
SKILL.md 檔案是由人寫出來、存到磁碟上的。它不會自己更新。如果 Claude 靠某個 skill 很順利地完成任務，那次成功也不會反向寫回 skill 檔案。下一次會話，仍然是從同一份靜態文件重新開始。
你當然可以要求 Claude 把成功做法與常見錯誤整理回 skill 裡，但 這一步是手動的。 要由你來發起。Claude 不會自己去做。
我不確定這是不是缺陷。對我來說，它更像是一條明確的設計邊界。
沒有執行回饋閉環
當 Claude 套用某個 skill 並產出結果時，沒有任何訊號會回流到 skill 本身。沒有紀錄會告訴你哪條說明有效、哪條被忽略、哪條造成了問題。skill 本身沒有「被使用過」的記憶。
Agent 在正式環境裡跑得越久，這點就越重要。那些模式會累積在你的腦中，而不會累積在檔案裡。
Skills 不會在 Agent 或團隊之間自然傳播
Custom Skills 是每個使用者各自持有的；它們不會在整個組織中自動共享，也無法由管理員集中管理。
所以，如果團隊裡某個人基於幾個月的實際使用，把某個 skill 打磨得更好了，這個改進版本並不會自動流向隊友。它只會留在本地。總得有人去複製、提交、分享，然後大家再各自更新。
這不是說它壞了。但這代表 skill 的改進傳播得很慢，而使用這些 skills 的 Agent 網路，也不會隨著時間自然收斂到更好的行為上。
從靜態 Skills 走向可繼承的能力
超出 SKILL.md 的「可重用、可驗證能力」意味著什麼
我最近一直在想，如果某次 skill 的成功執行，例如某個 Agent 真的順利跑完一段複雜的除錯序列，能不能直接變成其他 Agent 可以繼承的東西。不是被複製的檔案，而是一套帶有稽核軌跡的已驗證解法。
以現在的形態來看，skills 更像 onboarding 文件。它們基於某個人當下最好的理解寫成，再靠人工分發。這個模型是有效的，而且在穩定、成熟、邊界清楚的領域裡，效果其實很好。
但對那些把 Agent 跑在正式環境裡的團隊來說，Agent 會失敗、恢復、調整。於是「skill 裡寫了什麼」和「上週真正有效的是什麼」之間的距離，就會悄悄拉開。
當你需要一種會演化的東西
我越觀察真實使用中的 Agent 系統，就越覺得 難的不是把知識編碼一次，而是讓它一直保持最新。 Skills 解決的是編碼問題；持續更新的問題仍然是開放的。
現在已經開始出現一些基礎設施層面的做法，把經過驗證的 Agent 行為視為可共享資產。那不再是靜態檔案，而是帶有來源脈絡的已驗證解法。這種架構和 SKILL.md 很不一樣，也會把信任，以及 Agent 語境下「重用」究竟意味著什麼，重新帶進討論。
那條界線到底該畫在哪裡，我現在也還沒有完全想清楚。
侷限與權衡
如果只說我目前看到的結論：
Claude Skills 的確很有用。 它們減少重複、提升一致性，也讓領域知識可以跨會話攜帶。對個別開發者和小型團隊來說，這比臨時、零散地寫 prompt 要好得多。
真正的上限，會出現在你想要一種能自我演化、能自動在 Agent 之間傳播，或能從真實執行裡持續累積證據的能力時。 這不是 SKILL.md 被設計來解決的事情。
這個權衡其實很簡單：可預測性 vs. 適應性。Skills 提供的是可預測性。它們不會，也不是設計來提供，一個能從自己歷史中學習的 Agent。
FAQ
- Claude Code 裡的
SKILL.md檔案是什麼？
SKILL.md 檔案是 Claude skill 的核心元件。它是一份帶有 YAML frontmatter 的 Markdown 文件，為 Claude 提供特定領域的說明、上下文與中繼資料。它告訴 Claude 什麼時候該套用這個 skill，以及套用之後要做什麼。借助 Claude 的 VM 環境，skills 能提供一些單靠 prompt 很難做到的能力。
- Claude Skills 是怎麼運作的？
Claude 會在啟動時讀取 skill 的中繼資料，只有在偵測到相關任務時，或你用斜線指令手動呼叫時，才載入完整說明。這種漸進式載入能把上下文占用維持在較低水位。skill 目錄裡的輔助檔案也會依需求載入，而不是一次全部讀進來。
- 我要怎麼為 Claude Code 建立自訂 skill？
在專案的 .claude/skills/ 目錄下建立一個子目錄（如果是個人全域使用，則放在 ~/.claude/skills/）。接著新增一個 SKILL.md 檔案，最上方寫入包含 name 與 description 的 YAML frontmatter，下面再接你的 markdown 說明。Claude 會在相關情境下自動發現並套用這個 skill。你可以去看 Anthropic skills GitHub 倉庫裡的模板與範例，也可以閱讀完整的 Agent Skills 文件取得設定指引。如果想看更技術向的拆解，Anthropic's engineering blog post on Agent Skills 很值得細讀。如果你使用 SDK，Agent Skills in the SDK 也說明了在那個情境下，skill discovery 和 tool access 是如何運作的。
- Claude Skills 和 MCP tools 是一樣的東西嗎？
不完全是，雖然我自己有時也會把兩者混在一起。MCP (Model Context Protocol) tools 是 Claude 在執行期間呼叫的外部能力，例如檔案系統、資料庫、API 與各種服務。它們會執行，並回傳結果。Claude skills 則是指導性的：它們告訴 Claude 應該如何 行動、如何接近某個任務，而不是提供一個新的工具讓它去呼叫。某個 skill 也許會引導 Claude 完成一套 code review 流程；某個 MCP tool 則可能真的去抓回被審查的檔案。兩者可以搭配使用，但它們解的是不同的問題。一個給 Claude 存取能力，另一個給 Claude 行為指引。
- Claude Skills 可以在專案之間共享嗎？
可以共享一部分。放在 ~/.claude/skills/ 的 skills 屬於個人技能，會套用到這台機器上的所有專案。放在專案目錄 .claude/skills/ 裡的 skills 則是專案層級，可以提交到 Git，這意味著複製儲存庫的隊友也會自動得到同樣的 skills。不會發生的是更進一步的自動同步或自動傳播。如果你在某個專案裡把某個 skill 改進了，這個改進不會自己流向其他地方。共享仍然是手動的：複製、提交、分發。對個人與在同一個儲存庫協作的小團隊來說，這通常夠用；但對在多個環境中運行多套 Agent 工作流程的大型組織來說，摩擦就會慢慢浮現。
我會繼續觀察這個領域如何演化。靜態說明和會自我演化的 Agent 能力之間的距離，感覺正在慢慢縮短，只是過程並不總是顯眼。我現在也還沒完全想明白這代表什麼。下次見。
