Automation Audit Ops

Was macht Automation Audit Ops?

Verwenden Sie dies, wenn der Benutzer fragt, welche Automatisierungen live sind, welche Jobs kaputt sind, wo Überlappungen bestehen oder welche Tools und Connectors derzeit tatsächlich nützliche Arbeit leisten.

Dies ist ein audit-first Operator-Skill. Die Aufgabe besteht darin, ein evidenzbasiertes Inventar und einen Empfehlungssatz für Keep / Merge / Cut / Fix-next zu erstellen, bevor etwas neu geschrieben wird.

Skill-Stack

Ziehen Sie diese ECC-nativen Skills bei Bedarf in den Workflow ein:

• workspace-surface-audit für Connector-, MCP-, Hook- und App-Inventar
• knowledge-ops, wenn das Audit die Live-Repo-Wahrheit mit dauerhaftem Kontext abgleichen muss
• github-ops, wenn die Antwort von CI, geplanten Workflows, Issues oder PR-Automatisierung abhängt
• ecc-tools-cost-audit, wenn das eigentliche Problem Webhook-Fanout, Queue-Jobs oder Abrechnungsverbrauch im zugehörigen App-Repo ist
• research-ops, wenn das lokale Inventar mit der aktuellen Plattformunterstützung oder öffentlicher Dokumentation verglichen werden muss
• verification-loop zum Nachweis des Zustands nach der Fehlerbehebung, anstatt sich auf eine angenommene Wiederherstellung zu verlassen

Verwendung

• Der Benutzer fragt: „Welche Automatisierungen habe ich?“, „Was ist live?“, „Was ist kaputt?“ oder „Was überschneidet sich?“
• Die Aufgabe umfasst Cron-Jobs, GitHub Actions, lokale Hooks, MCP-Server, Connectors, Wrapper oder App-Integrationen
• Der Benutzer möchte wissen, was aus einem anderen Agentensystem portiert wurde und was noch innerhalb von ECC neu aufgebaut werden muss
• Der Workspace hat mehrere Wege angesammelt, um dasselbe zu tun, und der Benutzer möchte einen kanonischen Pfad

Leitplanken

• Beginnen Sie schreibgeschützt, es sei denn, der Benutzer hat explizit nach Korrekturen gefragt
• Trennen Sie:
  • konfiguriert
  • authentifiziert
  • kürzlich verifiziert
  • veraltet oder defekt
  • vollständig fehlend
• Behaupten Sie nicht, dass ein Tool live ist, nur weil ein Skill oder eine Konfiguration darauf verweist
• Führen Sie keine Zusammenführung oder Löschung überlappender Oberflächen durch, bis die Evidenztabelle existiert

Workflow

1. Die tatsächliche Oberfläche inventarisieren

Lesen Sie die aktuelle Live-Oberfläche, bevor Sie Theorien aufstellen:

• Repo-Hooks und lokale Hook-Skripte
• GitHub Actions und geplante Workflows
• MCP-Konfigurationen und aktivierte Server
• Connector- oder App-gestützte Integrationen
• Wrapper-Skripte und repospezifische Automatisierungs-Einstiegspunkte

Gruppieren Sie sie nach Oberfläche:

• lokale Laufzeit
• Repo-CI/Automatisierung
• verbundene externe Systeme
• Messaging/Benachrichtigungen
• Abrechnung/Kundenbetrieb
• Forschung/Überwachung

2. Jedes Element nach Live-Status klassifizieren

Markieren Sie für jede aufgedeckte Automatisierung:

• konfiguriert
• authentifiziert
• kürzlich verifiziert
• veraltet oder defekt
• fehlend

Klassifizieren Sie dann den Problemtyp:

• aktiver Defekt
• Authentifizierungsausfall
• veralteter Status
• Überlappung oder Redundanz
• fehlende Fähigkeit

3. Den Beweispfad zurückverfolgen

Untermauern Sie jede wichtige Behauptung mit einer konkreten Quelle:

• Dateipfad
• Workflow-Lauf
• Hook-Log
• Konfigurationseintrag
• aktuelle Befehlsausgabe
• genaue Fehlersignatur

Wenn der aktuelle Zustand mehrdeutig ist, sagen Sie dies direkt, anstatt so zu tun, als sei das Audit vollständig.

4. Mit Keep / Merge / Cut / Fix-next abschließen

Geben Sie für jede überlappende oder verdächtige Oberfläche einen Aufruf zurück:

• keep
• merge
• cut
• fix next

Der Wert liegt darin, laute Automatisierungen zu einem kanonischen ECC-Pfad zusammenzuführen, nicht darin, jeden historischen Pfad zu erhalten.

Ausgabeformat

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

Fallstricke

• Antworten Sie nicht aus dem Gedächtnis, wenn das Live-Inventar gelesen werden kann
• Behandeln Sie „in der Konfiguration vorhanden“ nicht als „funktionierend“
• Beheben Sie keine niederwertige Redundanz, bevor Sie den defekten hochrangigen Pfad benannt haben
• Weiten Sie die Aufgabe nicht zu einer Repo-Neuschreibung aus, wenn der Benutzer zuerst ein Inventar angefordert hat

Verifikation

• Wichtige Behauptungen verweisen auf einen Live-Beweispfad
• Jede aufgedeckte Automatisierung ist mit einer eindeutigen Live-Status-Kategorie versehen
• Die endgültige Empfehlung unterscheidet Keep / Merge / Cut / Fix-next