automation-audit-ops

Constraints

• Apply @rules/reports/general.mdc — any report published to an issue tracker follows the assignment language; code identifiers, file paths, workflow names, and command output stay verbatim.
• Apply @rules/compound-engineering/general.mdc — a recurring breakage or a confirmed redundancy is a durable lesson; recommend recording it in the project's own memory, never in this shared package.
• Apply @rules/git/general.mdc — use gh for GitHub Actions run history; if no GitHub tool is available, stop and report that, do not guess run state.
• Read-only skill — never modify, stage, commit, push, run installers, trigger workflows, or change any setting. Reading the working tree, run logs, and config is allowed; mutating anything is not. The only output is the inventory plus the keep/merge/cut/fix report.
• Evidence-first — never claim an automation is live, authenticated, or working just because a config or skill references it. Every claim cites proof: a file path with line, a workflow run id/conclusion, a log line, or the exact command output that produced it.
• Flag ambiguity, do not assume. When proof is missing or contradictory, mark the item UNVERIFIED and state what would confirm it — never upgrade a guess to a fact.
• Do not invent automations. Catalog only surfaces that actually exist in the repo or the configured environment.

Use when

• You are about to add, rewrite, or delete an automation and need to know what already exists and whether it works.
• CI, a hook, an MCP server, or a composer script is suspected broken, stale, or duplicated and you need an evidence-backed verdict before touching it.
• The automation surface has grown organically and you want a keep/merge/cut/fix decision set across the whole repo.

Execution

Number each finding and carry its proof through to the report. Work surface by surface.

1. Enumerate the surfaces. Build the raw catalog from these locations (skip a surface only after confirming it is absent):
   • GitHub Actions — every file in .github/workflows/ (triggers, jobs, steps).
   • Claude Code config & hooks — .claude/settings.json, .claude/settings.local.json, and any hooks blocks within them; project skill rules under .claude/rules/ and rules/.
   • MCP servers — any mcpServers block in .mcp.json, .claude/settings*.json, or other configured JSON.
   • Composer scripts — the scripts map in composer.json (build, check, fix, analyse, skill-check, security-audit, test:coverage, normalize/pint/rector/phpcs entries).
   • Bundled CLI installer — bin/cursor-rules and the install/sync logic it drives.
   • Skills catalog — skills/*/SKILL.md and their bundled scripts/, treated as automations themselves.
   • Scheduler / cron — any cron entry, Laravel scheduler definition, or .claude/scheduled_tasks* lock/registry.
2. Classify live state per item. Assign exactly one state, each backed by proof:
   • LIVE — confirmed running/passing: a recent successful workflow run, a command you executed returning success, or a hook observably firing.
   • CONFIGURED-UNVERIFIED — defined in config but no proof it ran or succeeded (no run history, no log, unconfirmed credential).
   • BROKEN — proof of active failure: failed run conclusion, non-zero command exit, missing referenced file/binary, malformed config.
   • AUTH-OUTAGE — defined and otherwise sound but blocked by a missing/expired token, secret, or MCP auth (cite the missing key, never its value).
   • STALE — references files, scripts, actions, or services that no longer exist, or pinned to a removed version.
   • MISSING — a capability the repo clearly needs (e.g. a quality gate exists in composer check but no workflow enforces it on PRs) with no automation covering it.
3. Trace proof for each claim. For GitHub Actions, read run conclusions via gh run list --workflow <file> / gh run view. For composer scripts, inspect the script body and any binary it calls; only mark LIVE if you ran it read-only or have a CI log proving it passed — never from the script name alone. For hooks/MCP, cite the exact config block and the auth/binary it depends on. Record the proof reference inline with the finding.
4. Detect overlap and redundancy. Cross-map surfaces that do the same work (e.g. a quality check duplicated between a workflow step and a composer script, two workflows triggering on the same event, two skills covering the same task). For each overlap, identify the canonical owner and the duplicate.
5. Classify each finding by problem-type before recommending: active-breakage, auth-outage, redundancy, or missing-capability. This drives the keep/merge/cut/fix decision.
6. Recommend keep / merge / cut / fix per item, justified only by the proof gathered. Never recommend deleting an item marked CONFIGURED-UNVERIFIED — recommend verifying it first.