Créer et entretenir une bibliothèque de compétences utilisable avec toute IA

## Ranger les dossiers pour ne charger les détails d’une compétence qu’à l’usage Attribuez à chaque compétence son propre répertoire avec un fichier principal d’instructions, les métadonnées obligatoires et des répertoires facultatifs de références et de scripts. Conservez les exemples complets, les documents de recherche, les modèles canoniques et la documentation de toute la collection dans des emplacements clairement séparés. Maintenez une carte des compétences à la racine afin qu’un utilisateur ou un agent puisse découvrir la collection sans charger le contenu de toutes les compétences. Traitez les noms et les descriptions comme l’index de démarrage. Ne chargez les instructions détaillées, les références et les scripts que lorsqu’une compétence s’active. Cette structure préserve l’attention pour la tâche en cours tout en laissant les documents approfondis disponibles à la demande. ## Garder court le fichier principal de chaque compétence, utilisable avec tout outil Maintenez le fichier principal d’instructions d’une compétence sous 500 lignes et placez les détails dans les références. Exigez des métadonnées YAML avec les champs name et description, rédigez description à la troisième personne, utilisez des noms de répertoire en minuscules séparés par des traits d’union et remettez en question la valeur informative de chaque paragraphe. Supposez un public expérimenté, sauf si la compétence enseigne explicitement les notions fondamentales. Rédigez des instructions indépendantes de la plateforme. Abstrayez les outils propres à un fournisseur, sauf lorsqu’une contrainte de plateforme est essentielle, et rendez les exemples portables au lieu de présenter un pseudocode conceptuel comme du code prêt pour la production. ## Écrire quand utiliser chaque compétence et quand ne pas l’utiliser Incluez des sections consacrées aux conditions d’activation, aux concepts fondamentaux, aux conseils pratiques, aux exemples, aux directives, aux pièges, à l’intégration et aux références. Chaque section d’activation doit indiquer des déclencheurs positifs et une limite de non-activation qui oriente les travaux adjacents vers la compétence appropriée. Accordez une importance particulière aux pièges tirés de l’expérience, car ils décrivent des modes d’échec que les instructions génériques omettent souvent. Dans les instructions d’intégration, mentionnez les autres compétences par des noms stables en texte brut lorsque des liens risquent de se rompre entre différentes dispositions d’installation. ## À chaque changement, mettre à jour les listes et la source des chiffres Lors de l’ajout ou de la modification d’une compétence, mettez à jour ensemble la présentation de la collection, les manifestes de distribution et l’index du corpus. Associez la compétence à ses scénarios d’activation, à ses mécanismes de comportement réutilisables et aux assertions qui l’étayent, afin que la découverte, le conditionnement et l’évaluation décrivent le même artefact. Consignez la provenance des assertions numériques, de benchmark, volatiles ou relatives aux performances d’un fournisseur. Mettez à jour les registres des mécanismes et des assertions chaque fois qu’une compétence introduit un changement de comportement réutilisable ou une assertion sensible aux preuves ; ne laissez pas ces relations implicites dans le texte. ## Lancer des vérifications automatiques avant de demander l’avis d’une IA Avant d’accepter une modification, exécutez les vérifications déclarées par le dépôt pour l’analyse des métadonnées, le schéma et la structure stricte du corpus, les dispositions d’installation compatibles entre plateformes, l’intégrité du contenu des compétences, les limites d’activation et les benchmarks adversariaux. Traitez-les comme des contrôles de revue, et non comme des diagnostics facultatifs. Validez d’abord de manière déterministe la structure, la synchronisation des manifestes, le calcul des barèmes, l’état de récupération et la forme des registres. N’utilisez un jugement fondé sur un modèle qu’après la réussite de ces vérifications et ne recourez pas à un modèle pour justifier un défaut structurel reproductible. ## Utiliser les commandes d’installation et de test propres à chaque projet d’exemple N’inventez pas de système de build global lorsque le dépôt n’en possède pas. Identifiez le runtime et le gestionnaire de paquets déclarés par chaque exemple ou sous-projet, puis utilisez ses propres commandes setup, build, test, lint, format et type-check. Limitez les environnements et les dépendances au sous-projet concerné. Exécutez la plus petite commande pertinente pendant les itérations, puis terminez l’ensemble des contrôles documentés par le sous-projet avant la revue. Distinguez la compilation, les tests unitaires, les tests asynchrones, le linting, le formatage et la vérification statique des types, au lieu de considérer la réussite d’une seule commande comme la preuve que tous les contrôles ont réussi. ## Faire avancer chaque recherche par étapes fixes avec l’outil prévu Initialisez chaque exécution de recherche au moyen de l’outil de cycle de vie fourni, afin qu’il crée de manière cohérente le fichier d’état, l’entrée de file, le journal du fil, la structure d’évaluation des sources et le modèle de proposition de mécanisme. Progressez par récupération, évaluation, proposition, revue de nouveauté, validation de l’exécution, préparation à la revue et clôture au moyen des transitions prises en charge ; ne modifiez jamais l’état d’une exécution à la main. Validez les exécutions actives indépendamment des contrôles portant sur l’ensemble du dépôt. Ne promouvez un mécanisme proposé qu’après la préparation de l’exécution, l’enregistrement du réviseur requis et la réussite du contrôle de préparation. Ajoutez la provenance d’une assertion avant d’introduire dans une compétence une assertion numérique, de benchmark ou volatile. ## Ne pas appeler d’IA payante dans la recherche automatique avant un budget fixé Fournissez des commandes déterministes pour la découverte, l’avancement d’une étape, le traitement quotidien et les rapports d’état, que la boucle soit lancée manuellement ou par un planificateur propre à la plateforme. Maintenez la récupération utilisable sans appel à des modèles payants et n’invoquez pas de modèle payant depuis une boucle sans surveillance tant qu’un contrôle budgétaire explicite n’existe pas. Traitez les files, les journaux du runtime, les instantanés, les rapports d’état, les revues mises en attente, les flux d’événements, les échecs et les répertoires d’exécution ordinaires comme un état opérationnel, non comme du code source. Ne les incluez jamais dans un commit, sauf pour une exécution d’amorçage délibérément désignée. ## Distribuer les compétences liées en un seul paquet, sans copies Lorsqu’un hôte met en cache séparément la source de chaque plugin, distribuez une collection de compétences associées dans un seul paquet plutôt que de faire pointer plusieurs paquets vers la même arborescence source. Cela évite les caches redondants tout en préservant une limite cohérente de version et de manifeste. Au démarrage, n’exposez que les métadonnées nécessaires à la découverte. Reportez le chargement du contenu complet des compétences et des ressources complémentaires jusqu’à l’activation, afin que l’étendue du paquet ne devienne pas une charge permanente pour le contexte. ## Donner moins de contenu à l’IA et demander l’accord d’une personne avant d’envoyer les changements au dépôt partagé (push) Privilégiez la qualité du contexte plutôt que sa quantité : l’attention limitée et la perte d’informations en position intermédiaire signifient qu’un volume de documents plus important peut réduire les performances. Utilisez des sous-agents pour isoler l’attention sur des travaux délimités, et pas seulement pour imiter des rôles organisationnels. Maintenez les exemples conceptuels portables, notamment avec un pseudocode indépendant du langage ou largement lisible. Faites précéder le jugement du modèle par des preuves déterministes et maintenez la publication distante sous contrôle humain. Les agents peuvent préparer les modifications et réussir tous les contrôles locaux, mais ils doivent obtenir une approbation humaine explicite avant d’exécuter push ou merge.