Audit de Surface de l'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 ? »
C'est 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 « qu'est-ce qui me manque ? »
- Auditer une machine ou un dépôt avant d'installer plus de compétences, hooks ou connecteurs
- Comparer les plugins officiels du marketplace avec la couverture ECC native
- Examiner
.env,.mcp.json, les paramètres de plugin 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
- Ne jamais afficher les valeurs secrètes. Ne révéler que les noms de fournisseurs, noms de capacités, chemins de fichiers et l'existence d'une clé ou d'une configuration.
- Privilégier les workflows ECC natifs plutôt que des conseils génériques « installe un autre plugin » lorsque ECC peut raisonnablement couvrir la surface.
- Traiter les plugins externes comme des références et sources d'inspiration, pas comme des limites de produit autoritaires.
- Séparer 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
Inspecter uniquement les fichiers et paramètres nécessaires pour bien répondre à la question :
- Surface du dépôt
package.json, fichiers de verrouillage, marqueurs de langage, configuration du framework,README.md.mcp.json,.lsp.json,.claude/settings*.json,.codex/*AGENTS.md,CLAUDE.md, manifestes d'installation, configurations de hooks
- Surface de l'environnement
- Fichiers
.env*dans le dépôt actif et les espaces de travail ECC adjacents évidents - Ne révéler que les noms de clés comme
STRIPE_API_KEY,TWILIO_AUTH_TOKEN,FAL_KEY
- Fichiers
- Surface des outils connectés
- Plugins installés, connecteurs activés, serveurs MCP, LSP et intégrations d'applications
- Surface ECC
- Compétences, commandes, hooks, agents et modules d'installation existants qui couvrent déjà le besoin
Processus d'Audit
Phase 1 : Inventaire de Ce Qui Existe
Produire un inventaire concis :
- cibles de harnais actives
- plugins installés et applications connectées
- serveurs MCP configurés
- serveurs LSP configurés
- services basés sur l'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, le signaler. Exemple :
- « Stripe est disponible via une application connectée, mais ECC n'a pas de compétence d'opérateur de facturation »
- « Google Drive est connecté, mais il n'y a pas de workflow d'opérateur Google Workspace natif ECC »
Phase 2 : Référencement par Rapport aux Surfaces Officielles et Installées
Comparer l'espace de travail avec :
- les plugins Claude officiels qui chevauchent la configuration, la révision, la documentation, la conception 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 pas se contenter de lister les noms. Pour chaque comparaison, répondre :
- ce qu'ils font réellement
- si ECC a déjà la parité
- si ECC n'a que des primitives
- si le workflow manque totalement dans ECC
Phase 3 : Transformer les Lacunes en Décisions ECC
Pour chaque lacune réelle, recommander la forme ECC native appropriée :
| Type de Lacune | Forme ECC Préférée |
|---|---|
| Workflow d'opérateur reproductible | Compétence |
| Application automatique ou effet de bord | Hook |
| Rôle délégué spécialisé | Agent |
| Pont vers un outil externe | Serveur MCP ou connecteur |
| Guidance d'installation/amorçage | Compétence de configuration ou d'audit |
Par défaut, privilégier les compétences orientées utilisateur qui orchestrent les outils existants lorsque le besoin est opérationnel plutôt qu'infrastructurel.
Format de Sortie
Retourner cinq sections dans cet ordre :
- Surface actuelle
- ce qui est déjà utilisable maintenant
- Parité
- là où ECC correspond déjà ou dépasse la référence
- Lacunes primitives uniquement
- les outils existent, mais ECC manque d'une compétence d'opérateur propre
- Intégrations manquantes
- capacité pas encore disponible
- Top 3 à 5 prochaines actions
- ajouts ECC natifs concrets, classés par impact
Règles de Recommandation
- Recommander au maximum 1 à 2 idées à plus forte valeur par catégorie.
- Favoriser 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/programmes
- opérations Google Workspace
- opérations de déploiement/contrôle
- Si un connecteur est spécifique à une entreprise, ne le recommander que s'il est réellement disponible ou clairement utile au workflow de l'utilisateur.
- Si ECC a déjà une primitive solide, proposer une compétence d'encapsulation plutôt que d'inventer un tout nouveau sous-système.
Bons Résultats
- L'utilisateur peut immédiatement voir ce qui est connecté, ce qui manque et ce qu'ECC devrait couvrir ensuite.
- Les recommandations sont suffisamment spécifiques pour être implémentées dans le dépôt sans un nouveau passage de découverte.
- La réponse finale est organisée autour des workflows, pas des marques d'API.