workspace-surface-audit

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:

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

Weekly Installs537Repositoryaffaan-m/everyt…ude-codeGitHub Stars152.8KFirst Seen12 days agoSecurity AuditsGen Agent Trust HubWarnSocketPassSnykPassInstalled oncodex499opencode475gemini-cli470cursor470antigravity470cline469