Le registre de compétences TrueFoundry expliqué : versionner les connaissances procédurales entre les agents

Les compétences regroupent des instructions, des références, des scripts et des ressources au sein de procédures réutilisables. Un registre permet de rendre ces bundles identifiables et versionnés, mais ne garantit pas automatiquement leur fiabilité.

TrueFoundry19 septembre 20269 min de lecture

Cadrage de la source. Cette explication se base sur la documentation du registre de compétences de l'AI Gateway de TrueFoundry, sur la création, la gestion et l'utilisation des compétences, ainsi que sur la documentation des capacités de compétences et de harnais de TrueForge, révisée le 19 septembre 2026. La documentation actuelle décrit le RBAC au niveau du dépôt et le versionnage, les noms complets (FQN) numérotés, la publication via l'interface utilisateur pour les compétences à fichier unique, la publication via CLI ou GitOps pour les bundles multi-fichiers, l'utilisation au sein des agents TrueFoundry, Claude Code et Cursor, ainsi que la divulgation progressive dans TrueForge. L'examen de sécurité, la signature, l'évaluation et l'admission aux versions mentionnés ci-dessous sont des contrôles recommandés et non une certification intégrée revendiquée.

Une compétence est un ensemble de procédures, pas une nouvelle autorisation

Une compétence d'agent décrit la manière d'exécuter une tâche récurrente. Son fichier racine SKILL.md contient un nom, une description orientée action et la procédure. Un bundle plus complet peut inclure des documents de référence, des scripts et des ressources. Cette structure sépare les connaissances procédurales d'un prompt système monolithique et permet à l'environnement d'exécution de ne charger les détails que lorsque la compétence est pertinente.

La distinction entre connaissance et autorité est essentielle. Une compétence peut indiquer à un agent comment interroger un entrepôt de données, trier un incident ou rédiger des notes de version. Elle n'accorde pas, en soi, l'accès à une base de données, n'autorise pas la réponse à un incident et ne garantit pas l'exactitude d'une note de version générée. Les outils, les identifiants, la politique de la passerelle et les systèmes en aval restent les seuls vecteurs d'autorité.

Le registre de compétences de TrueFoundry confère au bundle une identité partagée. Les compétences résident dans des dépôts, héritent de l'accès au dépôt et de l'historique des versions, et sont adressées par des noms complets (FQN) numérotés. Les équipes peuvent publier une fois et réutiliser le bundle dans les agents TrueFoundry, Claude Code ou Cursor.

La divulgation progressive réduit le contexte initial en n'exposant que les métadonnées de sélection. Cela ne rend pas la procédure sélectionnée sûre pour autant ; le bundle complet demeure donc un artefact soumis à gouvernance.

La divulgation progressive est la conception de l'exécution

TrueForge indique qu'une compétence associée ne contribue que par son nom et sa description au contexte initial du modèle. Le corps complet du fichier SKILL.md est lu à la demande depuis le bac à sable (sandbox) lorsque l'agent détermine que la compétence est pertinente. Cela réduit le contexte initial tout en conservant la procédure disponible.

La description constitue donc une surface de routage. Si elle est vague, l'agent risque de ne pas sélectionner la compétence ou de la sélectionner pour une tâche inappropriée. Maintenez-la orientée vers l'action, précisez quand la compétence doit être utilisée et évitez les descriptions qui se chevauchent, ce qui rendrait la sélection ambiguë. Le comportement de sélection doit être évalué avec des requêtes utilisateur réalistes, y compris les cas limites.

Le chargement progressif contrôle la taille du contexte ; il n'isole pas le contenu non approuvé. Une fois sélectionné, le corps de la compétence et les fichiers de support influencent l'agent. Les scripts peuvent s'exécuter dans le bac à sable configuré et les références peuvent orienter l'utilisation des outils. Traitez une compétence multi-fichiers comme un artefact logiciel doté d'une chaîne d'approvisionnement.

Trois chemins de publication, un seul artefact versionné

TrueFoundry documente trois chemins de publication. L'interface utilisateur crée une compétence à fichier unique dont le corps est le contenu SKILL.md rédigé dans l'éditeur. Les bundles multi-fichiers utilisent la commande de téléchargement CLI ou un manifeste déclaratif appliqué via GitOps. Tous les chemins créent une compétence versionnée sous un dépôt et génèrent un FQN, tel qu'une compétence qualifiée par dépôt à la version 1.

L'interface utilisateur ne prend actuellement en charge que le fichier SKILL.md unique. Les références, les scripts et les ressources nécessitent un chemin via CLI ou GitOps ; la prise en charge multi-fichiers dans l'interface utilisateur est prévue dans la feuille de route. La CLI valide les métadonnées (frontmatter) et télécharge le bundle. GitOps pointe un manifeste vers un répertoire de compétences local et publie via le même flux de travail d'application utilisé pour les autres ressources TrueFoundry.

Les chemins de publication diffèrent sur le plan opérationnel, mais convergent vers la même identité de dépôt et de version. Cette identité permet aux agents et aux environnements de développement locaux de consommer un bundle concret plutôt qu'une copie informelle.

L'accès au dépôt est hérité

Dans le modèle documenté, les compétences ne disposent pas de permissions individuelles distinctes. Les droits de découverte, de modification et d'utilisation sont hérités du dépôt parent. Cela fait des limites du dépôt l'unité pratique de gouvernance. Regroupez les compétences par propriété et sensibilité compatibles plutôt que de placer chaque procédure dans un catalogue unique aux accès étendus.

L'accès au dépôt détermine qui peut récupérer ou utiliser le bundle. Il ne restreint pas chaque action recommandée par la compétence. Un utilisateur autorisé à utiliser une compétence de base de données doit toujours disposer des autorisations nécessaires au niveau de l'outil de base de données et des ressources métier. Inversement, la révocation d'une compétence n'entraîne pas nécessairement la révocation de l'accès à l'outil sous-jacent.

CoucheCe qu'elle contrôleCe qu'elle ne prouve pasDépôtQui peut découvrir, modifier ou utiliser les versions de compétences stockées.Que le contenu de la compétence est sûr ou efficace.Bundle de compétencesProcédure, références, scripts et ressources.L'autorisation d'appeler des systèmes externes.TrueForgeChargement au moment de l'exécution et utilisation en bac à sable pour les compétences associées.La justesse de la procédure ou du résultat métier.Passerelle et outilIdentité, accès, garde-fous, approbations et exécution routée.Que le résultat de la tâche a atteint son objectif.

Le verrouillage de version est le fondement de la reproductibilité

La documentation de la CLI Skills exige un numéro de version entier positif lors du téléchargement et précise que l'alias « latest » n'est pas pris en charge. Il s'agit d'une propriété opérationnelle utile : les consommateurs désignent un bundle concret. Verrouillez la même version concrète dans la configuration de l'agent et dans les environnements de développement locaux lorsque vous avez besoin d'un comportement comparable.

Une version nécessite toujours une traçabilité. Enregistrez le commit du dépôt source, l'éditeur, le processus de construction ou de packaging, les empreintes numériques des fichiers, les dépendances et le résultat de la révision. Pour les scripts, verrouillez les paquets externes et enregistrez l'environnement d'exécution. Un FQN numéroté identifie ce que le registre a stocké ; la traçabilité explique comment ce bundle a été produit.

Les scripts et les références créent des risques différents

Les fichiers de référence peuvent être obsolètes, incomplets ou modifiés de manière malveillante. Les scripts peuvent lire et transformer des données, invoquer des commandes locales ou appeler des services via des interfaces disponibles. Les ressources peuvent contenir du contenu actif ou malformé. Examinez chaque catégorie avec un contrôle approprié plutôt que de traiter le répertoire comme du Markdown indifférencié.

Les contrôles statiques peuvent valider le frontmatter, le parcours de chemin, la structure de l'archive, la taille des fichiers, les binaires interdits, les déclarations de dépendances et les modèles dangereux connus. Les tests en bac à sable peuvent éprouver les scripts avec des entrées synthétiques et un accès réseau restreint. Les évaluations de tâches peuvent mesurer si l'agent sélectionne la compétence et respecte ses contraintes. La révision humaine doit se concentrer sur les procédures privilégiées et les actions irréversibles.

Le pipeline d'admission sépare le stockage, l'inspection, l'exécution des tâches et l'autorisation au moment de l'exécution. Aucun contrôle unique ne certifie toutes les propriétés d'une compétence.

La promotion doit être consciente du consommateur

La même compétence peut être utilisée par un agent TrueFoundry, Claude Code et Cursor, mais ces surfaces ne partagent pas nécessairement des modèles, des outils, des bacs à sable ou une identité utilisateur identiques. La portabilité du format n'est pas l'équivalence du comportement à l'exécution. Testez la compétence dans chaque surface prise en charge et enregistrez l'environnement dans le résultat.

Une compétence sûre lorsqu'elle est associée à des outils MCP en lecture seule peut devenir dangereuse lorsqu'un environnement de développement local expose des accès en écriture et des commandes shell. Les métadonnées de version doivent nommer les dépendances d'outils attendues, les permissions requises, les versions d'exécution compatibles et les environnements interdits.

Un cycle de vie de compétence discipliné

Commencez par une tâche restreinte et une description rendant la sélection testable. Rédigez la procédure en précisant les préconditions, les outils autorisés, les preuves requises, la gestion des erreurs et les règles d'arrêt. Publiez une version candidate. Exécutez des tests statiques, en bac à sable et comportementaux. Autorisez son utilisation par des consommateurs désignés. Observez la sélection, l'utilisation des outils, les échecs et les résultats. Retirez la version en supprimant les consommateurs et l'accès, puis conservez les preuves exigées par la politique.

Ne modifiez pas une compétence largement utilisée directement par une distribution de fichiers informelle. Publiez une nouvelle version, comparez l'ensemble du bundle et migrez les consommateurs de manière délibérée. Lorsqu'une vulnérabilité est détectée dans un script ou une référence, identifiez chaque agent consommateur et chaque surface de développement via l'inventaire des versions.

Les numéros de version sont des identifiants, pas des promesses de compatibilité.

Un numéro de version indique aux consommateurs quel bundle ils ont reçu. Il ne communique pas, en soi, si une mise à jour est rétrocompatible. Un changement de nom d'outil, de chemin de fichier, de schéma de sortie ou d'autorisation requise peut bloquer un agent, même si la procédure semble similaire.

Publiez les métadonnées de compatibilité avec le bundle : environnement d'exécution attendu, outils requis, contrats d'entrée et de sortie pris en charge, versions des dépendances, classifications des données et migrations connues. Pour les changements majeurs, maintenez la version précédente disponible suffisamment longtemps pour permettre aux consommateurs de migrer sereinement. Évitez d'apprendre aux agents à télécharger un bundle « latest » dynamique lors de l'exécution ; résolvez le numéro approuvé lors de la publication.

L'inventaire est essentiel pour la gestion des incidents.

Lorsqu'une référence devient erronée ou qu'une dépendance de script est compromise, les intervenants doivent répondre rapidement à deux questions : quelles versions contiennent le problème et où ces versions sont-elles utilisées ? L'identité dans le registre fournit le premier point d'ancrage, mais l'inventaire des consommateurs doit inclure les agents TrueFoundry ainsi que toute installation locale de Claude Code ou de Cursor synchronisée depuis le registre.

Les copies locales peuvent survivre aux changements d'accès au dépôt. La révocation des droits d'utilisation empêche toute récupération future, mais n'efface pas un bundle déjà téléchargé sur la machine d'un développeur. Les plans d'incident doivent distinguer le confinement du registre, le détachement à l'exécution, la remédiation locale, la révocation des identifiants d'outils et le rapprochement en aval. Le retrait n'est complet que lorsque l'autorité risquée et les copies affectées ont été traitées.

L'évaluation des résultats doit suivre la procédure.

L'évaluation des compétences nécessite plus que des tests de sélection. Vérifiez que l'agent respecte les préconditions, utilise les outils prévus, respecte les limites de lignes ou de coûts, gère les données manquantes, cite les bonnes références et s'arrête avant toute action non autorisée. Vérifiez ensuite le résultat de la tâche. Une trajectoire d'outil syntaxiquement correcte peut tout de même produire un mauvais résultat métier.

Stockez le FQN de la compétence avec chaque évaluation et trace d'exécution. Cela permet aux équipes de comparer les versions, de détecter les régressions et de déterminer si une défaillance provient de la compétence, du modèle, de l'outil, des données ou de la politique associée. Sans ce lien de version, une procédure partagée devient impossible à gouverner à grande échelle.

Tests d'échec à conserver.

• Utilisez des prompts qui devraient, ou ne devraient pas, sélectionner la compétence ; mesurez la sélection erronée et la sélection manquée.
• Publiez un bundle multi-fichiers contenant des chemins inattendus, des liens symboliques, des fichiers surdimensionnés et des dépendances non déclarées.
• Modifiez uniquement un script de support ou une référence ; confirmez que la comparaison du bundle et le changement de version le mettent en évidence.
• Exécutez la même version sur les surfaces prises en charge et comparez la portée et le comportement des outils.
• Révoquez l'accès au dépôt et confirmez que les consommateurs ne peuvent pas récupérer une nouvelle copie.
• Supprimez une compétence d'un agent tout en laissant l'accès aux outils intact ; confirmez que la distinction est bien comprise.
• Retirez une version vulnérable et inventoriez chaque consommateur épinglé avant de déclarer la remédiation terminée.

Comment le registre des compétences et TrueForge s'articulent.

Skills Registry est la surface de distribution et de gouvernance pour les bundles procéduraux versionnés. TrueForge est l'environnement d'exécution qui expose les métadonnées des compétences associées, charge la procédure complète à la demande et exécute les tâches de support via son bac à sable et ses outils. AI Gateway et MCP Gateway régissent le trafic des modèles et des outils autour de cet environnement d'exécution.

Aucune de ces couches ne certifie une procédure. L'intérêt de la plateforme réside dans sa composition : l'identité du registre et l'accès au dépôt, la gestion du contexte d'exécution, l'autorisation des outils et les preuves peuvent être alignés autour d'une même version de compétence épinglée.

La règle opérationnelle

Traitez les compétences comme des artefacts de publication proches du code. Soyez précis dans les descriptions, utilisez des versions numérotées, examinez le bundle complet, testez la sélection et l'exécution, et limitez les dépôts aux périmètres de responsabilité réels.

Le registre de TrueFoundry rend les connaissances procédurales réutilisables entre les agents et les surfaces de développement. TrueForge rend ces connaissances économiques à charger lors de l'exécution. Le système ne devient fiable que lorsque le versionnage est associé à l'admission, au principe du moindre privilège, au bac à sable et à la preuve des résultats.

Références

1. TrueFoundry — Registre des compétences AI Gateway.
2. TrueFoundry — Créer, gérer et utiliser des compétences.
3. TrueForge — Compétences.
4. TrueForge — Exploiter les capacités.

Divulgation éditoriale. Cet article reflète l'interprétation technique de TrueFoundry des documents publics cités au 19 septembre 2026. Les capacités du produit sont limitées à la documentation liée. Les exemples et les paramètres par défaut sont fournis à titre illustratif ; ils ne constituent pas un conseil juridique, un avis d'audit, une analyse comparative indépendante, ni une garantie de sécurité, de sûreté ou de conformité.

Slug : truefoundry-skills-registry-explainedTitre SEO : TrueFoundry Skills Registry, expliquéMéta-description : Découvrez comment le registre de compétences TrueFoundry versionne les bundles SKILL.md, applique le contrôle d'accès (RBAC) aux dépôts, prend en charge la publication via UI, CLI et GitOps, et s'intègre à TrueForge.

‍