工作区表面审计

工作区表面审计 是做什么的？

只读审计技能，用于回答“此工作区和机器当前实际能做什么，接下来应该添加或启用什么？”

这是ECC原生方案，用于替代设置-审计插件。它不会修改文件，除非用户明确要求进行后续实现。

何时使用

• 用户说“设置Claude Code”、“推荐自动化”、“我应该使用哪些插件或MCP？”或“我缺少什么？”
• 在安装更多技能、钩子或连接器之前审计机器或仓库
• 比较官方市场插件与ECC原生覆盖率
• 检查.env、.mcp.json、插件设置或已连接应用表面，以发现缺失的工作流层
• 决定一项能力应该是技能、钩子、代理、MCP还是外部连接器

不可协商规则

• 绝不打印秘密值。只公开提供者名称、能力名称、文件路径以及键或配置是否存在。
• 当ECC能合理拥有该表面时，优先使用ECC原生工作流，而非通用的“安装另一个插件”建议。
• 将外部插件视为基准和灵感，而非权威的产品边界。
• 清晰区分三件事：
  • 当前已可用的内容
  • 可用但ECC封装不佳的内容
  • 不可用且需要新集成的内容

审计输入

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

1. 仓库表面
   • package.json、锁定文件、语言标记、框架配置、README.md
   • .mcp.json、.lsp.json、.claude/settings*.json、.codex/*
   • AGENTS.md、CLAUDE.md、安装清单、钩子配置
2. 环境表面
   • 活动仓库及明显相邻ECC工作区中的.env*文件
   • 仅暴露键名，例如STRIPE_API_KEY、TWILIO_AUTH_TOKEN、FAL_KEY
3. 已连接工具表面
   • 已安装的插件、已启用的连接器、MCP服务器、LSP和应用程序集成
4. ECC表面
   • 已经涵盖需求的现有技能、命令、钩子、代理和安装模块

审计过程

第一阶段：盘点已有内容

生成一份简洁的清单：

• 活动的工具集目标
• 已安装的插件和已连接的应用
• 已配置的MCP服务器
• 已配置的LSP服务器
• 键名暗示的环境变量支持的服务
• 与工作区相关的现有ECC技能

如果一个表面仅以原始形式存在，请指出。示例：

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

第二阶段：对照官方和已安装的表面进行基准测试

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

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

不要仅列出名称。对于每次比较，回答：

1. 它们实际做什么
2. ECC是否已有对等能力
3. ECC是否仅有原始工具
4. ECC是否完全缺少该工作流

第三阶段：将差距转化为ECC决策

针对每个实际差距，推荐正确的ECC原生形式：

差距类型	首选ECC形式
可重复的操作工作流	技能
自动执行或副作用	钩子
专门的委派角色	代理
外部工具桥接	MCP服务器或连接器
安装/引导指导	设置或审计技能

当需求是操作性的而非基础设施性的时，默认选择面向用户的技能，这些技能编排现有工具。

输出格式

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

1. 当前表面
   • 哪些内容当前立即可用
2. 奇偶性
   • ECC在哪些方面已达到或超过基准
3. 原始差距
   • 工具存在，但ECC缺乏清晰的操作技能
4. 缺失的集成
   • 能力尚不可用
5. 前3-5个下一步行动
   • 具体的ECC原生新增内容，按影响排序

推荐规则

• 每个类别最多推荐1-2个最高价值的想法。
• 偏爱具有明确用户意图和业务价值的技能：
  • 设置审计
  • 计费/客户操作
  • 问题/计划操作
  • Google Workspace操作
  • 部署/操作控制
• 如果连接器是公司特定的，仅在其确实可用或明显对用户工作流有用时才推荐。
• 如果ECC已有强大的原始工具，建议包装技能，而不是发明全新的子系统。

良好结果

• 用户可以立即看到哪些已连接、哪些缺少以及ECC下一步应拥有什么。
• 建议足够具体，无需另一次发现即可在仓库中实现。
• 最终答案围绕工作流组织，而非API品牌。