Les skills OpenClaw : guide complet

Introduction

Les skills OpenClaw sont des instructions Markdown qui apprennent à un agent quand et comment utiliser ses tools. Ils sont utiles pour capitaliser une procédure, un format de livrable ou l’usage fiable d’un binaire sans surcharger les instructions générales. Ce ne sont ni des classes Python ni des modules BaseSkill exécutés par un pseudo-SDK. Si vous devez ajouter une capacité runtime, un nouveau tool ou un canal, forcer un simple skill est à éviter : un plugin est plus adapté. Ce guide couvre le fichier SKILL.md, les emplacements, la priorité, les prérequis, les allowlists, ClawHub et la vérification avant production.

Résumé rapide

1. Un skill est un dossier contenant SKILL.md.
2. Le body décrit la procédure ; le frontmatter fournit nom et description.
3. Les skills du workspace ont priorité sur les sources partagées.
4. openclaw skills check explique l’éligibilité et les prérequis.
5. Une allowlist de skills ne remplace pas la sécurité des tools.

Anatomie et cycle de chargement

Un skill fournit une connaissance procédurale au modèle. Il peut référencer des scripts, templates, assets et documents placés dans son dossier, mais l’action réelle passe par les tools, binaires ou plugins accessibles au runtime. Cette séparation est essentielle : SKILL.md dit quoi faire et dans quelles conditions ; la policy décide si l’agent a le droit de le faire.

OpenClaw découvre les skills dans plusieurs racines. Le workspace <workspace>/skills a la priorité la plus élevée pour les fichiers locaux. Viennent ensuite les skills de projet, personnels, managés, embarqués et les répertoires supplémentaires. Un nom identique dans une source prioritaire masque les versions inférieures. En multi-agent, chaque workspace peut donc surcharger un mode opératoire sans modifier le catalogue partagé.

Les skills éligibles sont sélectionnés au démarrage d’une session et peuvent être rafraîchis par le watcher. Les prérequis de système, binaires, variables ou configuration filtrent ce catalogue. Le tutoriel créer un agent OpenClaw montre comment appliquer ces règles à un agent précis.

Créer, installer et gouverner les skills

Structure minimale

~/.openclaw/workspace/skills/rapport-hebdo/
├── SKILL.md
├── references/
├── scripts/
└── templates/

Seul SKILL.md est obligatoire. Utilisez les sous-dossiers pour éviter d’enfouir des exemples longs dans les instructions principales.

Frontmatter et instructions

name: rapport-hebdo
description: Prépare un rapport hebdomadaire vérifié à partir des notes du workspace.

**Rapport hebdomadaire**

Utiliser ce skill quand l’utilisateur demande la synthèse de la semaine.

1. Lire les notes datées.
2. Distinguer faits, décisions et points bloqués.
3. Produire le format de `templates/rapport.md`.
4. Relire les dates et signaler toute information manquante.

Le nom doit utiliser minuscules, chiffres et tirets. La description tient sur une ligne et indique clairement le déclencheur. Le body doit définir l’entrée, les étapes, la validation et les limites.

Vérifier la découverte

openclaw skills list
openclaw skills info rapport-hebdo
openclaw skills check

Avec plusieurs agents, ajoutez --agent <id>. list montre le catalogue, info détaille un skill et check explique pourquoi il est prêt ou filtré. Testez ensuite avec openclaw agent --agent main --message "Utilise le skill rapport-hebdo".

Appeler explicitement un skill

Dans les surfaces compatibles, un utilisateur autorisé peut référencer $rapport-hebdo dans son prompt ou utiliser la commande du skill. Cette explicitation réduit l’ambiguïté, mais l’agent doit toujours respecter les tools et policies disponibles.

Installer depuis ClawHub ou Git

openclaw skills search "calendar"
openclaw skills install @owner/slug
openclaw skills verify @owner/slug

Une installation communautaire doit être traitée comme du code potentiellement dangereux, surtout si elle embarque des scripts. Vérifiez l’identité du publisher, la provenance, les fichiers, les binaires demandés et les effets de bord. Une installation globale rend le skill visible à plusieurs agents selon leurs allowlists.

Configurer l’éligibilité

Le frontmatter peut déclarer des binaires, variables, chemins de configuration ou systèmes requis. Ces gates évitent de montrer au modèle une procédure impossible à exécuter. Ils ne transmettent pas automatiquement un secret au sandbox. Les credentials doivent être gérés par la configuration et la policy adaptées.

Restreindre par agent

agents.defaults.skills définit une base, tandis que agents.entries.<id>.skills remplace cette base pour un agent. Une liste vide cache tous les skills. Ne supposez pas qu’un skill absent désactive le tool correspondant : contrôlez aussi tools.allow, tools.deny, le sandbox et les permissions du système.

Utiliser Skill Workshop

Quand l’agent repère une procédure réutilisable, Skill Workshop permet de créer une proposition au lieu d’écrire directement dans le catalogue actif :

openclaw skills workshop list
openclaw skills workshop inspect <proposal-id>
openclaw skills workshop evaluate <proposal-id>
openclaw skills workshop apply <proposal-id>

L’opérateur relit la proposition, les fichiers de support et les prérequis avant application. Cette file de revue réduit les modifications silencieuses de comportements partagés.

Skill ou plugin ?

Utilisez un skill pour enseigner l’usage d’un tool existant, ordonner une procédure ou imposer un format. Utilisez un plugin TypeScript pour enregistrer un nouveau tool, un provider, un canal, un hook ou un service runtime. Un plugin peut livrer un skill qui documente son tool ; les deux couches sont complémentaires.

Checklist de recette

• nom et description précis ;
• aucune clé dans le contenu ;
• prérequis déclarés ;
• skills check positif ;
• tools minimaux ;
• scénario nominal vérifié ;
• erreur et refus testés ;
• provenance revue avant partage.

Repère opérationnel supplémentaire

Le Gateway doit rester le point de référence opérationnel. Il porte les sessions, les connexions aux canaux et le routage ; un redémarrage ou une panne affecte donc toutes les surfaces qui en dépendent. En production, supervisez le processus, conservez une procédure de redémarrage, puis vérifiez son état avec openclaw gateway status. Les automations exigent elles aussi un Gateway actif au moment prévu. Cette topologie est plus simple à exploiter qu'une collection de scripts dispersés, mais elle impose de traiter le Gateway comme un service durable et non comme une commande ponctuelle.

Repère opérationnel supplémentaire

Le workspace facilite l'organisation, mais ce n'est pas une frontière de sécurité. Il fournit le répertoire de travail, les instructions, les skills et les fichiers de mémoire ; sans sandbox, un outil autorisé peut encore atteindre d'autres chemins de l'hôte. Pour un assistant exposé à plusieurs personnes, limitez les outils, activez l'isolation adaptée et séparez les Gateway lorsque les utilisateurs ne partagent pas le même niveau de confiance. Une allowlist de skills réduit ce que le modèle voit, mais ne remplace jamais une politique d'exécution shell.

Repère opérationnel supplémentaire

La validation doit porter sur un effet observable. Après une modification, lancez une demande courte, vérifiez le fichier ou le message produit, puis consultez les logs et l'historique de session en cas d'écart. Évitez de conclure qu'une opération a réussi uniquement parce que la CLI n'a pas retourné d'erreur. Pour les actions avec effets de bord, ajoutez une étape de lecture après écriture, un identifiant d'exécution et une règle d'idempotence. Cela réduit les doublons lors d'un retry ou d'une reprise après interruption.

Repère opérationnel supplémentaire

Les coûts et la latence dépendent davantage du modèle, du volume de contexte et du nombre d'appels d'outils que du nombre de fichiers de configuration. Commencez avec une mission étroite, un petit jeu de skills et une session clairement délimitée. Mesurez ensuite le temps de réponse, les appels échoués et la qualité de la sortie avant d'ajouter des agents ou des automatisations. Un workflow déterministe reste préférable lorsque la tâche se résume à transformer une entrée connue selon des règles stables.

Repère opérationnel supplémentaire

Les changements de configuration méritent une discipline de maintenance. Modifiez une seule dimension à la fois, gardez une copie exploitable, lancez openclaw doctor, puis redémarrez le Gateway seulement lorsque le changement l'exige. Le fichier est validé strictement : une clé inconnue ou une structure invalide peut empêcher le démarrage. La Control UI et openclaw config get sont utiles pour lire l'état effectif au lieu de raisonner sur un extrait ancien ou une valeur supposée.

Repère opérationnel supplémentaire

La sécurité commence avant le prompt. Restreignez les expéditeurs autorisés, conservez l'écoute réseau sur loopback tant qu'un accès distant n'est pas nécessaire, protégez l'authentification du Gateway et auditez régulièrement l'installation avec openclaw security audit --deep. Les contenus reçus, les pages consultées et les résultats d'outils doivent être considérés comme non fiables. Donnez à chaque agent uniquement les capacités nécessaires et préférez des identifiants dédiés pour les services externes.

Repère opérationnel supplémentaire

La mémoire OpenClaw est explicite : les faits durables vivent dans MEMORY.md, les préférences stables dans USER.md et les notes courantes dans memory/. Cette lisibilité facilite l'audit et la correction, mais oblige à surveiller ce qui est conservé. Ne placez ni secret ni jeton dans ces fichiers. Une information sensible copiée dans une conversation peut aussi se retrouver dans un transcript ; appliquez donc une politique de rétention et nettoyez les données avant de partager des diagnostics.

Repère opérationnel supplémentaire

Dans un déploiement multi-agent, chaque agent doit conserver son propre workspace, son répertoire d'état et son historique. Les bindings choisissent l'agent à partir du canal, du compte ou du correspondant. Cette séparation évite les collisions de sessions et permet des identités distinctes, mais elle ne crée pas une isolation hostile à l'intérieur d'un même Gateway. Pour des équipes ou clients qui ne se font pas confiance, utilisez des Gateway et, si nécessaire, des utilisateurs système ou des hôtes séparés.

Exemple concret

Une équipe répète chaque vendredi la même clôture éditoriale. Elle crée ~/.openclaw/workspace/skills/cloture-editoriale/SKILL.md. Le document indique quand se déclencher, quelles notes lire, comment distinguer les articles publiés des brouillons et quel tableau produire. Un template fixe les colonnes ; aucune clé ni logique réseau n’est placée dans le skill.

L’opérateur exécute openclaw skills info cloture-editoriale, puis openclaw skills check. Il ouvre une nouvelle session et demande explicitement $cloture-editoriale. Après le run, il compare les totaux du rapport aux fichiers sources avec un script déterministe. Il teste ensuite un workspace sans notes : le skill doit signaler l’absence de données au lieu d’inventer. Quand l’agent propose d’ajouter une règle issue de l’expérience, l’équipe passe par Skill Workshop, inspecte la proposition et ne l’applique qu’après revue. Cet exemple prouve qu’un skill est une procédure gouvernée, non une classe exécutable autonome.

Bonnes pratiques

Écrivez des instructions orientées décision : quand charger le skill, quelles sources accepter, quelles actions demander aux tools et comment vérifier le résultat. Gardez le fichier principal court et déplacez les détails stables dans references/. Déclarez les binaires et variables nécessaires afin que openclaw skills check détecte les environnements incomplets.

Traitez les skills communautaires et leurs scripts comme une dépendance de supply chain. Vérifiez leur provenance et leur contenu avant installation. En production, testez un scénario nominal et un cas d’échec, puis contrôlez la sortie réelle. Enfin, rappelez dans votre checklist qu’une allowlist de skills ne bloque pas un tool autorisé : sandbox, credentials et policy restent les frontières effectives.

Questions fréquentes

Qu’est-ce qu’un skill OpenClaw ?

Un skill OpenClaw est un dossier contenant un fichier SKILL.md avec frontmatter YAML et instructions Markdown. Il enseigne à l’agent comment utiliser des tools ou suivre une procédure. Il ne s’agit pas d’une classe Python dotée d’une méthode run() ou execute().

Où placer un skill OpenClaw personnalisé ?

Pour un agent, placez-le sous <workspace>/skills/<nom>/SKILL.md, par exemple dans le workspace par défaut. Les skills partagés peuvent vivre dans le répertoire d’état managé. Le choix du chemin détermine la portée et la priorité, puis les allowlists déterminent la visibilité.

Comment vérifier un skill OpenClaw ?

Utilisez openclaw skills list, openclaw skills info <nom> et openclaw skills check. Avec plusieurs agents, précisez --agent <id>. Testez ensuite le skill dans une nouvelle session et vérifiez l’effet produit, pas seulement sa présence dans la liste.

Quelle différence entre un skill et un plugin OpenClaw ?

Un skill fournit des instructions au modèle pour employer des capacités existantes. Un plugin ajoute réellement des tools, canaux, providers, hooks ou services au runtime Node/TypeScript. Pour une API externe nouvelle, le plugin porte souvent le client et le secret ; le skill explique son usage sûr.

Articles liés

Les skills OpenClaw transforment l’expérience en procédures relisibles et partageables, à condition de rester séparés des capacités runtime et des secrets. Commencez par un skill local étroit, vérifiez-le, puis utilisez Workshop ou ClawHub avec une revue explicite.

• Exemples de skills OpenClaw
• Connecter une API avec OpenClaw
• Créer un agent OpenClaw
• Configurer OpenClaw
• Guide complet OpenClaw