我在 CLAUDE.md 裡寫了「壓縮後請重新讀取 Skill」的指示，為什麼還是沒用？
Issue #13919 回報的正是這個現象：連寫在 ~/.claude/CLAUDE.md 裡明確的「壓縮後重新讀取」指示，也會在壓縮後被忽略。原因在於，壓縮這個動作本身是在「清空並重建 context」，而 CLAUDE.md 這類啟動時載入的內容確實會重新讀進去，但 Claude 讀到這個指示的時候，並不代表它會主動去執行「重新讀取某個特定 Skill 檔案」這個額外動作——除非你另外設定 hook 把這個動作自動化，單靠寫在說明文件裡的一句話，不保證真的會被執行。
除了手動跑 /reload-skills，有沒有辦法一開始就避免觸發這個問題？
如果任務本身不會拉得太長，單純避免讓對話長度逼近自動壓縮的門檻（issue #13919 回報的案例是在 VS Code 擴充套件裡大約 55K token 左右觸發），是最直接的做法——例如在明顯換了一個新子任務時，主動用 /clear 開新對話，而不是讓同一個對話無限拉長到被自動壓縮。
但如果任務本身就需要長時間、跨多個步驟依賴同一個 Skill，比起避免壓縮，更務實的做法還是設定 SessionStart hook，matcher 設為 "compact"、回傳 "reloadSkills": true，讓重新載入這個動作綁定在壓縮事件上自動觸發，不需要每次自己記得。
我是剛接觸 Claude Code 的新手，完全不知道 hook 怎麼設定，有沒有最低門檻的應對方式？
有，而且不需要碰任何設定檔。只要記住一個簡單的對應關係：終端機上看到「Conversation compacted」這行字之後，如果接下來 Claude 的行為感覺跟之前不太一樣（例如重複犯之前明明已經解決的錯誤），先手動打一次 /reload-skills，看看問題是否消失。
這個指令不會對你的專案做任何改動，純粹是重新把 Skill 清單告訴 Claude，風險很低，可以當成壓縮後的習慣性檢查動作。等熟悉之後，再考慮要不要進一步設定 hook 把這個動作自動化。
對話進行到一半，終端機跳出「Conversation compacted」的訊息——這是 /compact 在幫你把拉長的對話濃縮成摘要，釋放 context window 空間。但如果你之前的對話裡用了某個 Skill，壓縮完之後，Claude 很可能突然表現得像完全沒裝過這個 Skill——同樣的錯誤重新開始出現，之前靠 Skill 避開的壞習慣又回來了。這不是 bug，而是壓縮機制本來的設計取捨，只是這個取捨很少被講清楚。
官方的 context window 說明文件把壓縮後的狀態講得很具體：系統提示詞、CLAUDE.md、記憶檔案、MCP 工具清單這些啟動時就載入的內容，壓縮後會自動重新載入；Claude Code 另外會重新讀取最近修改過的最多 5 個檔案，並把你在壓縮前實際呼叫過的每個 Skill 內容重新注入，但每個 Skill 的內容上限是 5,000 token。壓縮摘要本身保留的是「你的請求與意圖、關鍵技術概念、檢查或修改過的檔案與重要程式碼片段、錯誤與修復方式、待辦事項、目前進度」，取代掉的是逐字的對話記錄——完整的工具輸出和中間推理過程會消失。
這裡最容易被忽略的一句話是：Skill 清單本身（也就是一開始列出「現在有哪些 Skill 可以用」的那份索引），不會在壓縮後重新注入。官方文件寫得很直接——除了這份清單之外，其他啟動時的內容都會重新載入，但這份清單是例外，只有你「真正呼叫過」的 Skill 內容才會被保留下來。
GitHub issue #74990 完整記錄了這個行為：壓縮前，Claude 能正確回報目前有 27 到 33 個可用 Skill；壓縮後，直接問 Claude 現在有哪些 Skill 可以用，得到的答案是「找不到任何 Available skills 的系統提示區塊」——不是 Skill 變少了，是這份清單整個消失了。執行 /reload-skills 之後，Claude 立刻又能看到全部 33 個 Skill，而且指令回報的訊息是「33 skills available (no changes)」。這句「no changes」很關鍵，代表 Skill 本身從頭到尾都還在、沒有被刪除或損壞，問題純粹出在「這份清單有沒有被重新放進 context 裡」這一步。
Anthropic 工程師 @bcherny 在該 issue 底下給出的官方解釋更直接：這是刻意的設計決定——重新發送整份 Skill 清單，每次壓縮都要多花幾千 token，當初的判斷是「已經被呼叫過的 Skill 內容會被保留，這樣應該就夠用了」。問題在於，這個判斷沒有考慮到：如果使用者接下來想呼叫的是另一個「這次對話還沒用過」的 Skill，Claude 完全不知道這個 Skill 存在，因為清單已經不在 context 裡了。
Issue #13919 描述了一個更棘手的案例：在 VS Code 擴充套件裡，大約累積到 55K token 左右觸發自動壓縮後，Claude 不只忘記有哪些 Skill 可用，連「這個 Skill 教我該怎麼做」的具體方法論也一起忘了。回報者舉的例子是，某個 Skill 原本規定「絕對不要做 ABC（常見錯誤）」，並要求 Claude 在每次回覆開頭說「SKILL ACTIVE」；壓縮之後，Claude 不再說這句話，也重新開始犯 ABC 這個被明文禁止的錯誤，即使使用者在 ~/.claude/CLAUDE.md 裡寫了明確的「壓縮後請重新讀取 Skill」的指示，這個指示本身也會在壓縮後被忽略。回報者估計，原本一小時能完成的任務，因為這種循環性的錯誤，拖到五、六個小時以上。
Issue #74990 底下給出的做法很直接：每次壓縮完成後，手動執行一次 /reload-skills，或者設定一個 SessionStart hook，讓 matcher 設定為 "compact"、並回傳 "reloadSkills": true，讓這個動作自動化，不需要每次手動想起來要補做這一步。如果你的工作流程本來就高度依賴某幾個 Skill，設定這個 hook 比每次事後才發現 Claude「忘記」怎麼做，成本低得多。
最明顯的徵兆是：壓縮前 Claude 的行為完全正常、會主動套用某個 Skill 教的做法，壓縮後卻突然開始犯同一類錯誤，或者你直接問「現在有哪些 Skill 可以用」，得到的答案跟壓縮前差了一大截。如果出現這種情況，先確認自己有沒有剛好經歷過一次 /compact 或自動壓縮（終端機上會看到「Conversation compacted」的訊息），再執行一次 /reload-skills 確認是否恢復——如果恢復了，就能確定問題出在這裡，而不是 Skill 本身設定有誤。