workspace-surface-audit

Topics in the source

• 工作区表面审计
• 何时使用
• 不可协商的规则
• 审计输入
• 审计流程
• 阶段 1：盘点现有内容
• 阶段 2：与官方和已安装表面进行基准比较
• 阶段 3：将差距转化为 ECC 决策

只读审计技能，用于回答"这个工作区和机器当前实际上能做什么，以及我们下一步应该添加或启用什么？" 这是 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 文件 仅显示密钥名称，如 STRIPEAPIKEY、TWILIOAUTHTOKEN、FALKEY 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 形态 | |----------|---------------------| | 可重复的操作工作流 | 技能 | | 自动执行或副作

This is an excerpt. Refer to the complete source and its current requirements.