Claude Code plugin 推薦：官方市集 315 個先裝這 10 個

Claude Code 的官方 plugin 市集，今天打開清單有 315 個 plugin。我數的是自己電腦上那份市集副本裡的 marketplace.json，它在 10 月 27 日早上剛同步過。兩個多月前，Scrimba 在 8 月 17 日的推薦文還寫「超過 250 個」。

315 個裡面，開發類 123 個、生產力 69 個、資料庫 39 個、監控 22 個、資安 18 個，其餘散在部署、設計、學習等分類。全部看一遍不實際，而網路上的推薦清單大多只告訴你「這個很好用」，很少告訴你裝下去要付出什麼。

所以這篇我換個方式挑。我讀了其中十幾個 plugin 的原始碼，再用 Claude Code 內建的 claude plugin details 估算每個 plugin 裝上去之後，每次對話都要多吃多少 token。先說清楚：這次我一個 plugin 都沒有真的安裝，下面講到的執行行為，依據是原始碼、README 和官方文件。

plugin 到底是什麼？一個裝了很多種零件的包

plugin 是 Claude Code 的擴充包。它本身不是一種功能，而是一個資料夾，裡面可以裝好幾種不同的元件。

圖 1：官方市集的 README 開頭（來源：GitHub）

我打開官方市集的 README，最上面就是一個警告框：安裝、更新或使用 plugin 之前，先確定你信任它；Anthropic 不控制 plugin 裡包含哪些 MCP server、檔案或其他軟體，也無法保證它們會照預期運作、不會改變。下面接著說明倉庫分兩區：/plugins 是 Anthropic 自己開發維護的，/external_plugins 是合作夥伴和社群的。

安裝指令是 /plugin install <名稱>@claude-plugins-official，或輸入 /plugin 進 Discover 分頁瀏覽。官方文件說，第一次開互動式工作階段時，Claude Code 會自動幫你加入這個官方市集。

一個 plugin 能裝的東西，我整理成下面這張表：

圖 2：plugin 的主要元件（資料來源：code.claude.com plugins 參考文件）

除了這五種，參考文件還列了 output style、bin/ 執行檔和 settings.json 等。這張表之所以重要，是因為不同元件的成本和風險完全不一樣：skill 和 agent 會占用對話的 context；hook 會在你沒注意的時候自動執行程式；MCP server 可能把資料送到別人的伺服器。後面每個 plugin，我都會指出它屬於哪一種。

安裝時還要選範圍。官方文件分三種：user（你在這台電腦的每個專案都啟用）、project（寫進 .claude/settings.json，提交後整個團隊都啟用）、local（只有你、只在這個專案）。優先順序是 local 蓋過 project，project 蓋過 user。官方市集預設會自動更新，其他第三方市集預設不會。

裝之前先看成本：每個 plugin 常駐多少 token？

這是我覺得最少人講、卻最實用的一件事。Claude Code 有個指令 claude plugin details <名稱>，會列出 plugin 的元件清單和預估的 token 成本。它預設只查已安裝的 plugin；我第一次對沒裝的 plugin 執行時，錯誤訊息直接提示可以加 --plugin-dir 從磁碟載入。照著把這個全域參數指到本機的 plugin 資料夾，就能在不安裝的情況下查詢：

claude --plugin-dir <plugin 資料夾> plugin details <名稱>

輸出分兩種成本。「常駐」（Always-on）是每次對話都會加上的量，主要是每個 skill 和 agent 的名稱與描述，Claude 要靠這些來判斷什麼時候該用它們。「觸發時」（on-invoke）是真的用到那個 skill 或 agent 時，才載入的完整內容。

圖 3：我用 claude plugin details 估算的結果，2026 年 10 月 27 日（數字為工具的估計值）

幾個觀察：

• pr-review-toolkit 是最重的，常駐約 2,035 token。 原因是它帶了 6 個 agent，每個 agent 的描述都會常駐，其中 code-simplifier 一個就約 730、silent-failure-hunter 約 460。
• code-review 只要約 22。 它只有一個指令，描述很短，完整的 2.5k 只在你下指令時才載入。
• security-guidance 是 0。 它全是 hook，工具輸出標註「harness-only — no model context cost」，hook 由 Claude Code 自己執行，不進模型的 context。但 0 token 不等於 0 成本，後面會講。

輸出最後一行寫著：token 數是估計值，可能跟實際用量不同。我也要補充這張表沒涵蓋的：LSP 類的 plugin 本機資料夾裡沒有設定檔（設定寫在市集清單裡），MCP 類的我沒有跑，因為不想冒險讓它真的啟動外部程式。官方文件提到，/plugin 的已安裝分頁有一區「Not used recently」，列的是一陣子沒用、但仍在增加啟動與 context 成本的 plugin，可以定期去清。

下面是我挑的 10 個（LSP 依語言選一個算一個）。

1. LSP：讓 Claude 改完程式馬上看到型別錯誤

php-lsp、typescript-lsp、pyright-lsp 這一系列，把語言伺服器接進 Claude Code。Claude 改完檔案之後，可以直接拿到診斷結果：型別錯誤、找不到的方法、跳到定義，不用等你跑測試才發現。

我打開 php-lsp 的資料夾，裡面只有 README 和 LICENSE。真正的設定寫在 marketplace.json 這個 plugin 的條目裡（strict: false）：用 intelephense --stdio 啟動，對應 .php 副檔名。typescript-lsp 用 typescript-language-server --stdio，涵蓋 .ts、.tsx、.js、.mjs 等 8 種副檔名。

要注意的是，plugin 不包含語言伺服器本身。php-lsp 的 README 要你先用 npm install -g intelephense 自己裝，沒裝的話 plugin 就沒有東西可以啟動。

Scrimba 和 Composio 的推薦文，都把 LSP 放在第一順位。我同意這個排法：它不改變 Claude 的行為，只是給它更準確的回饋，對寫 PHP、TypeScript 這類有型別資訊的語言特別有用。

2. commit-commands：一個指令完成 commit

它有三個指令：/commit、/commit-push-pr、/clean_gone。常駐約 105 token。

我讀了 commit.md 的內容，它是個很好的範例，說明一個指令檔怎麼寫。開頭的 ! 加反引號語法，會在指令送給 Claude 之前先執行 git status、git diff HEAD、git log --oneline -10，把結果直接塞進提示裡。Claude 一開始就看得到變更內容和最近的 commit 風格，不用再花幾輪去查。

另一個要看的是 allowed-tools 欄位。/commit 預先核准了 git add、git status、git commit；/commit-push-pr 則多核准了 git push 和 gh pr create。官方 skills 文件寫得很清楚：allowed-tools 不會限制 Claude 能用哪些工具，它的作用是讓列出來的工具不用再問你。換句話說，你下 /commit-push-pr，Claude 會直接推上遠端、開 PR，中間不會停下來等你同意。用之前要知道這一點。

/clean_gone 會清掉遠端已經刪除、本機還留著的分支，連同對應的 worktree。/commit-push-pr 需要先裝好並登入 GitHub CLI（gh）。

3 和 4. code-review 和 pr-review-toolkit：送 PR 前多一雙眼

這兩個都跟審查有關，但設計差很多。

圖 4：code-review plugin 的流程說明（來源：GitHub README）

code-review 只有一個 /code-review 指令，針對 GitHub 上的 PR。它會跳過已關閉、草稿、太瑣碎或已審過的 PR，收集倉庫裡的 CLAUDE.md，然後平行啟動 4 個 agent：兩個檢查是否符合 CLAUDE.md、一個找明顯的 bug、一個看 git blame 和歷史。每個問題打 0 到 100 分的信心分數，80 分以下的全部丟掉，最後只把高信心的問題留言到 PR 上。README 也列了它刻意過濾掉的東西：PR 之前就存在的問題、linter 會抓的問題、吹毛求疵的意見。

它的 allowed-tools 預先核准了 gh pr comment，所以留言時不會再問你。

有個小地方要提：我這台沒裝任何 plugin 的 Claude Code，指令清單裡已經有一個內建的 /code-review。官方文件說，plugin 的 skill 跟其他位置的 skill 同名時兩個都會載入，plugin 的版本要用帶命名空間的 /code-review:code-review 呼叫。我不打算比較兩者誰比較好，只是提醒你裝了之後別打錯。

pr-review-toolkit 則是 6 個專門的 agent：comment-analyzer 看註解是否跟程式一致、pr-test-analyzer 看測試覆蓋的缺口、silent-failure-hunter 找被吞掉的錯誤、type-design-analyzer 看型別設計，加上通用的 code-reviewer 和 code-simplifier。可以用 /review-pr 一次跑，也可以直接跟 Claude 說「幫我檢查錯誤處理」讓它挑對應的 agent。

代價就是前面那張表的 2,035 token 常駐。我的建議是：如果你只是偶爾想在送 PR 前檢查一下，code-review 輕得多；如果你每天都在審大量 PR，pr-review-toolkit 的分工比較細，值得那個成本。也可以把 pr-review-toolkit 裝在 project 範圍，只在需要的專案啟用。

5. feature-dev：先看懂程式碼，再動手

/feature-dev 把開發一個新功能拆成 7 個階段：釐清需求、探索現有程式碼、提出澄清問題、設計架構、實作、品質審查、總結。第 2、4、6 階段分別自動叫出 code-explorer、code-architect、code-reviewer 三個 agent。

README 特別標註第 3 階段是關鍵：在設計開始前，確保沒有模糊的地方。這對應到一個很常見的問題：AI 直接開寫，寫到一半才發現理解錯需求。常駐約 240 token，以它提供的流程來說不貴。

6. security-guidance：常駐 0 token，但不是免費

這是 10 個裡面設計最複雜的一個，也是最容易被誤解成本的一個。

圖 5：security-guidance 的三層設計與安裝需求（來源：GitHub README）

README 說它有三層：

1. 樣式警告：Claude 編輯或寫檔時，用正規表示式比對約 25 種危險寫法，例如 yaml.load、pickle.load 讀不可信的資料、直接設定 innerHTML、寫死的密鑰。
2. LLM diff 審查：每次 Claude 結束一個回合，把 diff 送給一次 LLM 呼叫，預設是最新的 Opus，把高嚴重度的發現回饋給 Claude，讓它在你看到回覆前先修。
3. commit 審查：git commit 時，一個用 Agent SDK 驅動的審查者會讀相關檔案，追蹤跨檔案的資料流，抓 IDOR、繞過驗證這類單看樣式抓不到的問題。

這就是 0 token 的意思：這些審查都不在你的對話 context 裡，所以 plugin details 算出來是 0。但第 2、3 層每次都在呼叫 Opus，用的是你的 Claude Code 登入或 API key。也就是說，每結束一個回合、每做一次 commit 或 push，就多一次 Opus 的用量。這才是它真正的成本。

我讀了它的 hooks.json，還有幾個實際要注意的地方：

• 需要 Claude Code 2.1.144 以上、PATH 裡有 Python 3.8 以上。
• 每個 hook 都用 bash 執行一支包裝腳本，所以要找得到 bash。我在自己電腦的 PowerShell 查，bash 指到的是 System32 底下的 bash.exe，也就是 WSL 的啟動程式，不是 Git 附的那個。Claude Code 執行 hook 時用哪一個，取決於它自己的環境，我沒有實際跑過，但值得留意。
• SessionStart 的 hook 會檢查 Claude Agent SDK 能不能匯入，不行的話會在 ~/.claude/security/agent-sdk-venv 建一個 Python 虛擬環境並安裝 SDK。這個資料夾在你的使用者目錄下；如果你的系統碟空間吃緊，要知道它會長在那裡。
• 不想要某一層，可以用環境變數關掉：ENABLE_STOP_REVIEW=0 只關每回合的審查、ENABLE_COMMIT_REVIEW=0 關 commit 審查，SECURITY_GUIDANCE_DISABLE=1 整個關掉。

我的看法是，如果你在意安全，這是 10 個裡最值得裝的之一，但最好先只開第 1、3 層，觀察一陣子用量再決定要不要開每回合的 diff 審查。

7. hookify：用 Markdown 寫規則，管住 Claude 的壞習慣

如果你發現自己一直在糾正 Claude 同一件事，例如它老是用 console.log、老是想 rm -rf，hookify 讓你把這些糾正變成規則。

圖 6：hookify 的規則檔格式（資料來源：hookify 範例檔）

規則是一個 Markdown 檔，放在 .claude/hookify.<名稱>.local.md。前面的 YAML 寫要看哪種事件（bash、file、stop 等）、用什麼正規表示式比對、要擋下（block）還是只警告（warn）；內文是觸發時顯示的訊息。README 說規則存檔後，下一次工具呼叫就生效，不用重開。

最方便的是 /hookify 不帶參數的用法：它會分析最近的對話，找出你糾正過或不滿意的行為，幫你產生規則。常駐約 294 token。

跟 security-guidance 一樣，hookify 也有 4 個 hook，在工具呼叫前後、回合結束和你送出訊息時執行它的 Python 規則引擎。差別在於 security-guidance 會依序試 python3、python、py -3，用第一個能跑的；hookify 的 hooks.json 則寫死呼叫 python3。

這在 Windows 上值得先確認。我在自己電腦的 PowerShell 查了一下：python3 指到 WindowsApps 資料夾裡一個 0 位元組的檔案，那是 Windows 的應用程式執行別名，真的執行 python3 --version 什麼都沒印出來，結束代碼是 9009。我電腦上的 Python 裝在別的路徑，沒有放進 PATH。Claude Code 執行 hook 時的環境可能跟我的 PowerShell 不同，所以我不能斷定 hookify 在這台電腦一定會失敗，但如果你裝了之後規則完全沒反應，這是第一個該查的地方。

8. claude-md-management：讓 CLAUDE.md 不過期

CLAUDE.md 是 Claude Code 每次都會讀的專案說明。問題是專案會變，CLAUDE.md 常常沒跟上。這個 plugin 有兩個工具：claude-md-improver 這個 skill 會拿 CLAUDE.md 對照目前的程式碼，檢查品質和過期的內容；/revise-claude-md 指令則在一段工作結束時，把這次對話中學到、但 CLAUDE.md 沒寫的東西補進去。常駐約 177 token。

我覺得它最適合的時機，是一段工作中你一直在跟 Claude 解釋同一個專案慣例的時候。跑一次 /revise-claude-md，下次就不用再解釋。

9 和 10. MCP plugin：先搞清楚程式在哪裡跑

MCP plugin 給 Claude 接上新的外部工具。它們的風險模型跟前面的都不一樣，所以我把四個常被推薦的 MCP plugin 設定檔一個個打開來看，其中 context7 和 playwright 是我的第 9、10 個。

圖 7：我讀各 plugin 的 .mcp.json 整理的比較（資料來源：官方市集）

context7（Upstash）讓 Claude 查詢各種函式庫最新版本的文件和範例，避免它用過時的 API。它提供兩個工具：resolve-library-id 找函式庫的 ID 和版本，query-docs 取文件。它是遠端 HTTP 型的 MCP，你的電腦上不跑任何程式，但你的查詢內容會送到 Upstash 的伺服器。

讀它的設定時，我發現 API key 的說明有三種版本：市集清單說可以匿名使用、設 CONTEXT7_API_KEY 提高額度；plugin.json 說「出現提示時進行驗證」；README 說設定會自動讀取那個環境變數。但 .mcp.json 裡只有一個網址，沒有任何引用那個環境變數的地方。遠端 MCP server 可以自己跳出登入流程，所以我不能斷定環境變數沒作用，只能說從設定檔看不出它怎麼被送出去。

playwright（Microsoft）讓 Claude 開瀏覽器、點按鈕、填表單、截圖，適合做端對端測試，或檢查自己改的網頁長什麼樣子。它的 .mcp.json 是 npx @playwright/mcp@latest：程式在你的電腦上跑，而且版本沒有鎖定，每次啟動都會抓 npm 上當下最新的版本。這在方便性和可預期性之間是個取捨，你應該知道你選了哪一邊。

github 連到 GitHub 的遠端 MCP server，用 GITHUB_PERSONAL_ACCESS_TOKEN 當 Bearer token。權杖能做的事，Claude 就都能做，所以權杖的權限範圍要自己控制好。它不在我的 10 個裡，因為 commit-commands 加上 gh 已經涵蓋大部分日常需求，但很多推薦文都列了它。

順帶一提，寫 Laravel 的讀者可以留意 laravel-boost：它的設定是在專案目錄執行 php artisan boost:mcp，所以專案裡要先有這個 artisan 指令才能啟動。

怎麼挑？依你的情況

圖 8：我依前面的分析整理的挑選建議

兩篇我參考的推薦文，Scrimba（Per Harald Borgen，8 月 17 日）和 Composio（6 月 1 日），挑的東西跟我大致重疊：LSP、GitHub、commit-commands、審查類、security-guidance 兩篇都有，Scrimba 另外也推薦 context7 和 playwright。差別在於它們很少講成本。Composio 那篇列了各 plugin 的公開安裝數，例如 Frontend Design 約 83 萬、Context7 約 35 萬，但那是它截至 6 月 1 日的數字，我沒辦法驗證；它也把自家產品排在第一，看的時候要打點折扣。

清單裡沒放、但你可能會遇到的兩個：frontend-design 和 skill-creator。它們其實是包成 plugin 的單一 skill，我會在另一篇講 skill 的文章裡細談。前陣子寫的 Claude Code Discord plugin 也來自同一個官方市集，那篇示範了怎麼讀一個 plugin 的原始碼來判斷它安不安全。

我自己的原則有三條：

• 一次只裝一兩個。 每個 plugin 的常駐成本會疊加，裝了用不到的，就是每次對話都在付錢。
• 裝之前先跑 plugin details。 30 秒就能知道它會常駐多少、有沒有 hook、有沒有 MCP server。
• hook 和 MCP 要多看一眼。 skill 和 agent 只是給 Claude 看的文字；hook 會在你的電腦上自動執行程式，MCP 可能把資料送出去。官方 README 那句「先確定你信任它」，對這兩類最重要。

如果你也在評估 AI 代理 的工具該給到什麼程度，這三條其實都適用：先看它能做什麼，再決定要不要讓它做。