Workspace Surface Audit

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

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

• 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

• "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

• 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

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

Output Format

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.