工作区表面审计 是做什么的？
一个只读审计技能，用于回答“此工作区和机器目前实际上能做什么，以及下一步应添加或启用什么？”的问题。
这是 ECC 原生对标设置审计插件的方案。除非用户明确要求后续实现，否则它不会修改文件。
何时使用
- 用户说“设置 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
- 活动仓库及相关 ECC 工作区中的
- 连接工具表面
- 已安装的插件、已启用的连接器、MCP 服务器、LSP 和应用集成
- ECC 表面
- 已覆盖需求的现有技能、命令、钩子、代理和安装模块
审计过程
阶段 1：清点现有资源
生成简洁的清点清单：
- 活动的工具集目标
- 已安装的插件和已连接的应用
- 已配置的 MCP 服务器
- 已配置的 LSP 服务器
- 环境变量密钥名称暗示的服务
- 已与工作区相关的现有 ECC 技能
如果某个表面仅以原语形式存在，请明确指出。示例：
- “Stripe 可通过已连接的应用使用，但 ECC 缺少计费操作技能”
- “Google Drive 已连接，但没有 ECC 原生的 Google Workspace 操作员工作流”
阶段 2：与官方和已安装的表面进行基准比较
将工作区与以下内容进行比较：
- 与设置、审查、文档、设计或工作流质量重叠的官方 Claude 插件
- Claude 或 Codex 中本地安装的插件
- 用户当前连接的应用表面
不要仅列出名称。对每个比较，回答以下问题：
- 它们实际上做什么
- ECC 是否已有对等功能
- ECC 是否仅有原语
- ECC 是否完全缺少该工作流
阶段 3：将差距转化为 ECC 决策
针对每个实际差距，推荐正确的 ECC 原生形态：
| 差距类型 | 首选 ECC 形态 |
|---|---|
| 重复性操作员工作流 | 技能 |
| 自动执行或副作用 | 钩子 |
| 专门的委派角色 | 代理 |
| 外部工具桥接 | MCP 服务器或连接器 |
| 安装/引导指南 | 设置或审计技能 |
当需求是操作性的而非基础设施性的时，默认推荐面向用户的技能来编排现有工具。
输出格式
按顺序返回五个部分：
- 当前表面
- 当前已可直接使用的内容
- 对等性
- ECC 已匹配或超过基准的方面
- 仅原型差距
- 工具存在，但 ECC 缺少整洁的操作员技能
- 缺失集成
- 能力尚不可用
- 接下来的 3-5 步行动
- 具体的 ECC 原生新增项，按影响排序
推荐规则
- 每个类别最多推荐 1-2 个最高价值的想法。
- 优先选择具有明确用户意图和业务价值的技能：
- 设置审计
- 账单/客户运营
- 问题/项目运营
- Google Workspace 运营
- 部署/运营控制
- 如果连接器是公司特定的，仅在其确实可用或对用户工作流有明显帮助时才推荐。
- 如果 ECC 已有强大的原语，建议创建包装技能而不是发明全新的子系统。
良好结果
- 用户可以立即看到已连接的内容、缺失的内容以及 ECC 下一步应拥有的内容。
- 推荐足够具体，无需再次发现即可在仓库中实现。
- 最终答案围绕工作流组织，而非 API 品牌。