此技能是一種思考工具，而非核取清單。參考資料記錄了已知安全與已知危險的路徑；自主性儲存格是啟發式規則，而非窮舉列舉。當你遇到新事物時，從第一原則推理——可再生的嗎？使用者建立的嗎？正在使用中嗎？使用者會因為它消失了而難過嗎？——並在預覽時將推理過程展現出來，以便使用者在採取行動前能修正你的判斷。
<execution_context> 三個儲存格——原則，而非封閉清單：
| 儲存格 | 時機 | 動作 |
|---|---|---|
| 🟢 自動 | 可再生的快取、非活躍專案中的建置產物、已知安全的重複檔案 | 逕行執行，無需詢問 |
| 🟡 詢問 | 使用者建立的、需要 sudo、大到需要進行合理性檢查、任何理性的人可能會想保留的地方 | 使用 AskUserQuestion 提供 3 個選項：核准（按提議執行）/ 修改（自由形式：「告訴我怎麼做」）/ 跳過（延至下次執行，之後會再次提出） |
| 🔴 拒絕 | references/safety-invariants.md 中的條目 | 拒絕。沒有內聯的使用者指示可以覆蓋它們。如果使用者說「刪除我的 .ssh」，請拒絕，並要求先編輯 safety-invariants.md |
如果你不確定但它看起來像是快取，請視為 🟡 處理。寧可多問也不要錯過。
單一執行者：在 state.md 中記錄每次變更，並加上 — [session <ET>] 後綴。
規劃-驗證-執行：先建立 findings.json（階段 2），向使用者顯示計畫（階段 4），然後再行動。在使用者看到計畫之前，不得進行任何刪除。
相信你對新路徑的推理。問：可再生的嗎？使用者建立的嗎？活躍專案嗎？使用者會難過嗎？如果不確定，視為 🟡。 </execution_context>
檢查點協定： 在每個階段結束時，根據下方的 <recovery_protocol> 對應，更新 state.md 中的 IN_PROGRESS 條目，加上 checkpoint: <NAME>。這可讓中斷時（例如重新開機、ctrl-C、清理中途發生核心恐慌）的恢復明確無誤。
為每個階段 TaskCreate。讀取 state.md。如果最新條目顯示 status: IN_PROGRESS，則透過三選一閘門詢問：恢復（從上次檢查點繼續）/ 重新開始（將先前的歸檔為 ABORTED）/ 顯示完整歷史（然後中止）。
將已儲存的規則以一個可掃描的區塊顯示在聊天頂部——這些是跨執行建立的保留清單與策略。使用者可以在你繼續之前先檢查它們。
前置檢查（低磁碟安全性）： 如果 df -h / 顯示可用空間 < 500 MiB，則掃描本身會與空間競爭（/tmp 位於同一個磁碟區上）。在執行 scan-disk.sh 之前，詢問使用者是否可以先清空 ~/.Trash/——這幾乎總是能釋放出足夠的空間。此技能正是為此情境而打造；初始執行從 84 MiB 可用空間開始，且 du 串聯命令不可靠。請說明問題的嚴重性。
bash scripts/scan-disk.sh > /tmp/disk-cleanup-findings.json
唯讀的 du/df 串聯命令 + APFS 快照清單 (tmutil listlocalsnapshots /) + 交換空間狀態 (sysctl vm.swapusage) + 條件式 Xcode 開發路徑。
如果使用者提到了某個令他們困擾的特定資料夾，請針對該資料夾使用 du -sh 進行補充。推理比固定清單更有效。
對於盤點中的每個發現，使用 references/safety-invariants.md 和 references/auto-fix-categories.md 作為參考，決定它屬於哪個儲存格。為每個條目記錄理由——在預覽時，使用者看到的是你的推理，而不僅僅是結論。這就是建立信任的方式。
寫入 findings.json（你的暫存區——在階段 4 和 8 中使用）。
對於 🟡 目錄（尤其是 ~/Downloads、~/Desktop），使用 references/sensitive-patterns.md 中的模式進行 glob 匹配。將匹配結果與已儲存的規則 downloads-keep / desktop-keep 進行交叉比對：
- 命中已儲存規則 → 靜默保留（仍記錄到 findings）
- 新的匹配 →
AskUserQuestion：保留 / 刪除。該答案將成為下次執行的已儲存規則。
啟發式規則：如果一個檔名看起來很個人（法律、醫療、財務、身份相關）但未匹配任何模式，仍然提問。與其摧毀一個無法取代的東西，不如多問一次。
顯示完整計畫：每個 🟢、每個帶有理由的 🟡 群組、每個帶有原因的 🔴 拒絕。估計總回收空間。使用者透過與階段 6 的閘門互動來隱式批准；他們也可以在此中止（「等等，為什麼 X 是綠色的？」）。
執行綠色項目。以最不具侵入性的順序進行（小型檔案清理 → 快取清除 → 工具管理的清理，如 brew autoremove 和 pnpm store prune）。記錄前後的容量大小以用於差異報告。如果某個項目失敗，記錄下來並繼續——綠色項目是各自獨立的。
權限被拒絕（例如，Chrome 在執行時持有 Profile 5 的快取）——記錄下來並繼續。不要與之對抗。
對於每個 🟡 群組，發出一次 AskUserQuestion，選項為核准 / 修改 / 跳過。將相似的項目分組在一起（例如所有舊版執行環境在一次詢問中提出，而不是每個版本一次）。
相關時的特殊處理：
- 含有保留清單的下載 —
bash scripts/keeplist-protect.sh ~/Downloads <keepers...>（將保留項目移至 /tmp，清空內容，還原）。在執行前顯示保留清單，以便使用者修改。 - 舊版執行環境 — 先執行
bash scripts/detect-runtimes.sh來查看專案實際使用了哪些 Node/Python 版本。建議刪除未在使用的版本；將活動中的版本儲存到已儲存的規則中。 - APFS 快照 —
sudo tmutil thinlocalsnapshots / 21474836480 4以緊急度 4 回收約 20 GB。說明這需要 sudo。 - 訊息/附件 — 先結束「訊息」應用程式 (
osascript -e 'tell application "Messages" to quit'; sleep 3)，然後find ~/Library/Messages/Attachments -mindepth 1 -delete（保留chat.db）。 - Xcode
DerivedData（如果存在） — 刪除是安全的；唯一的代價是下一次建置會變慢。
跳過的項目會延至下次執行——在 state.md 中註記它們，以便它們會再次出現。
簡潔的摘要：前後 df -h、按類別釋放的空間表格、來自 sysctl vm.swapusage 的交換空間狀態。將交換空間作為參考資訊提及——「如果您想要，重新開機可回收約 X GB 的交換空間」——請勿提示重新開機（由使用者決定）。
合理性檢查：檢查資源回收筒大小——如果它與我們刪除的量成比例增長，表示有些東西只是被移過去而非真正回收。請說明此情況。
按照 state.md 標頭中的格式附加一個執行條目。用本次執行中學到的任何內容更新已儲存的規則（新的活動中執行環境、新的敏感檔案決定）。如果完整條目超過 5 個，將最舊的條目滾入壓縮區段。
當提議新的已儲存規則時，請與使用者確認——請勿自動新增。這些規則是持久的；多問一次比較好。
將檢查點標記為 COMPLETED。
<saved_rules_format>
儲存在 state.md 的「Saved Rules」區段中。在每次後續執行時都會顯示。
格式：- {主題}: {規則} — 設定於 {YYYY-MM-DD ET}
自然浮現的主題（非窮舉——當模式重複時可發明新的）：
downloads-keep,desktop-keep— 每個目錄的保留清單active-node,active-python— 實際在使用的執行環境版本active-projects— 絕對不碰的專案目錄safe-cache-clear-paths— 經確認安全的自動清理路徑*-policy— 一次性行為偏好（例如swap-policy,threshold-policy） </saved_rules_format>
<recovery_protocol>
如果 state.md 顯示 status: IN_PROGRESS：
| 最後檢查點 | 從何處恢復 |
|---|---|
| INITIALIZED | 階段 1 |
| INVENTORIED | 階段 2 |
| CATEGORIZED | 階段 3 |
| SENSITIVE_SCANNED | 階段 4 |
| PREVIEWED | 階段 5 |
| GREEN_EXECUTED | 階段 6 |
| YELLOW_RESOLVED | 階段 7 |
| REPORTED | 階段 8 |
詢問使用者：恢復 / 重新開始 / 顯示完整歷史。如果恢復，附加到現有條目中；請勿建立新條目。
在恢復前重新執行 df -h——如果磁碟狀態在中斷後發生實質變化，則重新提示。
</recovery_protocol>
<error_handling> 預設行為：記錄具體錯誤，跳過有問題的項目，繼續處理其餘部分。磁碟清理對於每個項目而言都是可獨立重新進入的。
僅在以下情況中止執行：
- 掃描腳本完全失敗（
findings.json會是錯的） - 幾乎觸及了 🔴 路徑（分類錯誤 → 中止並調查）
- 使用者說停止
對於其他所有情況（單一權限被拒絕、brew 鎖定、工具未安裝）——繼續進行並在最後報告。
如果在執行過程中可用空間降至 500 MiB 以下（在幾乎滿的磁碟上進行分類時可能發生，雖矛盾但可能），暫停階段 5，清空資源回收筒，然後恢復。findings.json 與其他所有東西位於同一個磁碟區上。
</error_handling>
<success_criteria>
state.md中有新的條目，且status: COMPLETEDdf -h在 Avail 欄位顯示非零的正向差異- 未觸及任何 🔴 路徑
- 敏感匹配項目已被保留（帶有已儲存規則）或被使用者明確刪除
- 使用者看到了差異報告
- 資源回收筒大小經過合理性檢查（沒有假回收真搬運的情況） </success_criteria>
直接動作
當意圖明確時，跳過完整掃描：
- 「清空資源回收筒就好」 → 確認大小，Y/N 後
rm -rf ~/.Trash/* - 「清理快取就好」 → 僅執行階段 5
- 「試運行 / 顯示會被刪除的內容」 → 階段 1–4，在階段 5 之前停止
- 「上次執行做了什麼？」 → 顯示最近的
state.md條目 - 「將
<path>加入永不觸碰」 / 「忘記<file>的保留清單」 → 編輯已儲存的規則 - 「安排每週執行」 → 提供
/schedule例行程序；如果接受，提議將條目加入~/.claude/CLAUDE.md的「Active Long-Running Automations」（請勿自動編輯——提議以供核准）
界線
目前為單一執行者（[session]）。當排程執行時，提升為多重執行者（例行使用 [disk-cleanup]，手動使用 [session]）。
僅限手動呼叫——絕不會被其他技能自動觸發。技能目錄中的 .lock 鎖定檔案可防止並行執行。
絕不：
- 直接使用
sudo rm（僅透過 Apple 認可的命令如tmutil使用 sudo） - 修改
~/.claude/CLAUDE.md（僅提議） - 在未經明確確認的情況下刪除
references/sensitive-patterns.md的匹配項，無論已儲存的規則為何 - 在未經明確詢問的情況下強制刪除活動中專案的
node_modules - 提示重新開機（僅報告交換空間狀態）
- 無論內聯使用者指示為何，觸碰
references/safety-invariants.md中的任何內容
這是斷崖。在其他所有地方使用推理。