工作區表面審計 是做什麼的？
唯讀審計技能，用於回答「這個工作區和機器目前實際上能做些什麼，以及我們接下來應該添加或啟用什麼？」
這是 ECC 原生對應設定審計插件的方案。除非使用者明確要求後續實作，否則不會修改檔案。
使用時機
- 使用者說「設定 Claude Code」、「推薦自動化」、「我應該使用哪些插件或 MCP？」或「我缺少了什麼？」
- 在安裝更多技能、掛鉤或連接器之前審計機器或儲存庫
- 比較官方市集插件與 ECC 原生覆蓋範圍
- 審查
.env、.mcp.json、插件設定或已連接應用表面，以找出缺失的工作流程層 - 決定某項功能應該以技能、掛鉤、代理、MCP 還是外部連接器實現
不可協商的規則
- 絕不印出機密值。僅顯示提供者名稱、功能名稱、檔案路徑，以及金鑰或組態是否存在。
- 當 ECC 合理擁有該表面時，優先採用 ECC 原生工作流程，而非泛泛的「安裝另一個插件」建議。
- 將外部插件視為基準與靈感，而非權威的產品邊界。
- 清楚區分三件事：
- 目前已經可用的
- 可用但 ECC 包裝不佳的
- 不可用且需要新建整合的
審計輸入
僅檢查回答問題所需的檔案與設定：
- 儲存庫表面
package.json、鎖定檔、語言標記、框架設定、README.md.mcp.json、.lsp.json、.claude/settings*.json、.codex/*AGENTS.md、CLAUDE.md、安裝清單、掛鉤設定
- 環境表面
- 活躍儲存庫及明顯相鄰 ECC 工作區中的
.env*檔案 - 僅顯示金鑰名稱，例如
STRIPE_API_KEY、TWILIO_AUTH_TOKEN、FAL_KEY
- 活躍儲存庫及明顯相鄰 ECC 工作區中的
- 連接工具表面
- 已安裝的插件、已啟用的連接器、MCP 伺服器、LSP 與應用整合
- ECC 表面
- 已涵蓋需求的現有技能、指令、掛鉤、代理與安裝模組
審計流程
第一階段：盤點既存資源
產生一份精簡盤點：
- 活躍工具鏈目標
- 已安裝的插件與已連接的應用
- 已設定的 MCP 伺服器
- 已設定的 LSP 伺服器
- 由金鑰名稱推斷的環境後端服務
- 工作區中已有的相關 ECC 技能
如果某表面僅以基本元素存在，請指出。範例：
- 「Stripe 可透過已連接應用使用，但 ECC 缺少計費操作者技能」
- 「Google Drive 已連接，但沒有 ECC 原生的 Google Workspace 操作者工作流程」
第二階段：對比官方與已安裝表面
將工作區與以下項目進行比較：
- 在設定、審查、文件、設計或工作流程品質方面有重疊的官方 Claude 插件
- Claude 或 Codex 中本地安裝的插件
- 使用者目前連接的應用表面
不要只列出名稱。針對每項比較，回答：
- 它們實際上做了什麼
- ECC 是否已經具有對等性
- ECC 是否只有基本元素
- ECC 是否完全缺少該工作流程
第三階段：將缺口轉化為 ECC 決策
針對每個實際缺口，推薦正確的 ECC 原生型態：
| 缺口類型 | 偏好的 ECC 型態 |
|---|---|
| 可重複的操作者工作流程 | 技能 |
| 自動強制執行或副作用 | 掛鉤 |
| 專門的委派角色 | 代理 |
| 外部工具橋接 | MCP 伺服器或連接器 |
| 安裝/引導指南 | 設定或審計技能 |
當需求是操作性的而非基礎設施層面時，預設採用編排現有工具的使用者面向技能。
輸出格式
按以下順序返回五個區段：
- 當前表面
- 目前立即可用的項目
- 對等性
- ECC 已經匹配或超越基準的地方
- 僅有基本元素的缺口
- 工具存在，但 ECC 缺少乾淨的操作者技能
- 缺失的整合
- 尚不可用的功能
- 前 3-5 個下一步行動
- 具體的 ECC 原生新增項目，按影響力排序
推薦規則
- 每個類別最多推薦 1-2 個最高價值點子。
- 傾向於具有明顯使用者意圖與商業價值的技能：
- 設定審計
- 計費/客戶營運
- 問題/專案營運
- Google Workspace 營運
- 部署/營運控制
- 如果連接器是公司專用的，僅在它確實可用或對使用者工作流程明顯有幫助時推薦。
- 如果 ECC 已有強大的基本元素，建議建立封裝技能，而非發明全新的子系統。
良好結果
- 使用者可以立即看到哪些已連接、哪些缺失，以及 ECC 接下來應擁有什麼。
- 推薦內容足夠具體，無需另一次探索即可在儲存庫中實作。
- 最終答案圍繞工作流程組織，而非 API 品牌。