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:
- 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
- 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
- Connected tool surface
- Installed plugins, enabled connectors, MCP servers, LSPs, and app integrations
- 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:
- what they actually do
- whether ECC already has parity
- whether ECC only has primitives
- 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:
- Current surface
- what is already usable right now
- Parity
- where ECC already matches or exceeds the benchmark
- Primitive-only gaps
- tools exist, but ECC lacks a clean operator skill
- Missing integrations
- capability not available yet
- 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.
1---2name: ecc-workspace-surface-audit3description: 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.4---56# Workspace Surface Audit78Read-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?"910This is the ECC-native answer to setup-audit plugins. It does not modify files unless the user explicitly asks for follow-up implementation.1112## When to Use1314- User says "set up Claude Code", "recommend automations", "what plugins or MCPs should I use?", or "what am I missing?"15- Auditing a machine or repo before installing more skills, hooks, or connectors16- Comparing official marketplace plugins against ECC-native coverage17- Reviewing `.env`, `.mcp.json`, plugin settings, or connected-app surfaces to find missing workflow layers18- Deciding whether a capability should be a skill, hook, agent, MCP, or external connector1920## Non-Negotiable Rules2122- Never print secret values. Surface only provider names, capability names, file paths, and whether a key or config exists.23- Prefer ECC-native workflows over generic "install another plugin" advice when ECC can reasonably own the surface.24- Treat external plugins as benchmarks and inspiration, not authoritative product boundaries.25- Separate three things clearly:26 - already available now27 - available but not wrapped well in ECC28 - not available and would require a new integration2930## Audit Inputs3132Inspect only the files and settings needed to answer the question well:33341. Repo surface35 - `package.json`, lockfiles, language markers, framework config, `README.md`36 - `.mcp.json`, `.lsp.json`, `.claude/settings*.json`, `.codex/*`37 - `AGENTS.md`, `CLAUDE.md`, install manifests, hook configs382. Environment surface39 - `.env*` files in the active repo and obvious adjacent ECC workspaces40 - Surface only key names such as `STRIPE_API_KEY`, `TWILIO_AUTH_TOKEN`, `FAL_KEY`413. Connected tool surface42 - Installed plugins, enabled connectors, MCP servers, LSPs, and app integrations434. ECC surface44 - Existing skills, commands, hooks, agents, and install modules that already cover the need4546## Audit Process4748### Phase 1: Inventory What Exists4950Produce a compact inventory:5152- active harness targets53- installed plugins and connected apps54- configured MCP servers55- configured LSP servers56- env-backed services implied by key names57- existing ECC skills already relevant to the workspace5859If a surface exists only as a primitive, call that out. Example:6061- "Stripe is available via connected app, but ECC lacks a billing-operator skill"62- "Google Drive is connected, but there is no ECC-native Google Workspace operator workflow"6364### Phase 2: Benchmark Against Official and Installed Surfaces6566Compare the workspace against:6768- official Claude plugins that overlap with setup, review, docs, design, or workflow quality69- locally installed plugins in Claude or Codex70- the user's currently connected app surfaces7172Do not just list names. For each comparison, answer:73741. what they actually do752. whether ECC already has parity763. whether ECC only has primitives774. whether ECC is missing the workflow entirely7879### Phase 3: Turn Gaps Into ECC Decisions8081For every real gap, recommend the correct ECC-native shape:8283| Gap Type | Preferred ECC Shape |84|----------|---------------------|85| Repeatable operator workflow | Skill |86| Automatic enforcement or side-effect | Hook |87| Specialized delegated role | Agent |88| External tool bridge | MCP server or connector |89| Install/bootstrap guidance | Setup or audit skill |9091Default to user-facing skills that orchestrate existing tools when the need is operational rather than infrastructural.9293## Output Format9495Return five sections in this order:96971. **Current surface**98 - what is already usable right now992. **Parity**100 - where ECC already matches or exceeds the benchmark1013. **Primitive-only gaps**102 - tools exist, but ECC lacks a clean operator skill1034. **Missing integrations**104 - capability not available yet1055. **Top 3-5 next moves**106 - concrete ECC-native additions, ordered by impact107108## Recommendation Rules109110- Recommend at most 1-2 highest-value ideas per category.111- Favor skills with obvious user intent and business value:112 - setup audit113 - billing/customer ops114 - issue/program ops115 - Google Workspace ops116 - deployment/ops control117- If a connector is company-specific, recommend it only when it is genuinely available or clearly useful to the user's workflow.118- If ECC already has a strong primitive, propose a wrapper skill instead of inventing a brand-new subsystem.119120## Good Outcomes121122- The user can immediately see what is connected, what is missing, and what ECC should own next.123- Recommendations are specific enough to implement in the repo without another discovery pass.124- The final answer is organized around workflows, not API brands.
undermybelt