Back to Details

automation-audit-ops

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Automation Audit Ops

自动化审计运维

Use this when the user asks what automations are live, which jobs are broken, where overlap exists, or what tooling and connectors are actually doing useful work right now.
This is an audit-first operator skill. The job is to produce an evidence-backed inventory and a keep / merge / cut / fix-next recommendation set before rewriting anything.
当用户询问哪些自动化正在运行、哪些jobs发生故障、哪里存在重叠，或者当前有哪些工具和connectors实际在产生有效价值时使用本工作流。
这是一项审计优先的操作员技能，核心任务是在重写任何内容之前，生成有证据支撑的清单，以及保留/合并/裁剪/优先修复的建议集合。

Skill Stack

技能栈

Pull these ECC-native skills into the workflow when relevant:
  • workspace-surface-audit
    for connector, MCP, hook, and app inventory
  • knowledge-ops
    when the audit needs to reconcile live repo truth with durable context
  • github-ops
    when the answer depends on CI, scheduled workflows, issues, or PR automation
  • ecc-tools-cost-audit
    when the real problem is webhook fanout, queued jobs, or billing burn in the sibling app repo
  • research-ops
    when local inventory must be compared against current platform support or public docs
  • verification-loop
    for proving post-fix state instead of relying on assumed recovery
相关情况下可将以下ECC原生技能引入工作流：
  • workspace-surface-audit
    用于获取connector、MCP、hook和应用清单
  • knowledge-ops
    当审计需要将代码仓库实时数据与持久上下文进行对账时使用
  • github-ops
    当查询结果依赖CI、定时工作流、issues或PR自动化时使用
  • ecc-tools-cost-audit
    当核心问题是webhook扇出、排队jobs或关联应用仓库的账单消耗时使用
  • research-ops
    当需要将本地清单与当前平台支持能力或公开文档进行比对时使用
  • verification-loop
    用于验证修复后的状态，而非依赖假设的恢复结果

When to Use

适用场景

  • user asks "what automations do I have", "what is live", "what is broken", or "what overlaps"
  • the task spans cron jobs, GitHub Actions, local hooks, MCP servers, connectors, wrappers, or app integrations
  • the user wants to know what was ported from another agent system and what still needs to be rebuilt inside ECC
  • the workspace has accumulated multiple ways to do the same thing and the user wants one canonical lane
  • 用户询问「我有哪些自动化」、「哪些正在运行」、「哪些发生故障」或者「哪些存在重叠」
  • 任务覆盖cron jobs、GitHub Actions、本地hooks、MCP servers、connectors、wrappers或应用集成
  • 用户想要了解哪些内容是从其他Agent系统迁移而来，哪些仍需要在ECC内重建
  • 工作空间已经积累了多种实现同一功能的方案，用户想要得到一条标准执行路径

Guardrails

边界规则

  • start read-only unless the user explicitly asked for fixes
  • separate:
    • configured
    • authenticated
    • recently verified
    • stale or broken
    • missing entirely
  • do not claim a tool is live just because a skill or config references it
  • do not merge or delete overlapping surfaces until the evidence table exists
  • 除非用户明确要求修复，否则以只读模式启动
  • 对以下状态进行区分：
    • 已配置
    • 已认证
    • 近期验证过
    • 过时或故障
    • 完全缺失
  • 不要仅因为某个技能或配置引用了工具，就宣称该工具正在运行
  • 在证据表生成之前，不要合并或删除存在重叠的接口

Workflow

工作流

1. Inventory the real surface

1. 盘点真实接口

Read the current live surface before theorizing:
  • repo hooks and local hook scripts
  • GitHub Actions and scheduled workflows
  • MCP configs and enabled servers
  • connector- or app-backed integrations
  • wrapper scripts and repo-specific automation entrypoints
Group them by surface:
  • local runtime
  • repo CI / automation
  • connected external systems
  • messaging / notifications
  • billing / customer operations
  • research / monitoring
在进行理论分析前先读取当前运行的接口：
  • 仓库hooks和本地hook脚本
  • GitHub Actions和定时工作流
  • MCP配置和已启用的servers
  • 基于connector或应用的集成
  • wrapper脚本和仓库专属自动化入口
按接口类型分组：
  • 本地运行时
  • 仓库CI/自动化
  • 已连接的外部系统
  • 消息/通知
  • 账单/客户运营
  • 研究/监控

2. Classify each item by live state

2. 按运行状态对每个条目分类

For every surfaced automation, mark:
  • configured
  • authenticated
  • recently verified
  • stale or broken
  • missing
Then classify the problem type:
  • active breakage
  • auth outage
  • stale status
  • overlap or redundancy
  • missing capability
对每个盘点到的自动化，标记：
  • 已配置
  • 已认证
  • 近期验证过
  • 过时或故障
  • 缺失
然后对问题类型分类：
  • 活跃故障
  • 认证中断
  • 状态过时
  • 重叠或冗余
  • 能力缺失

3. Trace the proof path

3. 追溯证据路径

Back every important claim with a concrete source:
  • file path
  • workflow run
  • hook log
  • config entry
  • recent command output
  • exact failure signature
If the current state is ambiguous, say so directly instead of pretending the audit is complete.
每个重要声明都要有具体来源支撑：
  • 文件路径
  • 工作流运行记录
  • hook日志
  • 配置条目
  • 近期命令输出
  • 明确的故障特征
如果当前状态不明确，直接说明，不要假装审计已经完成。

4. End with keep / merge / cut / fix-next

4. 最终输出保留/合并/裁剪/优先修复建议

For each overlapping or suspect surface, return one call:
  • keep
  • merge
  • cut
  • fix next
The value is in collapsing noisy automation into one canonical ECC lane, not in preserving every historical path.
对每个存在重叠或可疑的接口，给出一项判定：
  • 保留
  • 合并
  • 裁剪
  • 优先修复
核心价值是将混乱的自动化收敛为一条标准的ECC执行路径，而非保留所有历史方案。

Output Format

输出格式

text
CURRENT SURFACE
- automation
- source
- live state
- proof

FINDINGS
- active breakage
- overlap
- stale status
- missing capability

RECOMMENDATION
- keep
- merge
- cut
- fix next

NEXT ECC MOVE
- exact skill / hook / workflow / app lane to strengthen
text
CURRENT SURFACE
- automation
- source
- live state
- proof

FINDINGS
- active breakage
- overlap
- stale status
- missing capability

RECOMMENDATION
- keep
- merge
- cut
- fix next

NEXT ECC MOVE
- exact skill / hook / workflow / app lane to strengthen

Pitfalls

常见误区

  • do not answer from memory when the live inventory can be read
  • do not treat "present in config" as "working"
  • do not fix lower-value redundancy before naming the broken high-signal path
  • do not widen the task into a repo rewrite if the user asked for inventory first
  • 当可以读取实时清单时，不要凭记忆回答
  • 不要将「配置中存在」等同于「正常运行」
  • 在明确高优先级故障路径之前，不要先修复低价值的冗余问题
  • 如果用户首先要求清单，不要将任务扩大为仓库重构

Verification

验证标准

  • important claims cite a live proof path
  • each surfaced automation is labeled with a clear live-state category
  • the final recommendation distinguishes keep / merge / cut / fix-next
  • 重要声明都引用了实时证据路径
  • 每个盘点到的自动化都标记了清晰的运行状态分类
  • 最终建议明确区分了保留/合并/裁剪/优先修复