我有一段時間很容易看到好用的 Skill 就安裝。設計、研究、規劃、review，先收下再說。直到某次想替 subagent 瘦身，才發現它還沒開始做事，context 就已經先付出一筆不小的開機費。
一開始我以為問題出在 CLAUDE.md 太長。量完才發現，我抓錯大頭了。
真正佔位置的，是 Skill 的說明清單
當時我的環境裝了 47 個 user Skills。把每個 Skill 的 name 與 description 加總後，約有 20.2 KB，估計是 5,500 到 7,000 tokens；相較之下，CLAUDE.md 約 2,000 到 2,800 tokens。
這不代表 47 份 SKILL.md 正文全被塞進來。一般情況下，啟動時先帶的是 Skill 的名稱與說明，正文等真正觸發時才讀。但對 subagent 而言，這份說明清單會再付一次；若 Agent 的 frontmatter 又明確綁定 skills:，指定 Skill 的完整內容還會預載進去。
問題從來不是「Skill 本文是不是很長」，而是我讓多少能力一直站在入口等著。
/doctor 給我一份清單，不是一鍵刪除按鈕
研究途中，我才發現 Claude Code 可以在對話裡輸入 /doctor 做健檢；Codex 也有同等用途的 codex doctor，但它要在系統終端執行。Codex 官方文件把它定義為本機安裝、設定、登入與 runtime 的診斷報告。
兩個入口的觸發方式不同，但幫我的事情一樣：把「我到底裝了什麼」攤開來看。
不過我很快踩到一個反例。/doctor 當時讀的是其中一個帳號的 usage 計數；另一個帳號裡，幾個看似低 usage 的 Skill 其實仍在工作。要是只看那一份報告直接刪，反而會誤傷自己常用的流程。
所以診斷報告是盤點起點，不是裁決書。
我後來把每個 Skill 分到四個去處
| 這個能力的情況 | 我會怎麼放 |
|---|---|
| 固定 Agent 每次都需要 | 預載，明確付出 token 成本 |
| 只有特定類型任務才需要 | 保留 Skill，讓它按需觸發 |
| Agent 專屬的方法論，不想污染主 context | 移到共同 reference，由 Agent 在需要時 Read |
| demo 遺留、失效引用或已無實際用途 | 移除，連同引用與 metadata 一起檢查 |
這個分類也改變了我看待「低 usage」的方式。低 usage 不一定代表沒價值：有些是低頻但必要的救援工具；有些則是只該住在特定專案，不該讓所有 session 都替它付費。
例如我把幾個思考方法的完整檔案移出 Skill 掃描路徑，改由特定 Agent 在符合情境時讀取。內容沒有濃縮或犧牲，只是從「每個 Agent 都先背著」改成「真的需要時再拿出來」。
瘦身不是刪得越多越好
後來留下來的 Skill 比以前少，但我不再把清單變短當成目標。真正重要的是，每一份常駐內容都要回答得出來：它是不是每次都值得佔一個位置？
這個問題看起來很小，卻會隨著 subagent、不同帳號與更多工作流程一路放大。把 Skill 放到對的位置後，Agent 開場終於不必先背著一整間工具倉庫。
