workspace-surface-audit

name	workspace-surface-audit
description	审计活跃仓库、MCP服务器、插件、连接器、环境表面和工具设置，然后推荐最高价值的ecc原生技能、钩子、代理和操作员工作流。当用户希望帮助设置OpenAI Codex或了解其环境中实际可用的功能时使用。
origin	ecc

工作区表面审计

只读审计技能，用于回答"这个工作区和机器当前实际上能做什么，以及我们下一步应该添加或启用什么？"

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

何时使用

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

不可协商的规则

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

审计输入

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

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

审计流程

阶段 1：盘点现有内容

生成简洁的清单：

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

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

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

阶段 2：与官方和已安装表面进行基准比较

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

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

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

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

阶段 3：将差距转化为 ecc 决策

对于每个实际差距，推荐正确的 ecc 原生形态：

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

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

输出格式

按此顺序返回五个部分：

1. 当前表面
   • 当前已可用的内容
2. 同等能力
   • ecc 已匹配或超越基准的地方
3. 仅有原始形式的差距
   • 工具存在，但 ecc 缺少简洁的操作技能
4. 缺失的集成
   • 尚不可用的能力
5. 前 3-5 个下一步行动
   • 具体的 ecc 原生新增内容，按影响排序

推荐规则

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

良好结果

• 用户可以立即看到已连接的内容、缺失的内容以及 ecc 下一步应拥有的内容。
• 推荐足够具体，无需再次发现即可在仓库中实现。
• 最终答案围绕工作流而非 API 品牌组织。