| name | automation-audit-ops |
| description | ECC 的证据优先自动化清单和重叠审计工作流。当用户想要在修复任何内容之前知道哪些作业、钩子、连接器、MCP 服务器或包装器是活动的、损坏的、冗余的或缺失时使用。 |
| origin | ECC |
自动化审计运营
当用户询问有哪些自动化是活动的、哪些作业是损坏的、哪里存在重叠，或者哪些工具和连接器实际上正在做有用工作时使用此技能。
这是一个审计优先的运营商技能。工作是在重写任何内容之前生成基于证据的清单和保留/合并/删除/下一步修复建议集。
技能栈
在相关时将以下 ECC 原生技能拉入工作流：
workspace-surface-audit 用于连接器、MCP、钩子和应用程序清单knowledge-ops 当审计需要调和实时仓库真实性与持久上下文时github-ops 当答案取决于 CI、预定工作流、问题或 PR 自动化时ecc-tools-cost-audit 当真正的问题是 webhook 扇出、排队作业或同级应用仓库中的计费消耗时research-ops 当本地清单必须与当前平台支持或公共文档进行比较时verification-loop 用于证明修复后状态，而不是依赖假设的恢复
何时使用
- 用户问"我有什么自动化"、"什么是活动的"、"什么是损坏的"或"什么重叠"
- 任务跨越 cron 作业、GitHub Actions、本地钩子、MCP 服务器、连接器、包装器或应用程序集成
- 用户想知道从另一个代理系统移植了什么，以及仍需要在 ECC 内重建什么
- 工作空间已累积多种做同样事情的方式，用户想要一条规范通道
防护规则
- 除非用户明确要求修复，否则以只读开始
- 分离：
- 不要仅仅因为技能或配置引用了工具就声称该工具是活动的
- 在证据表存在之前不要合并或删除重叠的表面
工作流
1. 清单实际表面
在理论化之前读取当前的活动表面：
- 仓库钩子和本地钩子脚本
- GitHub Actions 和预定工作流
- MCP 配置和启用的服务器
- 连接器或应用程序支持的集成
- 包装器脚本和仓库特定的自动化入口点
按表面分组：
- 本地运行时
- 仓库 CI / 自动化
- 连接的外部系统
- 消息传递 / 通知
- 计费 / 客户运营
- 研究 / 监控
2. 按活动状态分类每个项目
对于每个 surfaced 的自动化，标记：
然后分类问题类型：
- 活动中断
- 认证中断
- 陈旧状态
- 重叠或冗余
- 缺失功能
3. 追踪证明路径
用具体来源支持每个重要声明：
- 文件路径
- 工作流运行
- 钩子日志
- 配置条目
- 最近的命令输出
- 确切的失败签名
如果当前状态模糊，直接说明而不是假装审计完整。
4. 以保留/合并/删除/下一步修复结束
对于每个重叠或有问题的表面，返回一个调用：
价值在于将嘈杂的自动化折叠为一条规范的 ECC 通道，而不是保留每个历史路径。
输出格式
当前表面
- 自动化
- 来源
- 活动状态
- 证明
发现
- 活动中断
- 重叠
- 陈旧状态
- 缺失功能
建议
- 保留
- 合并
- 删除
- 下一步修复
下一个 ECC 行动
- 要加强的确切技能 / 钩子 / 工作流 / 应用通道
陷阱
- 当可以读取实时清单时，不要从内存中回答
- 不要将"存在于配置中"视为"工作"
- 在命名损坏的高信号路径之前不要修复较低价值的冗余
- 如果用户首先要求清单，不要将任务扩大到仓库重写
验证
- 重要声明引用实时证明路径
- 每个 surfaced 的自动化都标有清晰的活动状态类别
- 最终建议区分保留/合并/删除/下一步修复
