| name | workspace-surface-audit |
| description | 审计活跃的仓库、MCP 服务器、插件、连接器、环境面和工具设置，然后推荐最高价值的 ECC 原生技能、钩子、智能体和操作者工作流。当用户需要帮助设置 Claude Code 或了解其环境中实际可用的能力时使用。 |
| origin | ECC |
工作区面审计
只读审计技能，用于回答"这个工作区和机器现在实际能做什么，我们接下来应该添加或启用什么？"
这是 ECC 原生的 setup-audit 插件替代方案。除非用户明确要求后续实施，否则不修改文件。
何时使用
- 用户说"设置 Claude Code"、"推荐自动化"、"我应该使用什么插件或 MCP？"或"我缺少什么？"
- 在安装更多技能、钩子或连接器之前审计机器或仓库
- 将官方市场插件与 ECC 原生覆盖进行比较
- 审查
.env、.mcp.json、插件设置或连接的应用面以发现缺失的工作流层
- 决定某项能力应该是技能、钩子、智能体、MCP 还是外部连接器
不可协商的规则
- 绝不打印密钥值。仅暴露提供者名称、能力名称、文件路径以及密钥或配置是否存在。
- 当 ECC 可以合理拥有该面时，优先使用 ECC 原生工作流而非通用的"安装另一个插件"建议。
- 将外部插件视为基准和灵感，而非权威的产品边界。
- 清楚地分离三件事：
- 现在已经可用的
- 可用但 ECC 封装不够好的
- 不可用且需要新集成的
审计输入
仅检查回答问题所需的文件和设置：
- 仓库面
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 面
- 已覆盖需求的现有技能、命令、钩子、智能体和安装模块
审计过程
阶段 1：清点已有内容
生成紧凑的清单：
- 活跃的工具目标
- 已安装的插件和连接的应用
- 已配置的 MCP 服务器
- 已配置的 LSP 服务器
- 由密钥名称暗示的环境支持的服务
- 与工作区相关的现有 ECC 技能
如果某个面仅作为原语存在，指出这一点。示例：
- "Stripe 通过连接的应用可用，但 ECC 缺少 billing-operator 技能"
- "Google Drive 已连接，但没有 ECC 原生的 Google Workspace 操作者工作流"
阶段 2：与官方和已安装面进行基准比较
将工作区与以下内容比较：
- 与设置、审查、文档、设计或工作流质量重叠的官方 Claude 插件
- Claude 或 Codex 中本地安装的插件
- 用户当前连接的应用面
不要只列出名称。对于每个比较，回答：
- 它们实际做什么
- ECC 是否已有同等功能
- ECC 是否只有原语
- ECC 是否完全缺少该工作流
阶段 3：将差距转化为 ECC 决策
对于每个真正的差距，推荐正确的 ECC 原生形态：
| 差距类型 | 首选 ECC 形态 |
|---|
| 可重复的操作者工作流 | 技能 |
| 自动执行或副作用 | 钩子 |
| 专门的委派角色 | 智能体 |
| 外部工具桥接 | MCP 服务器或连接器 |
| 安装/引导指导 | 设置或审计技能 |
当需求是操作性的而非基础设施时，默认使用编排现有工具的面向用户的技能。
输出格式
按此顺序返回五个部分：
- 当前面
- 同等功能
- 仅原语差距
- 缺失的集成
- 前 3-5 个下一步行动
推荐规则
- 每个类别最多推荐 1-2 个最高价值的想法。
- 优先具有明显用户意图和商业价值的技能：
- 设置审计
- 计费/客户运营
- 问题/项目运营
- Google Workspace 运营
- 部署/运维控制
- 如果连接器是公司特定的，仅当它真正可用或明显对用户工作流有用时才推荐。
- 如果 ECC 已有强大的原语，提出包装技能而非发明全新的子系统。
良好结果
- 用户可以立即看到什么已连接、什么缺失以及 ECC 接下来应该拥有什么。
- 推荐足够具体，可以在仓库中实施而无需另一次发现过程。
- 最终答案围绕工作流组织，而非 API 品牌。
