先盤點現有的，再決定裝什麼
清單裡的 40 個 skills 是翻譯型目錄，只有名字，沒有安裝來源。 直覺是「挑幾個裝」，但更好的做法是先掃清楚現有的 215 個 skills 裡已經有什麼。
掃完之後：40 個裡 32 個已有等效——不是完全相同的 skill， 而是相同功能已被現有 skill 涵蓋。 真正的功能缺口只有 6-7 個，不是 40 個。 這告訴我：評估新 tools 的第一步不是「哪個好」，是「哪個沒有了」。
Superpowers Plugin：12/14 已有等效，不值得整包啟用
缺口裡有幾個來自 Anthropic 官方的 Superpowers plugin。 翻了一下，這個 plugin 之前在 2026-04-27 就裝好了，但一直維持停用狀態。
14 個 Superpowers skills 裡，分析下來 12 個已被現有 library 等效覆蓋 （parallel-feature-development、tdd-workflow、verification-loop、plan、skill-create 等）。 真正的新增只有 2 個。
但整包啟用有一個根本性的衝突：Superpowers 的 using-superpowers bootstrap skill
會在每次 session 開始時自動呼叫，強制讓 Claude 知道它有哪些 skills。
這直接牴觸了「預設不主動呼叫任何 skill」的設計原則——
那個原則是為了節省 context token、避免 session 開頭被不必要的 skill 加載佔滿。
邊際價值低（2 個新 skills）+ 全域衝突 → 不划算。
結論：Superpowers 維持停用。未來如果需要某個特定 Superpowers skill， 用「外科式單抽」的方式把那一個 SKILL.md 複製出來，其餘不動。
UI UX Pro Max：SKILL.md 和引擎不在同一個地方
另一個候選是 nextlevelbuilder/ui-ux-pro-max-skill。
這個 repo 的佈局藏了一個陷阱：SKILL.md 本身只有 44 KB，是純指引文件，
但 SKILL.md 裡的指令引用了 skills/ui-ux-pro-max/scripts/search.py，
實際的引擎和資料（1.8 MB）在 src/ui-ux-pro-max/ 下。
如果 naive 地只複製 SKILL.md，search.py 不存在，skill 直接壞掉。
正確做法是先 grep SKILL.md 裡的所有路徑引用，
再讀 core.py 確認 DATA_DIR 是相對 __file__ 的位置（不是 cwd），
然後把 SKILL.md + scripts/ + data/ + templates/ 組裝成兄弟結構。
從根目錄跑 search.py 冒煙測試通過，這才算真的安裝完成。
另外捨棄了同 repo 裡 6 個 ckm:* 附屬 skills——其中一個會撞到既有的 design-system，
不需要的功能不要裝。
Brainstorming：自包含驗證後單抽
真正的功能缺口只有 brainstorming。
在從 Superpowers 單抽之前，先驗證它是否自包含——
grep SKILL.md 裡所有對 superpowers/skills/ 的引用，
結果只有輸出路徑慣例（docs/superpowers/specs/）和自引用的 visual-companion.md，
沒有對其他 Superpowers skill 的硬依賴。
可以安全單抽。
64 KB 的 SKILL.md 複製過來，放進 skills-library/dev-patterns/brainstorming/。完成。
為什麼「先盤點現有的」比「看清單選」更有效
這個評估流程裡最重要的一步不是分析哪個 skill 好， 而是先建立「現有功能的地圖」。沒有那份地圖，就只能靠直覺猜哪些重疊、哪些不重疊。 有了地圖，「40 個缺口」立刻縮減到「1 個真缺口」， 也讓 Superpowers 整包啟用的決定有了具體的數字支撐（2/14 真新增）， 而不只是「感覺裝了會衝突」。
關鍵教訓
先盤點現有功能，再評估新工具：「這 40 個裡哪些有用」是錯的問題。正確的問題是「這 40 個裡哪些是現在沒有的」。盤點完再篩，工作量從 40 變 1。
整包啟用前先算邊際價值：Superpowers 12/14 已覆蓋，整包啟用卻帶來全域 bootstrap 衝突。邊際收益（2 個 skills）遠小於邊際成本（每個 session 的額外負擔）。
安裝前先驗證依賴：SKILL.md 引用 scripts/search.py 但引擎在別的目錄——不先 grep 路徑引用就複製，裝完就壞。安裝陌生 repo 的 skill 時，先讀完 SKILL.md 的路徑引用，再決定要帶什麼進來。
自包含驗證後才敢單抽：brainstorming 能安全單抽，是因為 grep 驗證了它對外部的依賴只有「輸出路徑慣例」，沒有對其他 skill 的硬依賴。不驗證就直接抽，等於裝了半個 skill。
不需要的功能不要裝：捨棄 6 個 ckm:* 附屬 skills 的決定比安裝它們更重要。功能列表只增不減，是後來難以管理的根本原因。