workspace-surface-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

只读审计技能，用于回答「当前工作区和设备实际能做什么？我们接下来应该添加或启用什么？」这一问题。

这是ECC原生的设置审计插件方案，除非用户明确要求后续落地实现，否则它不会修改任何文件。

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

用户提出「设置Claude Code」、「推荐自动化方案」、「我应该用什么插件或MCP？」或者「我还缺什么能力？」这类需求
在安装更多技能、钩子或连接器前审计设备或仓库情况
对比官方市场插件与ECC原生能力覆盖范围
检查
```
.env
```
、
```
.mcp.json
```
、插件设置或已连接应用层面的配置，查找缺失的工作流层级
确定某项能力应该用技能、钩子、Agent、MCP还是外部连接器实现

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

永远不要输出密钥值，仅展示提供商名称、能力名称、文件路径，以及密钥或配置是否存在
当ECC可以合理覆盖相关能力时，优先推荐ECC原生工作流，而非通用的「安装其他插件」建议
将外部插件视为基准和灵感来源，而非官方的产品能力边界
明确区分三类情况：
- 当前已可用
- 能力存在但未在ECC中完成良好封装
- 能力不存在，需要新增集成

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

仅检查能很好回答问题所需的文件和设置：

仓库层面
- ```
package.json
```
  、依赖锁定文件、语言标识、框架配置、
```
README.md
```
- ```
.mcp.json
```
  、
```
.lsp.json
```
  、
```
.claude/settings*.json
```
  、
```
.codex/*
```
- ```
AGENTS.md
```
  、
```
CLAUDE.md
```
  、安装清单、钩子配置
环境层面
- 活跃仓库和相邻的明显ECC工作区中的
```
.env*
```
  文件
- 仅展示密钥名称，例如
```
STRIPE_API_KEY
```
  、
```
TWILIO_AUTH_TOKEN
```
  、
```
FAL_KEY
```
已连接工具层面
- 已安装的插件、已启用的连接器、MCP服务器、LSP和应用集成
ECC层面
- 已经可以覆盖需求的现有技能、命令、钩子、Agent和安装模块

Audit Process

审计流程

Phase 1: Inventory What Exists

阶段1：清点现有资源

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"

输出一份精简的清单：

活跃的运行框架目标
已安装的插件和已连接的应用
已配置的MCP服务器
已配置的LSP服务器
通过密钥名称推断的环境支持的服务
已经和当前工作区相关的现有ECC技能

如果某类能力仅以基础原语形式存在，需要明确说明。示例：

「Stripe已通过连接应用接入，但ECC缺少账单操作员技能」
「Google Drive已连接，但不存在ECC原生的Google Workspace操作员工作流」

Phase 2: Benchmark Against Official and Installed Surfaces

阶段2：与官方及已安装的能力做基准对比

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

将当前工作区与以下对象做对比：

和设置、审核、文档、设计或工作流质量相关的官方Claude插件
Claude或Codex中本地安装的插件
用户当前已连接的应用能力

不要只罗列名称，针对每一项对比要回答：

它实际的作用是什么
ECC是否已经具备对等能力
ECC是否仅具备基础原语
ECC是否完全缺失该工作流

Phase 3: Turn Gaps Into ECC Decisions

阶段3：将缺口转化为ECC方案决策

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.

针对每一个真实存在的能力缺口，推荐正确的ECC原生实现形态：

缺口类型	推荐的ECC原生形态
可重复的操作员工作流	Skill
自动执行规则或副作用操作	Hook
专属委派角色	Agent
外部工具桥接	MCP server 或 connector
安装/启动引导	Setup 或 audit skill

当需求属于业务操作层面而非基础设施层面时，默认优先选择可以编排现有工具的用户侧技能。

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

按以下顺序返回五个部分：

当前可用能力
- 现在已经可以直接使用的能力
功能对等情况
- ECC已经匹配甚至超过基准能力的部分
仅缺封装的能力缺口
- 基础工具存在，但ECC缺少完善的操作员技能的部分
缺失的集成能力
- 目前完全不具备的能力
优先级前3-5的下一步动作
- 按影响排序的具体ECC原生能力补充建议

Recommendation Rules

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.

用户可以立刻看到哪些能力已接入、哪些能力缺失、ECC接下来应该覆盖哪些能力
推荐方案足够具体，不需要额外的调研就可以在仓库中落地
最终的答案围绕工作流组织，而非按API品牌组织