workspace-surface-audit

affaan-m ｜ 設定與維護 ｜ 原文 ｜ MIT

盤點 repo、MCP、plugin 和環境，推薦下一步該加的 skill 與 hook

---
name: workspace-surface-audit
description: 稽核目前的 repo、MCP server、plugin、connector、環境變數與 harness 設定，然後推薦最有價值的 ECC 原生 skill、hook、agent 和操作流程。使用者想要協助設定 Claude Code，或想了解自己的環境實際上有哪些能力時使用。
metadata:
  origin: ECC
---

# Workspace Surface Audit

唯讀的稽核 skill，用來回答這個問題：「這個 workspace 和這台機器現在實際上能做什麼，接下來該新增或啟用什麼？」

這是 ECC 原生對 setup-audit 類 plugin 的回應。除非使用者明確要求後續實作，否則不會修改任何檔案。

## 何時使用

- 使用者說「幫我設定 Claude Code」、「推薦自動化」、「我該用哪些 plugin 或 MCP？」或「我還缺什麼？」
- 在安裝更多 skill、hook 或 connector 之前，先稽核機器或 repo
- 拿官方 marketplace 的 plugin 跟 ECC 原生的覆蓋範圍做比較
- 檢視 `.env`、`.mcp.json`、plugin 設定或已連接 app 的介面，找出缺少的工作流程層
- 判斷某個能力該做成 skill、hook、agent、MCP，還是外部 connector

## 絕對不能違反的規則

- 絕對不要印出 secret 的值。只列出 provider 名稱、能力名稱、檔案路徑，以及 key 或設定是否存在。
- ECC 有合理能力接手的地方，優先用 ECC 原生流程，不要一直給「再裝一個 plugin」這種通用建議。
- 外部 plugin 只當作基準和靈感來源，不是權威的產品邊界。
- 清楚分成三類：
  - 現在就能用的
  - 能用但 ECC 還沒包裝好的
  - 沒有，需要新整合的

## 稽核輸入

只檢查能把問題回答好所需的檔案和設定：

1. Repo 介面
   - `package.json`、lockfile、語言標記、framework 設定、`README.md`
   - `.mcp.json`、`.lsp.json`、`.claude/settings*.json`、`.codex/*`
   - `AGENTS.md`、`CLAUDE.md`、安裝 manifest、hook 設定
2. 環境介面
   - 目前 repo 以及明顯相鄰的 ECC workspace 裡的 `.env*` 檔案
   - 只列出 key 名稱，例如 `STRIPE_API_KEY`、`TWILIO_AUTH_TOKEN`、`FAL_KEY`
3. 已連接的工具介面
   - 已安裝的 plugin、已啟用的 connector、MCP server、LSP 和 app 整合
4. ECC 介面
   - 已經涵蓋這個需求的現有 skill、command、hook、agent 和安裝模組

## 稽核流程

### 階段 1：盤點現有的東西

產出精簡的清單：

- 啟用中的 harness 目標
- 已安裝的 plugin 和已連接的 app
- 已設定的 MCP server
- 已設定的 LSP server
- 從 key 名稱推得的、靠環境變數運作的服務
- 已經跟這個 workspace 相關的 ECC skill

如果某個介面只有底層原件，要特別指出。例如：

- 「Stripe 可透過已連接的 app 使用，但 ECC 沒有 billing-operator skill」
- 「Google Drive 已連接，但沒有 ECC 原生的 Google Workspace 操作流程」

### 階段 2：對照官方與已安裝的介面做基準比較

把 workspace 拿來跟這些比較：

- 跟 setup、review、docs、design 或工作流程品質有重疊的官方 Claude plugin
- Claude 或 Codex 裡本機已安裝的 plugin
- 使用者目前已連接的 app 介面

不要只列名稱。每個比較都要回答：

1. 它們實際上做什麼
2. ECC 是否已經持平
3. ECC 是否只有底層原件
4. ECC 是否完全缺少這個流程

### 階段 3：把缺口變成 ECC 的決策

對每個真正的缺口，推薦正確的 ECC 原生形式：

| 缺口類型 | 偏好的 ECC 形式 |
|----------|---------------------|
| 可重複的操作流程 | Skill |
| 自動強制執行或副作用 | Hook |
| 專門的委派角色 | Agent |
| 外部工具橋接 | MCP server 或 connector |
| 安裝/啟動引導 | Setup 或 audit skill |

需求偏向操作面而非基礎設施面時，預設做成面向使用者、去編排現有工具的 skill。

## 輸出格式

依以下順序回傳五個段落：

1. **目前的介面**
   - 現在已經能用的東西
2. **持平項目**
   - ECC 已經跟基準相當或更好的地方
3. **只有底層原件的缺口**
   - 工具有了，但 ECC 缺少乾淨的操作 skill
4. **缺少的整合**
   - 還沒有的能力
5. **接下來的前 3-5 步**
   - 具體的 ECC 原生新增項目，依影響力排序

## 推薦規則

- 每個類別最多推薦 1-2 個最有價值的點子。
- 優先選使用者意圖明確、有商業價值的 skill：
  - setup 稽核
  - 帳務/客戶營運
  - issue/專案營運
  - Google Workspace 營運
  - 部署/營運控制
- 如果 connector 是公司專屬的，只有在它確實可用，或明顯對使用者的流程有幫助時才推薦。
- 如果 ECC 已經有很強的底層原件，就提議做一個 wrapper skill，不要硬發明全新的子系統。

## 好的結果

- 使用者能立刻看出什麼已連接、缺什麼、ECC 接下來該接手什麼。
- 推薦夠具體，在 repo 裡不用再做一輪探索就能實作。
- 最終回答是圍繞工作流程組織的，不是圍繞 API 品牌。

---
name: workspace-surface-audit
description: Audit the active repo, MCP servers, plugins, connectors, env surfaces, and harness setup, then recommend the highest-value ECC-native skills, hooks, agents, and operator workflows. Use when the user wants help setting up Claude Code or understanding what capabilities are actually available in their environment.
metadata:
  origin: ECC
---

# Workspace Surface Audit

Read-only audit skill for answering the question "what can this workspace and machine actually do right now, and what should we add or enable next?"

This is the ECC-native answer to setup-audit plugins. It does not modify files unless the user explicitly asks for follow-up implementation.

## When to Use

- User says "set up Claude Code", "recommend automations", "what plugins or MCPs should I use?", or "what am I missing?"
- Auditing a machine or repo before installing more skills, hooks, or connectors
- Comparing official marketplace plugins against ECC-native coverage
- Reviewing `.env`, `.mcp.json`, plugin settings, or connected-app surfaces to find missing workflow layers
- Deciding whether a capability should be a skill, hook, agent, MCP, or external connector

## Non-Negotiable Rules

- Never print secret values. Surface only provider names, capability names, file paths, and whether a key or config exists.
- Prefer ECC-native workflows over generic "install another plugin" advice when ECC can reasonably own the surface.
- Treat external plugins as benchmarks and inspiration, not authoritative product boundaries.
- Separate three things clearly:
  - already available now
  - available but not wrapped well in ECC
  - not available and would require a new integration

## Audit Inputs

Inspect only the files and settings needed to answer the question well:

1. Repo surface
   - `package.json`, lockfiles, language markers, framework config, `README.md`
   - `.mcp.json`, `.lsp.json`, `.claude/settings*.json`, `.codex/*`
   - `AGENTS.md`, `CLAUDE.md`, install manifests, hook configs
2. Environment surface
   - `.env*` files in the active repo and obvious adjacent ECC workspaces
   - Surface only key names such as `STRIPE_API_KEY`, `TWILIO_AUTH_TOKEN`, `FAL_KEY`
3. Connected tool surface
   - Installed plugins, enabled connectors, MCP servers, LSPs, and app integrations
4. ECC surface
   - Existing skills, commands, hooks, agents, and install modules that already cover the need

## Audit Process

### Phase 1: Inventory What Exists

Produce a compact inventory:

- active harness targets
- installed plugins and connected apps
- configured MCP servers
- configured LSP servers
- env-backed services implied by key names
- existing ECC skills already relevant to the workspace

If a surface exists only as a primitive, call that out. Example:

- "Stripe is available via connected app, but ECC lacks a billing-operator skill"
- "Google Drive is connected, but there is no ECC-native Google Workspace operator workflow"

### Phase 2: Benchmark Against Official and Installed Surfaces

Compare the workspace against:

- official Claude plugins that overlap with setup, review, docs, design, or workflow quality
- locally installed plugins in Claude or Codex
- the user's currently connected app surfaces

Do not just list names. For each comparison, answer:

1. what they actually do
2. whether ECC already has parity
3. whether ECC only has primitives
4. whether ECC is missing the workflow entirely

### Phase 3: Turn Gaps Into ECC Decisions

For every real gap, recommend the correct ECC-native shape:

| Gap Type | Preferred ECC Shape |
|----------|---------------------|
| Repeatable operator workflow | Skill |
| Automatic enforcement or side-effect | Hook |
| Specialized delegated role | Agent |
| External tool bridge | MCP server or connector |
| Install/bootstrap guidance | Setup or audit skill |

Default to user-facing skills that orchestrate existing tools when the need is operational rather than infrastructural.

## Output Format

Return five sections in this order:

1. **Current surface**
   - what is already usable right now
2. **Parity**
   - where ECC already matches or exceeds the benchmark
3. **Primitive-only gaps**
   - tools exist, but ECC lacks a clean operator skill
4. **Missing integrations**
   - capability not available yet
5. **Top 3-5 next moves**
   - concrete ECC-native additions, ordered by impact

## Recommendation Rules

- Recommend at most 1-2 highest-value ideas per category.
- Favor skills with obvious user intent and business value:
  - setup audit
  - billing/customer ops
  - issue/program ops
  - Google Workspace ops
  - deployment/ops control
- If a connector is company-specific, recommend it only when it is genuinely available or clearly useful to the user's workflow.
- If ECC already has a strong primitive, propose a wrapper skill instead of inventing a brand-new subsystem.

## Good Outcomes

- The user can immediately see what is connected, what is missing, and what ECC should own next.
- Recommendations are specific enough to implement in the repo without another discovery pass.
- The final answer is organized around workflows, not API brands.