automation-audit-ops
Skill1 starsChanged 7 months agoMITView on GitHub
Evidence-first automation inventory and overlap audit workflow for ECC. Use when the user wants to know which jobs, hooks, connectors, MCP servers, or wrappers are live, broken, redundant, or missing before fixing anything.
8 other projects use a version of this, 4 of them edited.
Adopted by
Most recently taken up by
- pankaj-mahaur/Agent-Daemonedited, first seen Nov 6, 2026
- renepf/claude-skillsedited, first seen Oct 25, 2026
- davidanthonyn/claude-skillsword for word, first seen Oct 20, 2026
- gongyijie85/dsh-eccedited, first seen Oct 13, 2026
- Fmarzochi/EGCedited, first seen Sep 16, 2026
- kuker24/OpenCodeBestFriendtheir own version, first seen Sep 5, 2026
Other versions8 projects use a version of this.
Word for word · 2
- SamuelNDCE/claude-super-skill-library★ 1100% same
- davidanthonyn/claude-skills★ 0100% same
Edited · 4
- Fmarzochi/EGC★ 6194% same
- gongyijie85/dsh-ecc★ 899% same
- pankaj-mahaur/Agent-Daemon★ 099% same
- renepf/claude-skills★ 099% same
Wrote their own version · 2
- pekral/cursor-rules★ 10same name
- kuker24/OpenCodeBestFriend★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository269 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .codex/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- examples/CLAUDE.mdCLAUDE.md
- .cursor/rules/common-agents.mdCursor rule
- .cursor/rules/common-coding-style.mdCursor rule
- .cursor/rules/common-development-workflow.mdCursor rule
- .cursor/rules/common-git-workflow.mdCursor rule
- .cursor/rules/common-hooks.mdCursor rule
- .cursor/rules/common-patterns.mdCursor rule
- .cursor/rules/common-performance.mdCursor rule
- .cursor/rules/common-security.mdCursor rule
- .cursor/rules/common-testing.mdCursor rule
- .cursor/rules/golang-coding-style.mdCursor rule
- .cursor/rules/golang-hooks.mdCursor rule
- .cursor/rules/golang-patterns.mdCursor rule
- .cursor/rules/golang-security.mdCursor rule
- .cursor/rules/golang-testing.mdCursor rule
- .cursor/rules/kotlin-coding-style.mdCursor rule
- .cursor/rules/kotlin-hooks.mdCursor rule
- .cursor/rules/kotlin-patterns.mdCursor rule
- .cursor/rules/kotlin-security.mdCursor rule
- .cursor/rules/kotlin-testing.mdCursor rule
- .cursor/rules/php-coding-style.mdCursor rule
- .cursor/rules/php-hooks.mdCursor rule
- .cursor/rules/php-patterns.mdCursor rule
- .cursor/rules/php-security.mdCursor rule
- .cursor/rules/php-testing.mdCursor rule
- .cursor/rules/python-coding-style.mdCursor rule
- .cursor/rules/python-hooks.mdCursor rule
- .cursor/rules/python-patterns.mdCursor rule
- .cursor/rules/python-security.mdCursor rule
- .cursor/rules/python-testing.mdCursor rule
- .cursor/rules/swift-coding-style.mdCursor rule
- .cursor/rules/swift-hooks.mdCursor rule
- .cursor/rules/swift-patterns.mdCursor rule
- .cursor/rules/swift-security.mdCursor rule
- .cursor/rules/swift-testing.mdCursor rule
- .cursor/rules/typescript-coding-style.mdCursor rule
- .cursor/rules/typescript-hooks.mdCursor rule
- .cursor/rules/typescript-patterns.mdCursor rule
- .cursor/rules/typescript-security.mdCursor rule
- .cursor/rules/typescript-testing.mdCursor rule
- agent-introspection-debuggingSkill
- agent-sortSkill
- api-designSkill
- article-writingSkill
- backend-patternsSkill
- brand-voiceSkill
- bun-runtimeSkill
- claude-apiSkill
- coding-standardsSkill
- content-engineSkill
- crosspostSkill
- deep-researchSkill
- dmux-workflowsSkill
- documentation-lookupSkill
- e2e-testingSkill
- eval-harnessSkill
- everything-claude-code-conventionsSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
10 rules. 10 are common, 0 are distinctive, and 0 are very specific to this project.
10
Common
Most of the 6 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Common: line 9
Use this when the user asks what automations are live, which jobs are broken, where overlap exists, or what tooling and connectors are …
- Common: line 33
start read-only unless the user explicitly asked for fixes
- Common: line 40
do not claim a tool is live just because a skill or config references it
- Common: line 41
do not merge or delete overlapping surfaces until the evidence table exists
- Common: line 47
Read the current live surface before theorizing:
- Common: line 93
If the current state is ambiguous, say so directly instead of pretending the audit is complete.
- Common: line 133
do not answer from memory when the live inventory can be read
- Common: line 134
do not treat "present in config" as "working"
- Common: line 135
do not fix lower-value redundancy before naming the broken high-signal path
- Common: line 136
do not widen the task into a repo rewrite if the user asked for inventory first
“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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.
Skill Stack
Pull these ECC-native skills into the workflow when relevant:
workspace-surface-auditfor connector, MCP, hook, and app inventoryknowledge-opswhen the audit needs to reconcile live repo truth with durable contextgithub-opswhen the answer depends on CI, scheduled workflows, issues, or PR automationecc-tools-cost-auditwhen the real problem is webhook fanout, queued jobs, or billing burn in the sibling app reporesearch-opswhen local inventory must be compared against current platform support or public docsverification-loopfor proving post-fix state instead of relying on assumed recovery
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
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
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
2. Classify each item by live state
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
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.
4. End with keep / merge / cut / fix-next
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.
Output Format
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 strengthenPitfalls
- 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
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

