workspace-surface-audit

工作區表面稽核

唯讀稽核技能，用於回答「這個工作區和機器現在實際上能做什麼，以及我們下一步應該添加或啟用什麼？」

這是 ECC 原生對應設定稽核外掛的解答。除非使用者明確要求後續實作，否則不會修改檔案。

使用時機

• 使用者說「設定 Claude Code」、「推薦自動化」、「我該用哪些外掛或 MCP？」或「我缺少什麼？」
• 在安裝更多技能、鉤子或連接器之前稽核機器或儲存庫
• 比較官方市集外掛與 ECC 原生覆蓋範圍
• 檢視 .env、.mcp.json、外掛設定或已連接應用程式表面，找出遺漏的工作流程層
• 決定某個功能應該以技能、鉤子、代理、MCP 或外部連接器的形式存在

不可妥協的規則

• 絕不列印機密值。僅顯示提供者名稱、功能名稱、檔案路徑，以及金鑰或設定是否存在。
• 當 ECC 能合理擁有該表面時，優先選擇 ECC 原生工作流程，而非泛泛的「安裝另一個外掛」建議。
• 將外部外掛視為基準與靈感，而非權威的產品邊界。
• 清楚區分三件事：
  • 目前已可用
  • 可用但 ECC 包裝不佳
  • 不可用且需要新的整合

稽核輸入

僅檢查回答問題所需的檔案與設定：

1. 儲存庫表面
   • package.json、鎖定檔、語言標記、框架設定、README.md
   • .mcp.json、.lsp.json、.claude/settings*.json、.codex/*
   • AGENTS.md、CLAUDE.md、安裝清單、鉤子設定
2. 環境表面
   • 當前儲存庫及明顯相鄰的 ECC 工作區中的 .env* 檔案
   • 僅顯示金鑰名稱，例如 STRIPE_API_KEY、TWILIO_AUTH_TOKEN、FAL_KEY
3. 已連接工具表面
   • 已安裝的外掛、已啟用的連接器、MCP 伺服器、LSP 及應用程式整合
4. ECC 表面
   • 已涵蓋需求的既有技能、指令、鉤子、代理及安裝模組

稽核流程

第一階段：盤點現有項目

產出精簡的盤點清單：

• 活躍的工具鏈目標
• 已安裝的外掛與已連接的應用程式
• 已設定的 MCP 伺服器
• 已設定的 LSP 伺服器
• 由金鑰名稱推斷的環境變數支援服務
• 已與工作區相關的既有 ECC 技能

如果某個表面僅以原始形式存在，請指出。例如：

• 「Stripe 可透過已連接應用程式使用，但 ECC 缺少帳務操作者技能」
• 「Google Drive 已連接，但沒有 ECC 原生的 Google Workspace 操作者工作流程」

第二階段：與官方及已安裝表面進行基準比較

將工作區與以下項目比較：

• 與設定、審查、文件、設計或工作流程品質重疊的官方 Claude 外掛
• 在 Claude 或 Codex 中本地安裝的外掛
• 使用者目前已連接的應用程式表面

不要只列出名稱。對於每個比較，回答：

1. 它們實際做什麼
2. ECC 是否已具有同等功能
3. ECC 是否僅有原始形式
4. ECC 是否完全缺少該工作流程

第三階段：將差距轉化為 ECC 決策

對於每個實際差距，推薦正確的 ECC 原生形式：

差距類型	偏好的 ECC 形式
可重複的操作者工作流程	技能
自動執行或副作用	鉤子
專門委派的角色	代理
外部工具橋接	MCP 伺服器或連接器
安裝/引導指引	設定或稽核技能

當需求是操作層面而非基礎設施層面時，預設使用編排現有工具的使用者面向技能。

輸出格式

依序回傳五個區段：

1. 當前表面
   • 現在已經可用的項目
2. 同等功能
   • ECC 已達到或超越基準的項目
3. 僅有原始形式的差距
   • 工具存在，但 ECC 缺少乾淨的操作者技能
4. 遺漏的整合
   • 尚不可用的功能
5. 前 3-5 個下一步行動
   • 具體的 ECC 原生新增項目，按影響力排序

推薦規則

• 每個類別最多推薦 1-2 個最高價值的想法。
• 偏好具有明確使用者意圖與商業價值的技能：
  • 設定稽核
  • 帳務/客戶營運
  • 問題/專案營運
  • Google Workspace 營運
  • 部署/營運控制
• 如果連接器是公司專用的，僅在確實可用或對使用者工作流程明顯有用時推薦。
• 如果 ECC 已有強大的原始形式，建議包裝成技能，而非發明全新的子系統。

良好成果

• 使用者能立即看到哪些已連接、哪些遺漏，以及 ECC 下一步該擁有什麼。
• 建議具體到可以在儲存庫中實作，無需再次探索。
• 最終答案圍繞工作流程組織，而非 API 品牌。