Automation Audit Ops

Que fait Automation Audit Ops ?

Utilisez ceci lorsque l'utilisateur demande quelles automatisations sont actives, quels jobs sont cassés, où se trouvent les chevauchements, ou quels outils et connecteurs effectuent actuellement un travail utile.

Il s'agit d'un skill de type audit-first. Le travail consiste à produire un inventaire basé sur des preuves et un ensemble de recommandations (keep / merge / cut / fix-next) avant toute réécriture.

Stack de compétences

Intégrez ces skills natifs ECC dans le workflow si nécessaire :

• workspace-surface-audit pour l'inventaire des connecteurs, MCP, hooks et applications
• knowledge-ops lorsque l'audit doit concilier la vérité du dépôt en direct avec le contexte durable
• github-ops lorsque la réponse dépend de l'CI, des workflows planifiés, des issues ou de l'automatisation des PR
• ecc-tools-cost-audit lorsque le vrai problème est le fanout des webhooks, les jobs en file d'attente ou la consommation de facturation dans le dépôt d'application sœur
• research-ops lorsque l'inventaire local doit être comparé au support actuel de la plateforme ou à la documentation publique
• verification-loop pour prouver l'état après correction au lieu de se fier à une récupération supposée

Quand l'utiliser

• l'utilisateur demande "quelles automatisations j'ai", "qu'est-ce qui est actif", "qu'est-ce qui est cassé" ou "qu'est-ce qui se chevauche"
• la tâche couvre les tâches cron, les actions GitHub, les hooks locaux, les serveurs MCP, les connecteurs, les wrappers ou les intégrations d'applications
• l'utilisateur veut savoir ce qui a été porté depuis un autre système d'agent et ce qui doit encore être reconstruit dans ECC
• l'espace de travail a accumulé plusieurs façons de faire la même chose et l'utilisateur veut une seule voie canonique

Garde-fous

• commencez en lecture seule sauf si l'utilisateur a explicitement demandé des corrections
• séparez :
  • configuré
  • authentifié
  • récemment vérifié
  • obsolète ou cassé
  • manquant totalement
• ne prétendez pas qu'un outil est actif simplement parce qu'un skill ou une configuration le référence
• ne fusionnez pas et ne supprimez pas de surfaces qui se chevauchent tant que le tableau des preuves n'existe pas

Workflow

1. Inventaire de la surface réelle

Lisez la surface active en direct avant de théoriser :

• hooks de dépôt et scripts de hooks locaux
• Actions GitHub et workflows planifiés
• configurations MCP et serveurs activés
• intégrations basées sur des connecteurs ou des applications
• scripts wrapper et points d'entrée d'automatisation spécifiques au dépôt

Regroupez-les par surface :

• runtime local
• CI / automatisation du dépôt
• systèmes externes connectés
• messagerie / notifications
• facturation / opérations client
• recherche / surveillance

2. Classer chaque élément par état actif

Pour chaque automatisation détectée, marquez :

• configuré
• authentifié
• récemment vérifié
• obsolète ou cassé
• manquant

Classez ensuite le type de problème :

• panne active
• panne d'authentification
• état obsolète
• chevauchement ou redondance
• capacité manquante

3. Tracer le chemin de preuve

Étayez chaque affirmation importante par une source concrète :

• chemin de fichier
• exécution de workflow
• journal de hook
• entrée de configuration
• sortie de commande récente
• signature exacte de l'échec

Si l'état actuel est ambigu, dites-le directement au lieu de prétendre que l'audit est complet.

4. Terminer par keep / merge / cut / fix-next

Pour chaque surface qui se chevauche ou suspecte, renvoyez une action :

• keep
• merge
• cut
• fix next

La valeur réside dans la réduction du bruit des automatisations pour une seule voie canonique ECC, pas dans la préservation de chaque chemin historique.

Format de sortie

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

Pièges

• ne répondez pas de mémoire lorsque l'inventaire en direct peut être lu
• ne traitez pas "présent dans la config" comme "fonctionnel"
• ne corrigez pas une redondance de faible valeur avant d'avoir nommé le chemin cassé à haute signalisation
• n'élargissez pas la tâche en une réécriture du dépôt si l'utilisateur a d'abord demandé un inventaire

Vérification

• les affirmations importantes citent un chemin de preuve en direct
• chaque automatisation détectée est étiquetée avec une catégorie d'état actif claire
• la recommandation finale distingue keep / merge / cut / fix-next