工作區表面審計 是做什麼的？
用於回答「此工作區和機器目前實際上可以做什麼，以及下一步我們應該添加或啟用什麼？」這個問題的唯讀審計技能。
這是 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 表面
- 已經涵蓋該需求的現有技能、命令、鉤子、代理和安裝模組
審計流程
階段一：清點現有項目
產生一份簡潔的清單：
- 活動的 Harness 目標
- 已安裝的插件和已連接的應用
- 已設定的 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 品牌組織。