Les skills d’OpenClaw

Une skill est un dossier contenant un fichier markdown. Ce fichier dit à l’agent comment et quand recourir à un outil, et OpenClaw décide quels fichiers un agent peut voir avant même que le modèle prenne la main. Les règles méritent d’être connues parce qu’elles expliquent à la fois les surprises (une skill qui n’apparaît pas) et les coûts (chaque skill éligible dépense des jetons d’invite). Voici tout le mécanisme.

D’où viennent les skills

• Les skills sur fichier se chargent par priorité décroissante : skills de l’espace de travail, skills d’agent du projet, skills d’agent personnelles dans le dossier utilisateur, skills gérées dans le répertoire d’état, skills d’atelier propres à l’agent, skills livrées avec l’installation ainsi que la bibliothèque Custodian, puis enfin les répertoires supplémentaires et les skills de plugins ; quand le même nom apparaît deux fois, la source la plus haute gagne.
• Les racines acceptent les dispositions groupées : une skill découverte n’importe où sous une racine configurée jusqu’à six niveaux de profondeur est trouvée, et en trouver une arrête la descente sous ce dossier ; le chemin du dossier n’est que de l’organisation, car le nom et la commande viennent du champ de nom dans l’entête ou du nom du dossier quand il manque.
• Un nœud sans écran connecté peut publier les skills installées dans son propre répertoire : elles apparaissent dans la liste de l’agent tant que le nœud est connecté et disparaissent à la déconnexion, une skill locale ou de passerelle garde son nom en cas de collision tandis que celle du nœud reçoit un nom préfixé, et comme ses fichiers et binaires vivent sur le nœud, on l’exécute avec l’outil exec visant ce nœud.
• La visibilité suit le chemin : les skills d’espace de travail sont visibles par un seul agent, celles du projet par l’agent de cet espace, les personnelles par les agents sur l’état par défaut, les gérées par tous les agents partageant cet état, celles de l’atelier par l’agent qui les a rédigées, et les répertoires supplémentaires par tous les agents partageant cette configuration ; une skill d’atelier apprise par un agent n’est pas partagée avec un autre tant qu’elle n’est pas publiée dans la bibliothèque gérée.

Traitez les skills tierces comme du code non fiable. Lisez-les avant de les activer.

Listes blanches, filtrage et bibliothèque personnelle

L’emplacement et la visibilité sont deux contrôles distincts. Une liste blanche dans les valeurs par défaut des agents pose une base commune, une liste non vide par agent est l’ensemble final et ne fusionne pas avec les valeurs par défaut, un tableau vide n’expose aucune skill, et la liste effective s’applique autant à la construction de l’invite qu’à la découverte des commandes, à la synchronisation du bac à sable et aux instantanés. Le filtrage est l’autre tamis : un bloc de métadonnées dans l’entête peut exiger des binaires présents dans le chemin, au moins un d’un ensemble, des variables d’environnement, des chemins de configuration vrais ou un système d’exploitation précis, et l’option toujours contourne tout sauf le filtre de plateforme. Sur une passerelle partagée, des opérateurs identifiés gardent une bibliothèque personnelle plutôt que de modifier l’espace de travail de tous : l’enregistrement publie une révision immuable complète dont l’empreinte couvre chemins, contenu, tailles et droits d’exécution, une session garde les révisions choisies jusqu’à un rattachement ou un rafraîchissement explicite, et une nouvelle session sélectionne jusqu’à 64 skills activées, les personnelles d’abord.

Installer, surcharger, rafraîchir

• Les commandes de skills installent depuis le registre public dans l’espace de travail par défaut ou dans le répertoire partagé avec l’option globale, et savent installer depuis un dépôt git ou un dossier local ; la vérification demande au registre l’enveloppe de confiance de la skill et sort en erreur quand le registre la marque en échec, tandis qu’une politique d’installation de l’opérateur peut filtrer chaque chemin d’installation et échoue fermée quand elle ne peut pas rendre de décision valide.
• Les entrées de configuration activent et paramètrent les skills : la valeur fausse désactive une skill même livrée, un champ de clé d’API alimente la variable d’environnement principale déclarée par la skill, une table d’environnement n’est injectée que si la variable n’est pas déjà définie, un sac de configuration porte des champs personnalisés, et une liste blanche ne restreint que les skills livrées ; les clés correspondent au nom de la skill sauf si celle-ci déclare la sienne.
• Les skills éligibles sont figées au démarrage d’une session et réutilisées jusqu’à un déclencheur de rafraîchissement : la surveillance voit un fichier de skill changer, la passerelle redémarre, un nouveau nœud distant éligible se connecte, ou la capacité de surveillance native est épuisée et le tour suivant commence ; la liste rafraîchie est prise au tour suivant, et une liste blanche modifiée force aussi un rafraîchissement.

La configuration des skills OpenClaw est le schéma de configuration complet de ces clés et L’outil exec d’OpenClaw l’outil que la plupart des skills finissent par appeler.

Ce que coûtent les skills

Dès qu’une skill est éligible, OpenClaw injecte un bloc compact dans l’invite système : une introduction fixe plus environ 97 caractères par skill en plus des longueurs du nom, de la description et de l’emplacement, ce qui, à environ quatre caractères par jeton, fait près de 24 jetons par skill avant ces champs. Si le bloc rendu dépassait le budget d’invite configuré, OpenClaw préserve d’abord autant d’identités de skills que le format sans description le permet, puis dépense le reste en descriptions raccourcies, et signale qu’une commande de vérification existe. Des descriptions courtes et précises sont le moyen le moins cher de garder un grand catalogue abordable. Deux frontières de sécurité comptent autant que le coût : l’injection d’environnement est limitée au run d’agent sur l’hôte et n’a aucun effet dans un bac à sable, et les listes blanches de skills ne sont pas une frontière d’autorisation du shell, donc un agent qui peut aussi lancer des commandes a besoin que Le bac à sable OpenClaw expliqué et Les approbations exec d’OpenClaw encadrent ce shell séparément.

Sur Diali

Sur Diali la configuration d’exécution est générée depuis le tableau de bord et remplacée à chaque version, et les fichiers de l’espace de travail qui portent les skills vivent sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). OpenClaw hébergé sur Diali décrit l’assistant hébergé et Les tarifs Diali les offres dans lesquelles il est livré.

• Sept sources, la plus haute gagne ; le nom vient de l’entête.
• Le filtrage trie au chargement ; les listes blanches trient par agent.
• Environ 24 jetons par skill éligible avant nom et description.