| name | automation-audit-ops |
| description | 基于证据的自动化清单和重叠审计工作流，适用于 ECC。在修复任何内容之前，当用户想要了解哪些作业、钩子、连接器、MCP 服务器或封装程序是活跃的、损坏的、冗余的或缺失时使用。 |
| origin | ECC |
自动化审计运维 (Automation Audit Ops)
当用户询问哪些自动化正在运行、哪些作业已损坏、哪里存在重叠，或者当前哪些工具和连接器实际上正在执行有用的工作时，请使用此技能。
这是一个证据优先的审计操作员技能。任务是在重写任何内容之前，生成一份有证据支持的清单以及一组“保留/合并/删除/下一步修复”的建议。
技能栈
在相关时将这些 ECC 原生技能引入工作流：
workspace-surface-audit：用于连接器、MCP、钩子和应用清单knowledge-ops：当审计需要将实时仓库事实与持久上下文协调时github-ops：当答案取决于 CI、定时工作流、问题 (Issues) 或 PR 自动化时ecc-tools-cost-audit：当实际问题是同级应用仓库中的 Webhook 扇出、排队作业或计费支出时research-ops：当需要将本地清单与当前平台支持或公共文档进行比较时verification-loop：用于证明修复后的状态，而不是依赖假设的恢复
何时使用
- 用户询问“我有多少自动化”、“什么是活跃的”、“什么是损坏的”或“哪里有重叠”
- 任务跨越 cron 作业、GitHub Actions、本地钩子、MCP 服务器、连接器、封装程序或应用集成
- 用户想知道哪些是从另一个代理系统迁移过来的，以及哪些仍需在 ECC 内部重建
- 工作区积累了多种执行相同操作的方法，用户希望建立一个规范路径
护栏
- 除非用户明确要求修复，否则从只读开始
- 区分以下状态：
- 已配置 (Configured)
- 已认证 (Authenticated)
- 最近已验证 (Recently verified)
- 陈旧或损坏 (Stale or broken)
- 完全缺失 (Missing entirely)
- 不要仅仅因为某个技能或配置引用了某个工具就声称它是活跃的
- 在证据表存在之前，不要合并或删除重叠的界面
工作流
1. 盘点真实表面
在理论化之前读取当前的实时表面：
- 仓库钩子和本地钩子脚本
- GitHub Actions 和定时工作流
- MCP 配置和已启用的服务器
- 由连接器或应用支持的集成
- 封装脚本和仓库特定的自动化入口点
按表面分组：
- 本地运行时 (Local runtime)
- 仓库 CI / 自动化
- 连接的外部系统
- 消息 / 通知
- 计费 / 客户运营
- 研究 / 监控
2. 按实时状态对每个项目进行分类
对于盘点出的每个自动化，标记：
然后分类问题类型：
- 活跃损坏
- 认证中断
- 陈旧状态
- 重叠或冗余
- 功能缺失
3. 追踪证明路径
用具体的来源支持每一个重要断言：
- 文件路径
- 工作流运行
- 钩子日志
- 配置条目
- 最近的命令输出
- 确切的故障签名
如果当前状态不明确，请直接说明，而不是假装审计已完成。
4. 以“保留/合并/删除/下一步修复”结束
对于每个重叠或可疑的表面，给出一个结论：
- 保留 (Keep)
- 合并 (Merge)
- 删除 (Cut)
- 下一步修复 (Fix next)
其价值在于将嘈杂的自动化压缩到一个规范的 ECC 路径中，而不是保留每一个历史路径。
输出格式
当前表面 (CURRENT SURFACE)
- 自动化项
- 来源
- 实时状态
- 证明
发现 (FINDINGS)
- 活跃损坏
- 重叠
- 陈旧状态
- 功能缺失
建议 (RECOMMENDATION)
- 保留
- 合并
- 删除
- 下一步修复
下一步 ECC 行动 (NEXT ECC MOVE)
- 要强化的确切技能 / 钩子 / 工作流 / 应用路径
陷阱
- 当可以读取实时清单时，不要凭记忆回答
- 不要将“出现在配置中”视为“正在工作”
- 在指明高信号的损坏路径之前，不要修复低价值的冗余
- 如果用户首先要求清单，不要将任务扩大到仓库重写
验证
- 重要断言引用了实时证明路径
- 每个盘点出的自动化都贴有清晰的实时状态标签
- 最终建议明确区分了保留 / 合并 / 删除 / 下一步修复
