我為什麼把這 7 個東西都寫成 Skill——一個 PM 的客製化判斷

Claude Code 的客製化機制有 5 層——CLAUDE.md、Skill、Subagent、Hook、MCP。最務實的入手點是 Skill：比 Hook 簡單、比 Subagent 直接、比 MCP 輕量。我寫過 7 個 Skill，從這個過程沉澱出三條判斷準則——什麼東西該抽成 Skill、什麼東西該留在 CLAUDE.md、什麼東西該抽到 shared-rules。

上一篇講完 CLAUDE.md，最後留了一個鉤子：「永遠該載入的寫 CLAUDE.md、按需才該載入的寫 Skill」。這篇把這條 trade-off 攤開——我為什麼有 7 個東西不寫進 CLAUDE.md、改寫成 Skill。

Claude Code 的客製化選項聽起來多——CLAUDE.md、Skill、Subagent、Hook、MCP——但實際用過會發現大多數人最先碰到、也最划算的是 Skill。原因簡單：比 Hook 容易設定、比 Subagent 跟主 session 更黏、比 MCP 不需要外部依賴。我 7 個 Skill 累積下來摸出該不該寫成 Skill 的判斷準則，這篇攤開。

Skill 跟 CLAUDE.md 的真正差別：always-on vs on-demand

課程把 Skill 描述成「有名稱、有描述常駐、Claude 判斷要用的時候才載入完整內容」的模組。這個機制的設計重點不在「能寫多複雜的步驟」，在它跟 CLAUDE.md 的根本差別——always-on vs on-demand。

CLAUDE.md 是 always-on：每次 session 啟動就 append 到 prompt 前，不管你這次要做什麼，它都先吃進 context。Skill 不一樣：name 跟 description 常駐（讓 Claude 知道有這個工具），但 full content 只在 Claude 判斷要用時才完整展開。

從 context 預算的角度看，這是「稅率」的差別。寫進 CLAUDE.md 等於每次 session 繳一次 context 稅；寫成 Skill 只在被觸發的 session 繳。如果某條規範一個月只在某一類任務出現一次，把它放 CLAUDE.md 就是讓另外幾百次 session 都默默繳這條稅、卻完全沒用到。

另一個角度：CLAUDE.md 適合「無論做什麼都該知道的東西」——專案 stack、commit 規範、不可違反的安全規則。Skill 適合「只有特定情境才該知道的東西」——某類任務的 SOP、某種文件的格式規範、某種錯誤的排查流程。前者是憲法，後者是手冊。

我寫了哪 7 個 Skill：分布在 3 個專案

我目前有 7 個 Skill，分布在 3 個主力專案：

knowledge-vault：vault-agent

vault-agent 是個人知識庫專用的 Skill，使用者下指令 ingest <標籤> 或 query <關鍵字> 時觸發、做 vault 的素材沉澱跟查詢。為什麼是 Skill 不是 CLAUDE.md：vault 操作流程很複雜（提案制、多檔分工、edge case），常駐會稀釋整份 CLAUDE.md，而我大多數 session 不在 ingest——按需載入更合理。

outsidewriter：3 個寫作相關 Skill

• writing-style：每次轉寫文章時載入，確保風格一致。
• fact-check：轉寫完成後強制執行的查核流程。
• output-formats：四種輸出格式（WP / FB / Threads / LinkedIn）的格式規範，產出階段才載入。

這三個的共同點：都是「寫文章」這個任務型態才會用到的東西。如果寫進 CLAUDE.md，每次跟 outsidewriter 對話（包含 debug、規劃、討論）都會繳 context 稅、但 90% 對話用不到這些規範。

gwarket-site：3 個技術相關 Skill

• code-conventions：修改或建立程式碼時參考的技術慣例。
• deployment-troubleshooting：部署後前端顯示異常、API 不正確、路由分流失敗等問題的排查指南。
• ui-design：做介面設計決策、建立新元件、討論視覺風格時用。

這三個的判斷邏輯也一樣——某種特定任務型態才需要的細節，常駐進 CLAUDE.md 是浪費。7 個 Skill 加起來覆蓋三個主力專案的客製化需求。下一段把這個過程沉澱出的判斷準則攤開。

三條判斷準則：什麼東西該抽成 Skill

準則 1：被多個專案需要的東西，不寫進單一專案的 CLAUDE.md

第一個訊號是重複。同一份規範如果同時被 insidewriter 跟 outsidewriter 需要、或被 gwarket-site 跟 publish-tools 需要，重複放兩處遲早會分裂。

我自己踩過：寫作風格規範一開始放在 outsidewriter 的 SKILL，後來 insidewriter 也要用。第一個直覺是複製一份過去——但複製等於下次改規範要改兩次、漏改一次就分裂。最後抽到 shared-rules/ 這個獨立 layer，writing-style.md、fb-writing.md、threads-writing.md、reading-protocol.md 都在那。各專案的 CLAUDE.md 跟 SKILL 只 reference 不重複。

注意：被多個專案需要的東西不一定要寫成 Skill——它可能是 shared-rules 裡的純 markdown 規範檔。Skill 是一種封裝形式，shared-rules 是另一種。準則 1 處理的是「不該綁在單一 CLAUDE.md」，不是「一定要寫成 Skill」。

準則 2：只在特定任務型態出現的規範，不放每次都讀的常駐記憶

第二個訊號是任務頻率不對等。fb-writing.md 的內容只在「寫 FB 貼文」這個任務出現。放進 outsidewriter 的 CLAUDE.md，每次 session（包含選題、轉寫、查核、發布、debug）都繳一次 context 稅，但只有發布階段那一輪用得到。

反面也成立：永遠該知道的東西不該寫成 Skill。publish-tools 的「四條發布鐵律」（不准新增分類標籤、預設發草稿、密碼從 .env 讀、安全字 confirm）是 always-on——任何 session 都不能違反。寫成 Skill 反而有風險（如果 Claude 沒主動載入呢？）。這條留在 CLAUDE.md。

準則 3：規範越精細，越要抽成獨立 Skill

第三個訊號是字數壓力