/skill

Automation Audit Operations

Original skill by ECC. Credit to ECC for the workflow and core ideas.

Use this skill when a user asks:

• What automation exists?
• What is live now?
• What is broken or stale?
• Which tools do the same job?
• What is missing?
• Which path should become the main ECC path?

Audit first. Do not rewrite files before you know the current state. End with clear proof and a keep, merge, cut, or fix next call.

Related ECC Skills

Use these skills when they fit the task:

• workspace-surface-audit: List connectors, MCP servers, hooks, and apps.
• knowledge-ops: Check saved notes against the current repo.
• github-ops: Check GitHub Actions, timed jobs, issues, and pull request jobs.
• ecc-tools-cost-audit: Check webhooks, queued jobs, repeated work, and costs.
• research-ops: Compare local setup with current public docs.
• verification-loop: Prove that a fix works after it is made.

If a named skill is not present, say so and keep going with local proof.

Use This Skill When

Use it when:

• The task covers cron jobs, GitHub Actions, hooks, MCP servers, connectors, apps, or wrapper scripts.
• A tool was moved from another agent system and may not work in ECC.
• More than one tool seems to do the same job.
• The user wants one main path for a task.
• A config says a tool exists, but no one knows if it still works.

Do not use this skill for a simple code bug that has no automation link.

Safety Rules

• Start in read-only mode.
• Make changes only when the user clearly asks for them.
• Do not run a job that can post, send, bill, deploy, delete, or change outside data without clear approval.
• Do not print keys, tokens, cookies, passwords, or private data.
• Do not call a tool live just to test it if the call may cost money or affect users.
• Do not treat a config entry as proof that a tool works.
• Do not remove or merge tools until the proof table is ready.
• Do not hide gaps. Mark unknown facts as unknown.
• Keep user changes that are not part of the task.

State Labels

Give each item one main state:

• configured: A file or setting names it.
• authenticated: Its login or key is present and valid.
• recently verified: A recent safe test or run proves it works.
• stale: It exists, but its last proof is old.
• broken: There is clear proof of failure.
• missing: The needed tool or step does not exist.
• unknown: There is not enough proof.

Do not mark an item recently verified unless you have a date or fresh test result.

Also give each problem one type:

• active breakage
• auth failure
• stale state
• overlap
• missing feature
• unknown

Workflow

1. Set the Scope

List what the user wants checked.

Note any limits, such as:

• One repo only
• Local tools only
• No live runs
• No outside systems
• No changes

If the scope is not clear, use the smallest safe scope and state it.

2. Find the Real Automation Surface

Read the current files and safe status data before making a claim.

Check items such as:

• Repo hooks and local hook scripts
• Cron, systemd timers, and other timed jobs
• GitHub Actions and scheduled workflows
• MCP config and enabled servers
• Connectors and app links
• Wrapper scripts
• Repo task runners
• Queue workers and webhooks
• Logs, run history, and state files

Group each item by area:

• Local run time
• Repo CI and jobs
• Outside systems
• Messages and alerts
• Billing and customer work
• Research and checks

Watch for hidden paths. A job may start from a shell profile, service file, container, parent repo, or shared config.

3. Build the Proof Table

For every item, record:

Use exact proof when possible:

• File path and line
• Job name and run date
• Log path and time
• Config key name, but never its secret value
• Safe command and short result
• Exact error text
• Process, port, or service state

A file path proves setup. It does not prove a live service.

An old success does not prove the job works now. Mark it stale if the proof is too old for the job rate.

4. Check Each Claim

For each item, ask:

1. Is it set up?
2. Can it sign in?
3. What starts it?
4. Is it running now, if it should be?
5. When did it last succeed?
6. What did that run change?
7. Does another tool do the same job?
8. What breaks if this item is removed?

If a safe check is not possible, say why and mark the state unknown.

5. Find Overlap

Two tools overlap only when they share the same goal, input, output, and users.

Do not call tools duplicates just because their names are close.

For each overlap, compare:

• Owner
• Trigger
• Input
• Output
• Run rate
• Proof of success
• Cost
• Risk
• Needed features

Keep two paths when they serve different needs, such as a manual path and a recovery path.

6. Make One Call Per Item

Choose one action:

• keep: It works and has a clear job.
• merge: Move useful parts into one main path.
• cut: It has no needed use and can be removed safely.
• fix next: It is useful, but broken or not proven.

For merge or cut, name the main path and list what must be saved first.

For fix next, give the first small fix and the proof needed to close it.

7. Verify Any Approved Fix

If the user asks for changes:

1. Make the smallest safe change.
2. Run a safe check.
3. Record the command or run.
4. Record the result and time.
5. Check for new errors.
6. Update the state label.

A clean config check is not enough when the job can be tested safely from end to end.

Output Format

SCOPE
- systems checked
- limits
- audit time

CURRENT SURFACE
| item | area | trigger | state | last proof | proof source | problem |

FINDINGS
- active breakage
- auth failure
- stale state
- overlap
- missing feature
- unknown state

RECOMMENDATIONS
| item | call | reason | risk | next proof |

NEXT ECC MOVE
- exact skill, hook, job, workflow, or app path to improve

Example

User request:

Check our daily report jobs. Tell me which one is live and which one we should keep. Do not change anything.

Example result:

SCOPE
- Checked local cron, GitHub Actions, report scripts, and recent logs.
- Read-only audit.
- Audit time: 2026-05-12 14:00 UTC.

CURRENT SURFACE
| item | area | trigger | state | last proof | proof source | problem |
| daily-report.yml | repo CI | 08:00 UTC schedule | recently verified | 2026-05-12 | GitHub run 1842 | none |
| send_report.sh | local run time | cron at 08:05 | broken | 2026-05-10 | logs/report.log: auth failed | auth failure |
| old_report.py | local run time | no trigger found | stale | 2025-11-03 | file and old log | overlap |

FINDINGS
- The GitHub job is the only path with a recent good run.
- The cron job fails at sign-in.
- The old Python script has no live trigger.
- All three make the same daily report.

RECOMMENDATIONS
| item | call | reason | risk | next proof |
| daily-report.yml | keep | It has a fresh good run | low | Check the next timed run |
| send_report.sh | cut | It repeats the same job and is broken | medium | Save its custom mail text first |
| old_report.py | merge | It has one useful chart not in the main job | low | Add and test the chart in CI |

NEXT ECC MOVE
- Use `github-ops` to add the useful chart to `daily-report.yml`, after approval.

Edge Cases

• If no logs exist, use unknown, not broken.
• If a job is meant to run once a month, a two-week-old success may still be fresh.
• If a service is off by design, do not call it broken.
• If auth is present but cannot be tested safely, mark it authenticated only when there is valid proof.
• If two jobs share code but make different outputs, they may not overlap.
• If a backup path is needed for recovery, mark it as a backup instead of cutting it.
• If a job points to a missing file, mark it broken and cite both paths.
• If local and remote state disagree, report both and mark the live state unknown until checked.
• If proof may hold secret data, cite the file or field name without showing the value.
• If a test may send a message, create a charge, post content, or deploy code, do not run it without approval.
• If the user asks only for an audit, stop after the report.

Final Check

Before you finish, make sure:

• Every found item has one state label.
• Every key claim has a proof source.
• Dates are shown for fresh or stale proof.
• Unknown facts are clear.
• Each item has one action call.
• No files or outside systems were changed without approval.
• The next step names the exact path to improve.