workspace-surface-audit

Topics in the source

• Workspace Surface Audit
• When to Use
• Non-Negotiable Rules
• Audit Inputs
• Audit Process
• Phase 1: Inventory What Exists
• Phase 2: Benchmark Against Official and Installed Surfaces
• Phase 3: Turn Gaps Into ECC Decisions

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

This is an excerpt. Refer to the complete source and its current requirements.