Claude Code工具鏈怎麼分工？CLAUDE.md、Skills、Hooks、MCP與Subagents

Claude Code工具鏈怎麼分工？CLAUDE.md、Skills、Hooks、MCP與Subagents

先講結論：Claude Code工具鏈怎麼分工？本文整理CLAUDE.md、Rules、Auto Memory、Skills、Hooks、MCP、Subagents與Plugins的責任和導入順序。

Claude Code工具鏈怎麼分工？CLAUDE.md、Skills、Hooks、MCP與Subagents在講什麼？ Claude Code工具鏈怎麼分工？本文整理CLAUDE.md、Rules、Auto Memory、Skills、Hooks、MCP、Subagents與Plugins的責任和導入順序。

先記住哪個結論？ 核心是把「Claude Code工具鏈怎麼分工？CLAUDE.md、Skills、Hooks、MCP與Subagents」放回完整脈絡，區分已知資訊、背景與可延伸的判斷。

文中整理了哪些重點？ 文章依序整理：Claude Code工具鏈怎麼分工？本文整理CLAUDE.md、Rules、Auto Memory、Skills、Hooks、MCP、Subagents與Plugins的責任和導入順序。，並補充相關背景、影響與讀者可查證的線索。

讀者最容易忽略什麼？ 不要只看標題；請同時確認時間、人物、作品或事件名稱，以及資訊的原始來源。

這個主題和台灣讀者有何關係？ 對台灣讀者而言，清楚的中文脈絡、關鍵字與可延伸閱讀入口，能讓後續查證更有效率。

哪些資訊需要再核對？ 涉及日期、名單、票價、健康、政策、交通或產品規格時，仍應以文章列出的一手來源與最新公告為準。

如果只看一段，建議看哪裡？ 可先讀這個答案區與文章開頭，再依需求回到正文的背景、分析與常見問題。

這篇內容適合誰？ 適合想快速掌握「Claude Code工具鏈怎麼分工 CLAUDE.md Skills Hooks…」並需要延伸閱讀入口的讀者。

一句話總結？ 一句話：Claude Code工具鏈怎麼分工？本文整理CLAUDE.md、Rules、Auto Memory、Skills、Hooks、MCP、Subagents與Plugins的責任和導入順序。

Claude Code工具鏈的核心，是把「持續指令、可重用方法、確定性自動化、外部連接和隔離分工」放在不同層級。CLAUDE.md與Rules提供專案規則，Auto Memory保存Claude自行累積的Repository經驗，Skills封裝任務方法，Hooks在生命週期事件執行Command、HTTP、Prompt、Agent或MCP Tool，MCP連接外部系統，Subagents則在獨立Context中處理局部工作。Plugins可以把Skills、Agents、Hooks、MCP與LSP等元件打包分發。本文聚焦工具鏈分工；日常操作、成本、Ralph與Agent Teams由其他四篇承接。

• CLAUDE.md保存每個Session都需要知道的專案規則。
• .claude/rules/依路徑或領域載入更細規則。
• Auto Memory由Claude自行寫入，每個Repository跨Session使用。
• Skills適合多步驟工作方法，Subagents適合獨立Context工作。
• Hooks負責固定時點的檢查、攔截、通知和驗證。
• MCP連接Issue、設計、監控、資料庫與內部API。
• Plugins將多種擴充元件包成可安裝單位。

Claude Code 工具鏈的責任分工

Claude Code 工具鏈怎麼分工，需把 CLAUDE.md、Skills、Hooks、MCP 與 Subagents 放在任務生命週期中看。文章不是列名詞，而是說明指令、能力封裝、事件攔截、外部工具與並行代理各自負責什麼。

工具鏈如何避免權責混亂

• CLAUDE.md：保存專案規則、工作方式與不可違反的邊界。
• Skills：封裝可重複的專業流程與輸出契約。
• Hooks：在特定事件自動檢查或阻擋；MCP 提供外部資料／工具介面。
• Subagents：分工處理研究、測試或審查，但需要清楚的交接與權限。

本文以「Claude Code 工具鏈的責任分工」為主線，補回人物、作品、制度、技術、場景與它們之間的關係，讓讀者能從具名實體一路追到實際流程與文化語境。

各元件如何分工

元件	主要責任	適合內容
CLAUDE.md	持續提供專案指令	架構、命令、Coding標準、禁止事項
Rules	依路徑或主題拆分指令	前端、API、安全、測試特定規則
Auto Memory	由Claude保存跨Session經驗	建置方式、除錯線索、使用者偏好
Skills	可重用工作方法	Release、Migration、審查與報告
Hooks	固定事件自動執行	格式化、掃描、通知、攔截與驗證
MCP	連接外部工具與資料	GitHub、Jira、Sentry、Figma、資料庫
Subagents	隔離Context與專業分工	研究、測試、安全、文件與獨立模組
Plugins	封裝與分發擴充	Skills、Agents、Hooks、MCP、LSP、Monitors

CLAUDE.md放什麼

CLAUDE.md適合保存每次進入Repository都需要知道的事情，例如專案結構、安裝與測試命令、不可修改目錄、相容性要求和完成條件。

• 保持具體、短而穩定。
• 重複被修正的錯誤才值得加入。
• 多步驟程序移到Skill。
• 只對特定路徑有效的內容移到Rules。
• 必須被強制執行的事項交給Hook、CI或Sandbox。

官方文件提醒，CLAUDE.md屬於Context，不是強制安全設定；模糊或衝突內容仍可能不被穩定遵循。

Rules如何降低無關Context

.claude/rules/可以依檔案路徑載入規則，讓前端、後端、安全和測試要求只在相關工作中出現。

.claude/rules/
├── security.md
├── testing.md
├── frontend.md
└── api.md

---
paths:
  - "src/**/*.{ts,tsx}"
---
- Preserve accessibility labels.
- Run component tests.
- Update snapshots only for intentional UI changes.

Auto Memory和CLAUDE.md有何差別

CLAUDE.md由人編寫，Auto Memory則由Claude根據修正與工作經驗自行保存。兩者都會在新Session載入，但用途不同。

• CLAUDE.md：團隊可審查、版本控制的明確規則。
• Auto Memory：建置指令、除錯洞察和Claude發現的模式。
• /memory：查看已載入指令、開關Auto Memory及開啟記憶目錄。

安全、法規和禁止事項不能只依賴Auto Memory；它應可被查看、編輯與刪除。

Skills何時使用

Skill回答「遇到這類任務時，應依什麼流程完成」。它可包含SKILL.md、範例、模板、參考資料和腳本，相關時才載入。

• 發布套件與Release。
• 資料Migration。
• 安全審查與事故報告。
• 建立Changelog或文件。
• 固定格式的Code Review。

專案共用命令放CLAUDE.md；只有發布時才需要的完整流程放Skill。

Hooks目前支援哪些類型

Hooks在Claude Code生命週期事件發生時執行，可設定於使用者、專案、本機或Plugin層級。官方目前支援Command、HTTP、Prompt、Agent與MCP Tool等處理方式。

• Command：執行Shell腳本、Lint、掃描或通知。
• HTTP：呼叫受控Endpoint。
• Prompt：用快速模型判斷是否允許或繼續。
• Agent：讓Agent執行較完整的驗證工作。
• MCP Tool：在事件中呼叫MCP能力。

Hooks適合做什麼

• PreToolUse阻擋危險Shell或外連。
• PostToolUse在修改後執行Format與局部測試。
• PermissionRequest加入組織核准規則。
• Stop檢查任務是否真的完成。
• SubagentStop驗證子任務輸出。
• TaskCompleted避免未通過驗收便標記完成。
• ConfigChange阻擋未核准設定變更。

Hook本身可執行程式，也需要Code Review、固定版本、窄Secrets與網路權限。

MCP如何連接外部系統

MCP Server讓Claude Code直接讀取或操作Issue Tracker、監控、設計、資料庫和內部API。遠端服務官方建議優先使用HTTP傳輸，需登入的Server可透過/mcp完成OAuth。

• 讀取與寫入使用不同Tool或Scope。
• 正式資料庫優先使用唯讀Replica。
• Project級Server需經團隊審查。
• Client Secret不寫入Repository。
• 限制工具輸出大小，避免Context被大量資料淹沒。
• 高風險Tool明確標示副作用與確認要求。

Subagents何時值得使用

Subagent使用獨立Context完成工作，只將摘要或結果傳回主Session，適合需要讀取大量檔案但主對話只需要結論的工作。

• 獨立研究和依賴分析。
• 測試、安全與文件專項Review。
• 互不重疊模組的局部Patch。
• 以isolation: worktree建立臨時Git Worktree。
• 設定maxTurns、Skills、MCP、Memory與Permission Mode。

同一核心檔案、尚未確定的Schema或高度依賴工作，不適合直接平行交給多個Subagent。

Plugins如何統一分發

Plugin是一個自包含目錄，可封裝Skills、Agents、Hooks、MCP Servers、LSP Servers與Monitors，並透過Marketplace或安裝命令分發。

當一套擴充需要在多個Repository或團隊使用時，Plugin比複製.claude/檔案更容易管理版本與依賴。

可靠導入順序

1. 先建立Git回退、測試、CI、權限與Sandbox。
2. 用CLAUDE.md保存穩定共用規則。
3. 用Rules拆分目錄與領域要求。
4. 檢查Auto Memory的保存內容與開關。
5. 將高頻多步驟工作封裝為Skills。
6. 用Hooks執行可確定的攔截和驗證。
7. 逐個加入MCP，限制Scope與副作用。
8. 只對可獨立驗收工作使用Subagents。
9. 需要跨專案分發時再建立Plugin。

五篇內容如何分工

• 操作指南：Session、Plan、權限、Git與交付。
• 本篇：CLAUDE.md、Rules、Memory、Skills、Hooks、MCP、Subagents與Plugins。
• 額度成本：訂閱、Credits與API。
• Ralph Loop：Stop Hook與迭代控制。
• Agent Teams：多Session協作與整合。

讀者常問

CLAUDE.md和Skill最大差別是什麼？

CLAUDE.md保存每個Session都需要的規則，Skill保存只有特定任務才需要的完整方法。

Hooks可以取代CI嗎？

不能。Hooks適合提早攔截與自動檢查，正式Merge仍要使用獨立CI與Review。

Subagent和Agent Team一樣嗎？

不一樣。Subagent回報主Session；Agent Team的Teammates是獨立Claude Code實例，可直接互相通信。

Auto Memory能放安全政策嗎？

不應只依賴它。安全政策需要版本控制、Managed Settings、Permissions與Sandbox強制。

官方資料

• Extend Claude Code
• Memory、CLAUDE.md與Rules
• Hooks Reference
• MCP
• Subagents
• Plugins Reference

Claude Code工具鏈成熟與否，不由安裝多少擴充決定，而由每項能力是否放在正確層級、使用最小權限、能被驗證，也能在失敗時移除和回退。

YOLO_DEPTH_IMAGE_37347_20260817

Claude Code 工具鏈最容易被用成一團混合物：把所有規則寫進 CLAUDE.md，把所有操作做成 hook，把外部服務全部接到 MCP，再用 subagent 和 plugin 疊出更多自動化。短期看起來功能很多，長期卻會出現三個問題：Agent 不知道哪條規則是硬限制、工具權限超過目前任務需要、以及失敗時沒有人能判斷是記憶、技能、hook、MCP 還是模型本身造成。

比較穩健的分工方式，是讓每一層只解決一種問題。CLAUDE.md 負責專案和工作目錄的長期上下文；Skills 負責可按需載入的任務方法；Hooks 負責在特定生命週期事件做機械檢查；MCP 負責標準化連接外部資料與工具；Subagents 負責隔離或委派一個較窄的工作；Plugins 則是把多個設定、技能、工具或 hooks 打包分發。這些元件可以一起用，但不能互相取代。工具越多，越需要清楚的 scope、permission、輸出 schema 和驗收。

CLAUDE.md：放穩定、共享、值得每次載入的規則

CLAUDE.md 適合放專案架構、編碼標準、常用工作流程、測試命令、目錄地圖和禁止事項。它的內容會進入 Agent 的工作上下文，因此要優先放那些每次任務都可能需要、且修改成本較高的規則。Anthropic 官方 memory 文件將專案記憶、使用者記憶和本地專案偏好區分開，這個區分很重要：團隊規則不應與個人快捷設定混在同一份正典裡。

CLAUDE.md 不適合放每一個 ticket 的詳細步驟、巨大 API response、長篇事故紀錄或每天變動的版本表。這些資料應保存在文件、artifact 或 issue，再由記憶檔指向來源和讀取方式。上下文越長，真正重要的禁止事項和驗收條件越可能被稀釋；寫得少但穩定，通常比把整個 wiki 貼進去更可靠。

規則檔也不是權限系統。CLAUDE.md 可以說「不要把 secret 印出」「修改 migration 前先備份」，但真正的 secret access、filesystem permission、branch protection、CI policy 和 production credential 仍要由環境控制。把安全責任全放在 prompt 上，會讓一次忽略或上下文截斷就變成外部事故。最好的做法是規則檔負責引導，系統權限負責阻擋，驗證流程負責讀回。

Skills：把方法封裝成按需載入的任務單元

Skill 適合放「如何完成某一類工作」：例如資料庫 migration review、React accessibility audit、發布前 SEO 檢查或建立 release note。它可以包含流程、輸入輸出格式、輔助腳本、範例和檢查表，但不應把所有專案共同規則重新複製一份。Skill 的重點是 task-specific method；CLAUDE.md 的重點是 project-specific context。兩者混在一起，會讓每個任務都載入不需要的內容。

一個好的 Skill 要有觸發條件、前置資料、最小命令、驗收 gate、失敗處理和輸出格式。若只是把一段很長的 prompt 命名成 skill，模型仍然要自行猜測邊界。可以把 Skill 看成可重用的 runbook：它告訴 Agent 先讀什麼、再做什麼、做完如何證明，必要時把機械檢查交給腳本執行。

Skill 的權限不應因為被載入就自動擴大。讀取型 skill 可以安全地分析；寫入型 skill 要明確列出目標範圍、備份、鎖、回滾和 read-back；對外操作則要有單獨的批准 gate。若同一個 skill 同時能搜尋、修改和發布，最好拆成分析、準備和執行三個層次，讓使用者可以只開啟需要的權限。

Hooks：讓機械檢查在固定時機自動發生

Hook 的價值在於它不靠模型「記得要做」。例如在工具執行前檢查路徑是否在 allowlist、在寫入前檢查檔案 hash、在提交前執行 lint、在輸出後掃描 secret，這些工作若規則固定，應交給程式而不是自然語言提醒。Hook 的輸出要有明確的 allow、deny、warn 或需要人工處理狀態，並保留錯誤訊息與相關檔案。

Hook 不是萬能 middleware。它只能在被觸發的事件和它能讀到的資料範圍內做判斷；若 hook 沒有涵蓋某個外部副作用，就不能宣稱整個流程已受保護。也要留意 hook 失敗時的策略：安全檢查通常 fail-closed，非關鍵格式檢查可以 warn；如果所有 hook 都用同一種阻擋策略，低風險任務可能被不必要地卡住。

Hook 本身也需要版本、timeout、log 和測試。不要讓 hook 靜默修改使用者檔案、偷偷上傳資料或呼叫未授權網路；若需要外部服務，至少記錄 endpoint、輸入摘要、回應狀態和 fallback。當 hook 失敗時，Agent 應能看到足夠資訊修復，使用者也能知道它不是模型拒絕，而是生命週期檢查阻擋。

MCP：連接工具與資料，不等於自動獲得信任

Model Context Protocol 的定位是標準化應用程式如何向 LLM 提供 context。Anthropic 官方文件把 MCP 描述成連接資料來源與工具的協定，並列出它在 Claude Code、Messages API、Claude Desktop 等產品中的使用方式。MCP 讓工具描述和連線方式較一致，但不會替你決定哪些 server 可信、哪些資料可被模型讀取、哪些工具需要批准。

新增 MCP server 前先做 inventory：server 由誰維護、使用哪種 transport、能讀寫哪些資料、是否保存輸入、需要哪些 credentials、是否能執行外部副作用、以及怎麼停用。專案 scope、使用者 scope 和全域 scope 要分清楚；一個團隊共用的 CRM server 不應因為某個 repo 需要查文件就被所有工作自動載入。

MCP tool 的 schema 只保證輸入形式，不保證意圖和權限。對讀取工具，要限制資料範圍、筆數、欄位與敏感資料；對寫入工具，要有 dry-run、idempotency、批准、版本鎖和 read-back。外部服務回傳的文字也不必然可信，Agent 不能把 tool output 裡的指令當成高優先級規則。把工具資料、專案規則和模型推理分層，是防止 prompt injection 與權限混淆的基本做法。

Subagents：用角色邊界縮小任務，不是複製更多模型

Subagent 適合把一個複雜任務拆成研究、實作、測試、review 或文件等窄角色。它可以只拿到特定檔案、特定工具和特定輸出 schema，再把結果交回主 Agent。這樣做的好處是上下文更小、責任更清楚、某個角色可以使用不同的模型或 timeout；代價是需要處理交接、版本、失敗、並行和總成本。

不要因為「多 Agent」聽起來更強就把所有工作平行化。共享檔案、資料庫、branch、外部 API 或發布資源仍然需要單一 writer 或明確鎖。可並行的通常是唯讀研究、獨立測試或不互相覆蓋的候選生成；會產生副作用的步驟應序列化，並在每一段完成後驗證真實狀態。

Subagent 的輸出應是 artifact 或結構化報告，不是只有「完成了」。至少保存輸入範圍、工具事件、檔案變更、測試結果、來源、未解問題和建議下一步。主 Agent 可以整合這些輸出，但不能把某個 subagent 的自我宣告當作外部事實。對高風險任務，再加一個獨立 verifier，比讓同一個 Agent 重新複述自己的答案更有價值。

Plugins：把可重用組件打包，但要控制供應鏈

Plugin 比 Skill 的範圍更大，通常可以包含指令、skills、hooks、MCP 設定、資產或多個 agent 角色。它適合在多個 repo 或團隊之間分發一致工具鏈，但也因此帶來更高的供應鏈和權限風險。安裝 plugin 前要確認來源、版本、依賴、更新方式、腳本內容、網路需求、檔案讀寫範圍和卸載方法。

Plugin 的文件應清楚列出它新增什麼，不要只寫「提升效率」。如果它加入 hook，說明哪個事件會觸發；如果它新增 MCP，列出 server 和工具；如果它修改 memory 或 settings，說明載入順序和覆蓋範圍；如果它可以執行 shell，列出 allowlist、timeout 和輸出。版本更新要可回滾，不能把遠端最新內容默默注入所有專案。

把 plugin 當成軟體依賴治理：pin 版本、檢查 checksum、保留 changelog、在隔離 repo 做 smoke、限制 production scope，並在移除前讀取現況。不要把一個能發布、刪除或傳送資料的 plugin 和一般格式化工具視為同等風險。功能越廣，越需要最小權限和獨立驗證。

工具鏈的正確導入順序

第一步只建立 CLAUDE.md，整理專案地圖、命令、驗收和禁止事項；先用唯讀任務確認 Agent 讀到的規則正確。第二步把重複的流程抽成 Skills，避免主記憶變得太長。第三步加入不涉及外部副作用的 Hooks，例如格式、路徑和測試檢查。第四步才接入 MCP，從唯讀、範圍小的 server 開始，測試工具輸出和權限。

第五步為需要隔離的任務建立 Subagents，明確交接包和 artifact；第六步把已驗證的組件打包成 Plugin，固定版本並在另一個乾淨專案做安裝 smoke。每一層加入後都要重新測量上下文大小、工具數量、延遲、錯誤、成本和使用者理解度。若新增一個工具只讓 Agent 更常選錯，功能增加就是品質退化。

Anthropic 官方 CLI 文件列出 interactive、print、resume、MCP、allowed／disallowed tools、output format、max turns 和 permission mode 等控制面。這些旗標可以協助建立可重現的執行方式，但不能代替專案規則與外部授權；例如 --dangerously-skip-permissions 的存在不代表適合一般自動化。對非互動任務，應固定輸出格式、限制 turns、設定工作目錄、限制工具並保存執行證據。

成本與可觀測性

工具鏈的成本不只包括模型 token。MCP 可能增加網路、資料庫和第三方 API 費用；subagents 增加模型回合；hooks 增加本地或外部檢查時間；plugins 增加更新與安全審查；過大的 CLAUDE.md 可能增加每次 session 的上下文成本。應按任務記錄模型、回合、工具呼叫、輸入輸出大小、hook 時間、MCP 延遲、失敗與重試，才能知道效率提升是否只是把成本移到另一層。

Tracing 或日誌要區分可讀證據與敏感內容。不要把 API key、cookie、完整私人資料或外部服務 response 無限制寫入 log；保存必要的工具名稱、輸入摘要、狀態、外部 ID、artifact hash 和錯誤類型即可。若需追查完整 payload，放在有存取控制和保留期限的受限儲存，並讓 trace 只引用它。

故障排查：先判斷是哪一層出問題

若 Agent 遺漏專案規則，先檢查 CLAUDE.md scope、工作目錄、import 和上下文是否被截斷；不要立刻增加更多 prompt。若 Agent 選錯工具，檢查 Skill 的觸發條件、MCP tool description、permission 和輸入 schema。若工具成功但結果不可信，查外部資料來源、版本、讀回和 verifier；若工具根本沒有被呼叫，查 allowed／disallowed tools、permission mode、hook 和 Agent 的決策。

若整個流程變慢，分開量模型時間、hook 時間、MCP network、subagent 等待和人工 gate。若只有某個 repo 出錯，比較 plugin version、local settings、MCP scope、近端 memory 和目錄規則。若更新後大規模退化，先回滾 plugin 或 skill 版本，再用最小任務找出改變的組件。不要在所有層同時改設定，否則失去因果證據。

Claude Code 工具鏈驗收清單

1. CLAUDE.md 是否只保存穩定、共享、每次任務都需要的專案規則？
2. Skills 是否有明確觸發、輸入、輸出、權限、驗收和失敗處理？
3. Hooks 是否在固定事件做機械檢查，並有 timeout、log、allow／deny 和測試？
4. MCP server 的來源、scope、credentials、資料讀寫與停用方法是否清楚？
5. 外部工具輸出是否被視為資料而非高優先級指令，並經過 schema／安全檢查？
6. Subagents 是否只拿到必要上下文和工具，並以 artifact 與獨立 gate 交接？
7. Plugins 是否固定版本、檢查來源、保留 changelog、可回滾且不默默擴大權限？
8. 非互動執行是否固定 cwd、permission、max turns、output format 和成本上限？
9. 是否能分辨 memory、skill、hook、MCP、subagent 和模型本身的故障？
10. 是否有公開／authenticated read-back 或其他獨立證據，避免只相信 Agent 自己的完成宣告？

來源與分析邊界

本文以Anthropic Claude Code CLI reference 官方文件核對 interactive、print、resume、MCP、tool permission、output format、max turns 與 permission mode；以Anthropic Claude Code memory 官方文件核對專案、使用者與本地記憶的分工；以Anthropic MCP 官方文件核對 MCP 作為 context、資料來源與工具連接協定的定位；並以Anthropic Claude Code LLM gateway 官方文件核對集中認證、usage tracking、成本控制、audit logging 與 model routing 的實務邊界。官方文件說明產品與協定能力，不代表任何 plugin、MCP server 或第三方 gateway 的安全性與可靠性背書。

本文提出的 CLAUDE.md／Skills／Hooks／MCP／Subagents／Plugins 分工、導入順序、artifact 交接、最小權限、版本固定、故障排查與驗收清單，是 YOLO LAB 的工程分析。圖中的中央 Agent、記憶檔、技能模組、MCP 連線、subagents、plugin 箱、權限閘門與驗證面板是概念化原創示意，不是 Anthropic 官方介面、產品截圖、plugin marketplace 或實際 runtime trace。

Claude Code 工具鏈真正成熟的標誌，不是安裝了多少元件，而是每個元件都有清楚責任：規則檔提供穩定上下文，Skill 提供可重用方法，Hook 做固定檢查，MCP 連接受控外部能力，Subagent 縮小任務，Plugin 負責可版本化分發。當新增一層不會掩蓋權限、成本和驗收，當失敗能快速定位並回滾，工具鏈才會從「功能集合」變成可維護的工程系統。

增量：Claude Code 工具鏈的關鍵，是把能力接到正確的責任邊界

Claude Code 的 CLAUDE.md、Skills、Hooks、MCP 與 Subagents，不是五種可以任意堆疊的提示詞。比較穩定的分工是：CLAUDE.md 管專案共識，Skills 管可重用流程，MCP 連接外部資料或工具，Hooks 做事件觸發與檢查，Subagents 承擔可隔離的子任務。

這個分工可以用「誰知道什麼、誰能做什麼、誰負責擋下來」來檢查。知識應放在最靠近使用場景的位置；權限應該比知識更窄；需要外部寫入、刪除或發布時，則必須在流程中留下明確的人工確認點。

Plugin 的價值不只是省掉安裝指令，而是提供可被團隊審查的能力包。官方文件說明了 marketplace discovery 與 plugin reference：Discover plugins、Plugins reference。導入時應先鎖定來源、版本與權限，再把最小可行流程放進 CI 或 review。

一個實用驗收表可以包含四項：新成員能否在十分鐘內理解入口；工具失敗時是否可重試且不重複寫入；Hook 阻擋錯誤時是否給出可修復訊息；Subagent 的輸出是否帶有檔案、測試與未完成事項。工具越多，越需要可追蹤的責任鏈。