Workspace Surface Audit
Inventory what your repo, MCP configs, plugins, and env surfaces can actually do before you add more Claude Code skills, hooks, or connectors.
Overview
Workspace Surface Audit is an agent skill most often used in Build (also Validate, Operate) that inventories repo, MCP, plugin, and env surfaces and recommends ECC-native skills, hooks, and connectors to add next—without
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill workspace-surface-auditWhat is this skill?
- Read-only audit of repo, MCP servers, plugins, connectors, and env without printing secret values
- Recommends highest-value ECC-native skills, hooks, agents, and operator workflows vs generic plugin sprawl
- Benchmarks official marketplace plugins against what the machine can run today
- Decision guide: skill vs hook vs agent vs MCP vs external connector for each gap
- ECC-native alternative to setup-audit plugins; implementation only if the user explicitly asks
Adoption & trust: 3.2k installs on skills.sh; 210k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to pile on plugins and MCP servers without knowing what your repo and harness already expose or what ECC can own instead.
Who is it for?
Solo builders standardizing a Claude Code workspace who want a secret-safe audit before expanding skills, hooks, or MCP coverage.
Skip if: Teams that only need one-off feature code with no agent harness, or users who want the skill to silently rewrite configs without an explicit follow-up request.
When should I use this skill?
User wants help setting up Claude Code, recommends automations, asks what plugins or MCPs to use, or audits machine/repo capabilities before adding skills, hooks, or connectors.
What do I get? / Deliverables
You get a review-first map of available surfaces, missing workflow layers, and concrete ECC-native next steps—then optional implementation only if you ask for it.
- Capability and surface inventory
- Prioritized ECC-native skill/hook/agent/MCP recommendations
- Skill-vs-MCP-vs-connector decision notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the audit targets harness surfaces—MCP, plugins, ECC-native skills—in the active coding workspace. Agent-tooling is where solo builders configure Claude Code capabilities; this skill maps real surfaces to recommended ECC-native additions.
Where it fits
Compare marketplace plugins against ECC coverage before you commit to an MCP and hook stack for a new product.
Review .mcp.json, plugin settings, and connected apps to decide which workflow layer to add as a skill versus an MCP.
Re-audit after env and connector drift to see which automations are redundant or never wired up.
How it compares
Use as a harness readiness checker, not as a generic “install more marketplace plugins” shopping list.
Common Questions / FAQ
Who is workspace-surface-audit for?
Solo and indie builders using Claude Code who need to see what MCP, plugins, connectors, and env files already enable before adding more agent tooling.
When should I use workspace-surface-audit?
During Validate when scoping your agent stack, in Build while configuring agent-tooling, and in Operate when revisiting hooks and connectors after the workspace drifts—especially for “set up Claude Code”, “what am I missing?”, or pre-install audits.
Is workspace-surface-audit safe to install?
The skill is designed read-only and forbids printing secret values; still review the Security Audits panel on this Prism page and your local SKILL.md before granting broad filesystem or env access.
SKILL.md
READMESKILL.md - Workspace Surface Audit
# 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 sec