Que fait Audit de surface d'espace de travail ?
Compétence d'audit en lecture seule pour répondre à la question « que peut réellement faire cet espace de travail et cette machine maintenant, et que devrions-nous ajouter ou activer ensuite ? »
Il s'agit de la réponse native ECC aux plugins d'audit de configuration. Elle ne modifie pas les fichiers, sauf si l'utilisateur demande explicitement une implémentation de suivi.
Quand l'utiliser
- L'utilisateur dit « configure Claude Code », « recommande des automatisations », « quels plugins ou MCP devrais-je utiliser ? » ou « que me manque-t-il ? »
- Auditer une machine ou un dépôt avant d'installer d'autres compétences, hooks ou connecteurs
- Comparer les plugins officiels du marketplace avec la couverture ECC native
- Examiner
.env,.mcp.json, les paramètres de plugins, ou les surfaces d'applications connectées pour trouver les couches de workflow manquantes - Décider si une capacité doit être une compétence, un hook, un agent, un MCP ou un connecteur externe
Règles non négociables
- N'affichez jamais les valeurs secrètes. Révélez uniquement les noms des fournisseurs, les noms des capacités, les chemins de fichiers, et si une clé ou une configuration existe.
- Privilégiez les workflows ECC natifs plutôt que les conseils génériques « installez un autre plugin » lorsque ECC peut raisonnablement posséder la surface.
- Traitez les plugins externes comme des références et des sources d'inspiration, et non comme des limites de produit faisant autorité.
- Séparez clairement trois choses :
- déjà disponible maintenant
- disponible mais mal encapsulé dans ECC
- non disponible et nécessiterait une nouvelle intégration
Entrées d'audit
Inspectez uniquement les fichiers et paramètres nécessaires pour bien répondre à la question :
- Surface du dépôt
package.json, lockfiles, marqueurs de langage, configuration de framework,README.md.mcp.json,.lsp.json,.claude/settings*.json,.codex/*AGENTS.md,CLAUDE.md, manifestes d'installation, configurations de hooks
- Surface d'environnement
- Fichiers
.env*dans le dépôt actif et les espaces de travail ECC adjacents évidents - Révélez uniquement les noms de clés comme
STRIPE_API_KEY,TWILIO_AUTH_TOKEN,FAL_KEY
- Fichiers
- Surface d'outils connectés
- Plugins installés, connecteurs activés, serveurs MCP, LSP et intégrations d'applications
- Surface ECC
- Compétences existantes, commandes, hooks, agents et modules d'installation qui couvrent déjà le besoin
Processus d'audit
Phase 1 : Inventaire de ce qui existe
Produisez un inventaire compact :
- cibles de harnais actives
- plugins installés et applications connectées
- serveurs MCP configurés
- serveurs LSP configurés
- services basés sur des variables d'environnement suggérés par les noms de clés
- compétences ECC existantes déjà pertinentes pour l'espace de travail
Si une surface n'existe que sous forme primitive, signalez-le. Exemple :
- « Stripe est disponible via une application connectée, mais il manque une compétence opérateur de facturation dans ECC »
- « Google Drive est connecté, mais il n'existe pas de workflow opérateur Google Workspace natif ECC »
Phase 2 : Comparaison avec les surfaces officielles et installées
Comparez l'espace de travail avec :
- les plugins officiels Claude qui chevauchent la configuration, la révision, la documentation, le design ou la qualité du workflow
- les plugins installés localement dans Claude ou Codex
- les surfaces d'applications actuellement connectées de l'utilisateur
Ne vous contentez pas de lister les noms. Pour chaque comparaison, répondez :
- ce qu'ils font réellement
- si ECC a déjà la parité
- si ECC n'a que des primitives
- si le workflow entier manque dans ECC
Phase 3 : Transformer les lacunes en décisions ECC
Pour chaque lacune réelle, recommandez la forme native ECC correcte :
| Type de lacune | Forme ECC préférée |
|---|---|
| Workflow opérateur répétable | Compétence |
| Application automatique ou effet secondaire | Hook |
| Rôle délégué spécialisé | Agent |
| Pont vers un outil externe | Serveur MCP ou connecteur |
| Conseils d'installation/d'amorçage | Compétence de configuration ou d'audit |
Par défaut, privilégiez les compétences orientées utilisateur qui orchestrent les outils existants lorsque le besoin est opérationnel plutôt qu'infrastructurel.
Format de sortie
Retournez cinq sections dans cet ordre :
- Surface actuelle
- ce qui est déjà utilisable maintenant
- Parité
- là où ECC égale ou dépasse déjà la référence
- Lacunes uniquement primitives
- les outils existent, mais il manque une compétence opérateur propre dans ECC
- Intégrations manquantes
- capacité pas encore disponible
- Top 3 à 5 prochaines actions
- ajouts concrets natifs ECC, classés par impact
Règles de recommandation
- Recommandez au maximum 1 à 2 idées à plus forte valeur par catégorie.
- Favorisez les compétences avec une intention utilisateur évidente et une valeur métier :
- audit de configuration
- opérations de facturation/client
- opérations de tickets/programme
- opérations Google Workspace
- opérations de déploiement/contrôle
- Si un connecteur est spécifique à une entreprise, ne le recommandez que s'il est réellement disponible ou clairement utile au workflow de l'utilisateur.
- Si ECC possède déjà une primitive solide, proposez une compétence d'encapsulation plutôt que d'inventer un tout nouveau sous-système.
Bons résultats
- L'utilisateur peut voir immédiatement ce qui est connecté, ce qui manque et ce qu'ECC devrait posséder ensuite.
- Les recommandations sont suffisamment spécifiques pour être implémentées dans le dépôt sans un autre passage de découverte.
- La réponse finale est organisée autour des workflows, et non des marques d'API.