工作区表面审计¶

只读审计技能。用于回答“此工作区与机器当前实际上能做什么？接下来应添加或启用什么？”这一问题。

这是ECC针对设置审计插件的原生回应。除非用户明确要求后续实现，否则不修改任何文件。

使用场景¶

• 用户说“设置Claude Code”、“推荐自动化”、“应该使用哪个插件或MCP？”或“缺了什么？”
• 在进一步安装技能、钩子、连接器之前，先审计机器或仓库
• 对比官方市场插件与ECC原生的覆盖范围
• 为了发现工作流层的缺失，审查 .env、.mcp.json、插件设置或已连接应用的表面
• 判断功能应属于技能、钩子、智能体、MCP还是外部连接器

不可协商的规则¶

• 绝不打印机密值。仅显示提供商名称、功能名称、文件路径、密钥或设置是否存在。
• 如果ECC能够合理地拥有该表面，则优先推荐ECC原生工作流，而非泛泛的“安装另一个插件”建议。
• 将外部插件视为基线和灵感来源，而非权威的产品边界。

• 明确区分三类情况：

• 当前可用的能力

• 可用但ECC封装不足的能力
• 不可用且需要新集成的能力

审计输入¶

仅检查回答问题时所需的文件与设置：

1. 仓库表面
2. package.json、锁文件、语言标记、框架设置、README.md
3. .mcp.json、.lsp.json、.claude/settings*.json、.codex/*
4. AGENTS.md、CLAUDE.md、安装清单、钩子设置
5. 环境表面
6. 活动仓库及明显相邻的ECC工作区中的 .env* 文件
7. 仅显示密钥名称（如 STRIPE_API_KEY、TWILIO_AUTH_TOKEN、FAL_KEY）
8. 已连接工具表面
9. 已安装的插件、已启用的连接器、MCP服务器、LSP、应用集成
10. ECC表面
11. 覆盖需求的现有技能、命令、钩子、智能体、安装模块

审计流程¶

阶段1：盘点现有内容¶

生成一份简洁的清单：

• 活动工具链的目标
• 已安装的插件与已连接的应用
• 已配置的MCP服务器
• 已配置的LSP服务器
• 通过密钥名称所暗示的基于环境的服务
• 与工作区相关的现有ECC技能

如果某表面仅以原始形式存在，请明确指出。例如：

• “Stripe可通过已连接应用使用，但ECC没有计费操作技能”
• “Google Drive已连接，但ECC没有Google Workspace原生的操作工作流”

阶段2：与官方及已安装表面进行基准对比¶

将工作区与以下内容进行对比：

• 在设置、审查、文档、设计或工作流质量方面存在重叠的官方Claude插件
• 在Claude或Codex中本地安装的插件
• 用户当前已连接应用的表面

不要仅列出名称。针对每次对比回答以下问题：

1. 它们实际做什么
2. ECC是否已经具备同等功能
3. ECC是否仅拥有原始形式
4. ECC是否完全缺少该工作流

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

针对每个实际缺口，推荐适当的ECC原生形式：

如果需求属于操作性而非基础设施性，默认使用编排现有工具的用户向技能。

输出格式¶

按此顺序返回5个部分：

1. 当前表面
2. 当前可用的能力
3. 同等功能
4. ECC达到或超越基线的部分
5. 仅原始形式的缺口
6. 工具已存在，但ECC缺乏简洁的操作技能
7. 缺失的集成
8. 尚不可用的功能
9. 前3-5个后续步骤
10. 按影响度排序的具体ECC原生新增

推荐规则¶

• 每个类别最多推荐1-2个最有价值的想法。
• 优先选择具有明确用户意图和商业价值的技能：
• 设置审计
• 计费/客户运营
• Issue/项目管理运营
• Google Workspace运营
• 部署/运营控制
• 如果连接器是企业特有的，仅在其实际可用或对用户工作流明显有用时才推荐。
• 如果ECC已具备强大的原始形式，应提出封装技能，而非发明全新的子系统。

良好结果¶

• 用户能迅速确认已连接的内容、缺失的内容以及ECC接下来应具备的内容。
• 推荐事项足够具体，可直接在仓库中实施而无需重新摸索。
• 最终回答围绕工作流而非API品牌来组织。