Skills

• Omettez agents.defaults.skills pour ne restreindre aucun Skill par défaut.
• Omettez agents.list[].skills pour hériter de agents.defaults.skills.
• Définissez agents.list[].skills: [] pour n’exposer aucun Skill à cet agent.
• Une liste agents.list[].skills non vide constitue l’ensemble définitif : elle n’est pas fusionnée avec les valeurs par défaut.
• La liste d’autorisation effective s’applique à la construction des prompts, à la découverte des commandes avec barre oblique, à la synchronisation du bac à sable et aux instantanés des Skills.
• Il ne s’agit pas d’une frontière d’autorisation pour le shell de l’hôte. Si le même agent peut utiliser exec, limitez ce shell séparément au moyen d’un bac à sable, de l’isolation par utilisateur du système d’exploitation, de listes d’interdiction ou d’autorisation pour l’exécution et d’identifiants propres à chaque ressource.

Par défaut, openclaw skills install effectue l’installation dans le répertoire skills/ de l’espace de travail actif. Ajoutez --global pour effectuer l’installation dans le répertoire partagé ~/.openclaw/skills, visible par tous les agents locaux sauf si leurs listes d’autorisation le restreignent.

Les installations Git et locales attendent un fichier SKILL.md à la racine de la source. L’identifiant court provient du champ name du frontmatter de SKILL.md lorsqu’il est valide, puis, à défaut, du nom du répertoire ou du dépôt. Utilisez --as <slug> pour le remplacer. openclaw skills update suit uniquement les installations ClawHub ; réinstallez les sources Git ou locales pour les actualiser.

openclaw skills verify @owner/<slug> demande à ClawHub le périmètre de confiance clawhub.skill.verify.v1 du Skill. Les Skills ClawHub installés sont vérifiés par rapport à la version et au registre enregistrés dans .clawhub/origin.json. Les identifiants courts sans propriétaire restent acceptés pour les Skills déjà installés ou non ambigus, mais les références qualifiées par le propriétaire évitent toute ambiguïté concernant l’éditeur.

Les pages de Skills ClawHub affichent l’état de la dernière analyse de sécurité avant l’installation, avec des pages détaillées pour VirusTotal, ClawScan et l’analyse statique. La commande renvoie un code de sortie non nul lorsque ClawHub indique que la vérification a échoué. Les éditeurs peuvent corriger les faux positifs depuis le tableau de bord ClawHub ou avec clawhub skill rescan @owner/<slug>.

Les clients du Gateway qui nécessitent une distribution hors de ClawHub peuvent préparer une archive ZIP de Skill avec skills.upload.begin, skills.upload.chunk et skills.upload.commit, puis l’installer avec skills.install({ source: "upload", ... }). Cette voie est désactivée par défaut et nécessite skills.install.allowUploadedArchives: true dans openclaw.json. Les installations ClawHub normales ne nécessitent jamais ce paramètre.

La découverte des Skills de l’espace de travail, de l’agent du projet et des répertoires supplémentaires accepte uniquement les racines de Skills dont le chemin réel résolu reste à l’intérieur de la racine configurée, sauf si skills.load.allowSymlinkTargets approuve explicitement une racine cible. L’Atelier de Skills écrit au travers de ces cibles approuvées uniquement lorsque skills.workshop.allowSymlinkTargetWrites est activé. Les répertoires gérés ~/.openclaw/skills et personnels ~/.agents/skills peuvent contenir des dossiers de Skills liés symboliquement, mais le chemin réel de chaque fichier SKILL.md doit toujours rester dans le répertoire résolu de son Skill.

Configurez security.installPolicy afin d’exécuter une commande de politique locale fiable avant de poursuivre l’installation des Skills. La politique reçoit les métadonnées et le chemin de la source préparée, s’applique aux installations ClawHub, aux téléversements, à Git, aux sources locales, aux mises à jour et aux chemins d’installation des dépendances, et refuse l’opération par défaut lorsque la commande ne peut pas renvoyer une décision valide.

skills.entries.*.env et skills.entries.*.apiKey injectent des secrets dans le processus de l’hôte uniquement pendant ce tour de l’agent, et non dans le bac à sable. N’incluez pas les secrets dans les prompts ni dans les journaux.

• Lorsque plusieurs programmes d’installation sont répertoriés, le Gateway choisit l’option privilégiée (brew lorsqu’il est disponible, sinon node).
• Si tous les programmes d’installation sont de type download, OpenClaw répertorie chaque entrée afin que vous puissiez voir tous les artefacts disponibles.
• Les spécifications peuvent inclure os: ["darwin"|"linux"|"win32"] pour appliquer un filtre par plateforme.
• Les installations Node respectent skills.install.nodeManager dans openclaw.json (valeur par défaut : npm ; options : npm / pnpm / yarn / bun). Cela concerne uniquement l’installation des skills ; l’environnement d’exécution du Gateway doit toujours être Node.
• Ordre de préférence des programmes d’installation du Gateway : Homebrew → uv → gestionnaire de paquets node configuré → go → download.

• Homebrew : OpenClaw n’installe pas automatiquement Homebrew et ne traduit pas les formules brew en commandes du gestionnaire de paquets système. Dans les conteneurs Linux dépourvus de brew, les programmes d’installation exclusivement basés sur brew sont masqués ; utilisez une image personnalisée ou installez la dépendance manuellement.
• Go : OpenClaw exige Go 1.21 ou une version plus récente pour l’installation automatique des skills. Si go est absent et que Homebrew est disponible, OpenClaw installe d’abord Go via Homebrew ; sous Linux sans Homebrew, il peut à la place utiliser apt-get en tant que superutilisateur ou via un sudo sans mot de passe lorsque la version candidate actualisée de golang-go satisfait à la version minimale. La commande go install proprement dite pour la dépendance cible toujours un répertoire d’exécutables dédié et géré par OpenClaw (le répertoire bin de Homebrew lors d’une nouvelle installation, sinon ~/.local/bin), plutôt que votre GOBIN configuré — vos propres variables d’environnement GOBIN, GOPATH et GOTOOLCHAIN sont lues, mais jamais remplacées.
• Téléchargement : url (obligatoire), archive (tar.gz | tar.bz2 | zip), extract (par défaut : automatique lorsqu’une archive est détectée), stripComponents, targetDir (par défaut : ~/.openclaw/tools/<skillKey>).

requires.bins est vérifié sur l’hôte lors du chargement de la skill. Si un agent s’exécute dans un environnement isolé, l’exécutable doit également exister dans le conteneur. Installez-le via agents.defaults.sandbox.docker.setupCommand ou une image personnalisée. setupCommand s’exécute une seule fois après la création du conteneur et nécessite un accès réseau sortant, un système de fichiers racine accessible en écriture et un utilisateur root dans l’environnement isolé.

Par défaut, OpenClaw surveille les dossiers de skills et actualise l’instantané lorsque des fichiers SKILL.md changent. Configurez ce comportement sous skills.load :

{  skills: {    load: {      extraDirs: ["~/Projects/agent-scripts/skills"],      allowSymlinkTargets: ["~/Projects/manager/skills"],      watch: true, // default      watchDebounceMs: 250, // default    },  },}

Utilisez allowSymlinkTargets pour les structures utilisant intentionnellement des liens symboliques, lorsqu’un lien symbolique à la racine d’une skill pointe en dehors de la racine configurée, par exemple <workspace>/skills/manager -> ~/Projects/manager/skills. Activez skills.workshop.allowSymlinkTargetWrites uniquement lorsque Skill Workshop doit également appliquer des propositions via ces chemins de liens symboliques approuvés.

Si le Gateway s’exécute sous Linux, mais qu’un node macOS est connecté avec l’autorisation d’utiliser system.run, OpenClaw peut considérer les skills réservées à macOS comme admissibles lorsque les exécutables requis sont présents sur ce node. L’agent doit exécuter ces skills via l’outil exec avec host=node.

Les nodes hors ligne ne rendent pas visibles les skills exclusivement distantes. Si un node cesse de répondre aux sondes d’exécutables, OpenClaw efface de son cache les correspondances d’exécutables pour ce node.