10 exemples de skills OpenClaw concrets
Découvrez 10 exemples de skills OpenClaw fondés sur SKILL.md : veille, support, release, incident, reporting et automatisations vérifiables.
Introduction
Ces exemples skills OpenClaw montrent des procédures SKILL.md concrètes pour la veille, le support, les releases, les incidents et le reporting. Ils sont utiles si votre agent possède déjà les tools ou plugins nécessaires et que vous voulez rendre leur usage reproductible. Ils ne contiennent pas de classes Python BaseSkill : un skill documente une méthode, tandis que le runtime exécute les actions. Si aucune capacité existante ne sait joindre votre service, un skill seul est inutile ; créez ou installez plutôt un plugin. Le but est de choisir dix patterns réalistes, avec déclencheur, preuve attendue et garde-fous de production.
Résumé rapide
- Chaque exemple correspond à un dossier et un
SKILL.md. - Le skill décrit déclencheur, étapes, validation et refus.
- Les tools ou plugins réalisent les effets de bord.
- Commencez localement avant de partager via ClawHub.
- Vérifiez chaque résultat et testez au moins un cas d’échec.
Comment lire ces exemples
Les exemples ne sont pas des modules prêts à appeler une API arbitraire. Ils supposent que l’agent dispose déjà des tools adaptés : lecture de fichiers, recherche web, messagerie, exécution contrôlée ou tool fourni par un plugin. Le skill rend leur enchaînement prévisible et explique les limites.
La structure commune tient en quatre questions : quand utiliser la procédure, quelles entrées accepter, quelles étapes suivre et comment prouver la réussite. Pour un effet de bord, ajoutez une confirmation ou une lecture après écriture. Pour une collecte, imposez des sources et un traitement des données manquantes. Pour une automation, précisez l’idempotence et la livraison.
Le guide des skills OpenClaw détaille le format, les chemins et les gates. Ici, les dix idées servent de points de départ à adapter à votre workspace et à vos tools réels.
Dix skills à adapter à votre workspace
1. Veille sectorielle
Déclencheur : demande de synthèse sur un thème et une période. Le skill impose de rechercher, dater, dédupliquer et distinguer faits et commentaires. La validation vérifie que chaque point renvoie à une source consultée et qu’aucune date n’est inventée.
2. Revue de pull request
Déclencheur : demande de revue dans un dépôt autorisé. Le skill ordonne lecture du diff, exécution des tests ciblés, recherche de risques puis rapport par sévérité. Il interdit de modifier le code sans demande explicite et exige de citer fichiers et lignes.
3. Préparation de release
Déclencheur : version candidate identifiée. Le skill lit les changements, vérifie les tests et prépare les notes. Il sépare préparation et publication : aucune release n’est créée sans approbation. La preuve attendue est un artefact de release relu.
4. Triage support
Déclencheur : ticket entrant. La procédure extrait produit, urgence, reproduction et impact, puis cherche une réponse dans la base autorisée. Elle ne ferme jamais le ticket seule. En l’absence de preuve, elle escalade avec les questions manquantes.
5. Rapport hebdomadaire
Déclencheur : fin de semaine ou automation planifiée. Le skill agrège les notes du workspace, calcule les totaux avec un outil déterministe et produit un tableau stable. Le test compare les comptes du rapport aux sources avant livraison.
6. Incident de production
Déclencheur : alerte ou demande d’investigation. Le skill commence en lecture seule, fixe une fenêtre temporelle, rassemble logs et changements récents, puis formule des hypothèses. Toute commande de remédiation demande confirmation et inclut un rollback.
7. Nettoyage de boîte de réception
Déclencheur : demande de tri sur un compte autorisé. La procédure classe, propose des réponses et demande validation avant envoi ou suppression. Elle masque les secrets et ne copie pas le contenu intégral dans les logs.
8. Contrôle de contenu
Déclencheur : brouillon présent dans le workspace. Le skill vérifie structure, claims, liens et ton, exécute les validateurs disponibles puis rend un rapport. Il distingue les erreurs bloquantes des suggestions et ne publie pas.
9. Inventaire de dépendances
Déclencheur : audit d’un projet. Le skill lit les manifests, identifie les versions et licences, puis vérifie les mises à jour via les tools autorisés. Il ne modifie aucun lockfile et signale les sources non vérifiables.
10. Sauvegarde contrôlée
Déclencheur : demande explicite ou automation. La procédure définit le périmètre, exclut secrets et caches, lance la copie via un tool autorisé, calcule un checksum et vérifie la restauration d’un petit échantillon. Une notification sans preuve de lecture n’est pas considérée comme un succès.
Modèle commun de SKILL.md
name: rapport-hebdo
description: Produit et vérifie le rapport hebdomadaire depuis les notes du workspace.
**Rapport hebdomadaire**
**Quand utiliser**
Utiliser à la demande du propriétaire ou depuis l’automation dédiée.
**Procédure**
1. Lire les notes de la période.
2. Construire les totaux avec l’outil déterministe disponible.
3. Produire le rapport depuis le template.
4. Relire les sources et les totaux.
**Garde-fous**
Ne pas envoyer le rapport si la validation échoue. Ne jamais inclure de secret.
Installation et test
Créez le dossier sous <workspace>/skills, puis lancez :
openclaw skills info rapport-hebdo
openclaw skills check
openclaw agent --agent main --message "Utilise le skill rapport-hebdo sur les notes de test"
Pour une version partagée, passez par Skill Workshop ou installez un paquet revu. Le tutoriel API skills explique quand un plugin est requis.
Automatiser sans perdre le contrôle
Une automation peut déclencher le rapport ou la veille, mais le Gateway doit rester actif. Listez les jobs et inspectez les runs. Pour les actions irréversibles, gardez une approbation humaine, une clé d’idempotence et une étape de lecture après écriture.
Checklist de sélection
Choisissez un exemple dont les tools existent déjà, dont le périmètre est borné et dont la réussite peut être observée. Si vous ne savez pas formuler un cas négatif, le skill est probablement trop vague.
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.
Exemple concret
Vous adaptez le pattern « incident de production ». Créez un skill local qui autorise seulement la collecte des logs d’un service test. Le document demande une fenêtre de quinze minutes, un identifiant d’incident et une sortie structurée : symptômes, changements récents, hypothèses, preuves et prochaine action. Il interdit toute commande d’écriture.
Lancez openclaw skills check --agent ops, puis un tour sur un jeu de logs connu contenant une erreur réseau et un redémarrage. Vérifiez que le rapport cite les deux événements sans conclure à une cause certaine. Lancez ensuite un second test demandant de redémarrer le service : la policy doit refuser l’action ou demander une approbation selon votre configuration. Enfin, comparez le rapport à une checklist manuelle et conservez l’identifiant de session. Ce test prouve que le skill améliore la méthode d’investigation sans transformer un texte Markdown en accès production implicite.
Bonnes pratiques
Un bon exemple commence par un tool existant et un résultat vérifiable. N’écrivez pas « appeler l’API » si aucun plugin ou outil HTTP autorisé ne le permet. Ajoutez toujours les conditions d’arrêt, les données manquantes et la preuve attendue. Pour les messages, créations ou suppressions, utilisez une confirmation et une lecture après écriture.
Gardez les secrets hors du skill et des exemples. Limitez les scripts embarqués, relisez-les comme du code et déclarez leurs binaires. Votre checklist doit inclure openclaw skills check, un scénario nominal, un cas d’échec et l’inspection des effets. Avant de partager sur ClawHub, faites une revue de supply chain et retirez toute hypothèse propre à votre machine.
Questions fréquentes
Quels sont les meilleurs exemples de skills OpenClaw ?
Les meilleurs exemples correspondent à des procédures répétées et vérifiables : veille, revue de code, préparation de release, triage support, rapport, incident ou sauvegarde. Le choix dépend des tools disponibles. Un skill ne doit pas prétendre fournir une capacité runtime absente.
Peut-on copier un exemple de skill OpenClaw tel quel ?
Utilisez-le comme structure, puis adaptez les chemins, tools, politiques, preuves et cas d’échec à votre environnement. Vérifiez avec openclaw skills check et testez sur des données sans risque. Ne copiez jamais de secrets ni une commande destructive non comprise.
Comment combiner plusieurs skills OpenClaw ?
Le modèle peut choisir plusieurs skills éligibles ou l’utilisateur peut les référencer explicitement. Gardez toutefois chaque skill centré sur une procédure. Si un enchaînement doit être strict, placez les étapes déterministes dans un script ou un plugin et utilisez le skill pour cadrer son invocation.
Un skill OpenClaw peut-il appeler une API ?
Il peut expliquer comment employer un tool HTTP ou un tool de plugin déjà disponible. Le skill lui-même n’ajoute pas de client runtime ni de permission. Pour une intégration durable avec schéma, authentification et traitement d’erreurs, un plugin TypeScript est généralement la bonne couche.
Articles liés
Ces dix exemples montrent que la valeur d’un skill vient de la procédure, des limites et de la preuve, non d’une classe Python. Choisissez un seul cas, adaptez-le aux tools réels de votre agent, puis validez-le avant de l’automatiser.
Restez informé sur les agents IA
Nouveaux tutoriels, comparatifs et guides pratiques directement dans votre boîte mail.