工作区表面审计
只读审计技能，用于回答"这个工作区和机器当前实际上能做什么，以及我们下一步应该添加或启用什么？"
这是 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 插件
- C…
