Skills personnalisés dans Claude : le guide simple pour créer, tester et packager votre Skill.md comme un pro

Les Skills personnalisés dans Claude, c’est quoi exactement ?

Si vous utilisez Claude régulièrement, vous avez forcément déjà vécu ce moment : vous lui redemandez pour la 12e fois d’appliquer votre ton de marque, de respecter votre structure de reporting, ou de sortir un tableau propre comme un sou neuf.

Les Skills personnalisés servent précisément à ça : apprendre à Claude vos règles du jeu, pour qu’il les applique de façon fiable, sans que vous ayez à répéter les mêmes consignes à chaque conversation. En clair, vous transformez Claude en collègue ultra réglo qui suit vos process… sans demander une augmentation.

Bonne nouvelle : les Skills sont disponibles pour les plans gratuit, Pro, Max, Team et Enterprise, à condition d’avoir l’exécution de code activée si vous voulez aller au-delà du simple Markdown.

Dans cet article, on va voir comment :

  • créer un Skill.md bien structuré
  • rédiger des métadonnées qui déclenchent le Skill au bon moment
  • ajouter des ressources (documents, références)
  • ajouter des scripts exécutables si besoin
  • zipper le tout correctement
  • tester et itérer sans s’arracher les cheveux

Pourquoi créer un Skill (et pas juste un prompt réutilisable) ?

Un prompt réutilisable, c’est pratique, mais ça reste fragile : vous devez penser à le coller, à le maintenir, à l’adapter. Un Skill, lui, est conçu pour être déclenché automatiquement quand la situation s’y prête.

Les meilleurs Skills :

  • résolvent une tâche spécifique et répétable
  • ont des instructions claires et actionnables
  • incluent des exemples quand c’est utile
  • définissent quand ils doivent être utilisés
  • se concentrent sur un workflow au lieu de vouloir tout faire

Autrement dit : un Skill, c’est un mini système. Pas un fourre-tout.

Le coeur du système : créer un fichier Skill.md

Chaque Skill est un dossier qui contient au minimum un fichier Skill.md. C’est votre pièce maîtresse : Claude va s’en servir pour savoir quoi faire et quand.

Le fichier doit commencer par un préambule YAML, qui contient des métadonnées. Certaines sont obligatoires.

Les métadonnées obligatoires

Vous devez impérativement fournir :

  • name : le nom convivial de votre Skill (64 caractères max)
  • description : la description de ce que fait le Skill et quand l’utiliser (200 caractères max)

La description est capitale : Claude s’en sert pour décider s’il doit charger votre Skill. Si elle est vague, votre Skill risque de dormir comme un onglet oublié.

Exemples efficaces :

  • name : Directives de marque
  • description : Appliquer les directives de marque d’Acme Corp aux présentations et documents, incluant couleurs, polices et usage du logo.

Les métadonnées optionnelles (mais souvent utiles)

Vous pouvez aussi ajouter :

  • dependencies : les packages requis

Exemple :

  • python>=3.8, pandas>=1.5.0

Ces métadonnées servent de premier niveau dans une logique de divulgation progressive : Claude lit d’abord le strict nécessaire pour décider si le Skill s’applique, puis seulement ensuite il va lire le contenu détaillé.

Le corps Markdown : vos consignes, votre méthode, vos exemples

Une fois les métadonnées en place, vous rédigez le contenu Markdown. C’est le deuxième niveau : Claude y accède lorsqu’il a déjà décidé que le Skill vaut la peine d’être consulté.

Ici, l’idée est simple :

  • clarifier l’objectif
  • donner des règles
  • préciser les cas d’usage
  • fournir des exemples d’entrée et de sortie

Exemple de Skill.md orienté directives de marque

Voici le type de structure qui fonctionne très bien :

  • aperçu du Skill
  • règles de couleurs
  • typographie
  • usage du logo
  • quand appliquer
  • ressources disponibles

Ce format est particulièrement efficace pour les équipes marketing, contenu, design, sales enablement, ou toute boîte qui veut arrêter de publier des documents en Comic Sans par accident.

Ajouter des ressources : quand Skill.md ne suffit plus

Parfois, votre Skill devient trop gros ou trop spécifique. Exemple :

  • un référentiel de style complet
  • des cas particuliers selon les équipes
  • des annexes réglementaires

Dans ce cas, vous pouvez ajouter des fichiers dans le dossier du Skill, comme :

  • REFERENCE.md
  • CHECKLIST.md
  • FAQ.md
  • exemples de documents

L’astuce : référencez ces fichiers depuis Skill.md, pour que Claude sache qu’ils existent et aille les lire seulement si nécessaire.

Résultat : votre Skill reste lisible, mais il peut devenir très riche.

Ajouter des scripts : passer en mode Skill avancé

C’est là que ça devient intéressant pour l’automatisation. Un Skill peut inclure des fichiers de code exécutables qui permettent à Claude de lancer des traitements.

Exemples d’usages :

  • analyser un CSV avec Python
  • générer un graphique avec matplotlib
  • transformer un document via un script
  • faire un traitement Node.js

Les langages et packages cités comme courants :

  • Python (pandas, numpy, matplotlib)
  • JavaScript et Node.js
  • outils d’édition de fichiers
  • outils de visualisation

Point important sur les dépendances

Claude et Claude Code peuvent installer des packages depuis des dépôts standard (PyPI, npm) lors du chargement de Skills.

Mais pour les Skills via API utilisant l’outil d’exécution de code : pas d’installation à l’exécution. Les dépendances doivent être préinstallées dans le conteneur.

Donc si vous visez une compatibilité API, restez raisonnable côté dépendances.

Empaqueter votre Skill : le ZIP qui peut tout gâcher

Oui, on a tous déjà eu un zip “presque bon”. Et non, Claude ne devine pas ce que vous vouliez faire.

Checklist d’empaquetage :

  1. le dossier du Skill doit avoir le même nom que le Skill
  2. créez un fichier ZIP du dossier
  3. le ZIP doit contenir le dossier Skill comme racine (pas les fichiers directement)

Structure correcte

  • my-Skill.zip
  • my-Skill/
    • Skill.md
    • resources/

Structure incorrecte

  • my-Skill.zip
  • Skill.md
  • resources/

Si votre Skill ne se charge pas, ce détail fait partie du top 3 des suspects.

Tester votre Skill : avant et après le téléchargement

Un Skill, c’est comme une recette : tant que vous n’avez pas goûté, vous ne savez pas si c’est bon.

Avant de télécharger

  • relisez Skill.md pour la clarté
  • vérifiez que la description reflète précisément quand le Skill s’applique
  • vérifiez que tous les fichiers référencés existent
  • testez avec des prompts d’exemple pour voir si Claude l’invoque

Astuce : préparez 5 à 10 prompts typiques. Puis 2 ou 3 prompts “pièges” où il ne devrait pas se déclencher.

Après le téléchargement sur Claude

Une fois uploadé :

  1. activez le Skill dans Personnaliser puis Skills
  2. testez plusieurs invites qui devraient le déclencher
  3. vérifiez la réflexion de Claude pour confirmer qu’il charge le Skill
  4. itérez sur la description si Claude ne l’utilise pas au bon moment

Pour les plans Team et Enterprise : vous pouvez ensuite provisionner le Skill pour l’organisation afin de le rendre disponible à tous.

Bonnes pratiques : ce qui sépare un Skill utile d’un Skill “meh”

Restez focalisé

Un Skill = un workflow. Si vous essayez d’englober tous les process de votre boîte dans un seul Skill, vous allez obtenir un mini ERP en Markdown. Et ce n’est pas un compliment.

Créez plusieurs Skills spécialisés :

  • un Skill “rédaction SEO”
  • un Skill “compte rendu de réunion”
  • un Skill “analyse de données”
  • un Skill “brand voice”

Claude peut en activer plusieurs automatiquement, même s’ils ne se référencent pas explicitement entre eux. C’est l’un des gros points forts : la composabilité.

Écrivez des descriptions chirurgicales

La description est votre déclencheur. Soyez spécifique :

  • “à utiliser pour les emails clients sortants”
  • “à utiliser pour les rapports hebdomadaires au format X”
  • “à utiliser quand on analyse des fichiers CSV de ventes”

Évitez : “aide à rédiger” ou “améliore les textes”. Claude ne sait pas quand appuyer sur le bouton.

Commencez simple

Faites une version 1 uniquement en Markdown. Ajoutez du code ensuite.

Vous gagnerez du temps, et vous éviterez de déboguer un script alors que le problème venait juste d’une description trop floue.

Ajoutez des exemples

Un bon exemple vaut 20 lignes de règles. Ajoutez :

  • une entrée attendue
  • une sortie attendue
  • un mini contre-exemple si nécessaire

Votre Skill devient plus prédictible, et Claude comprend mieux la notion de réussite.

Testez de façon progressive

Testez après chaque modification importante. Sinon, quand ça casse, vous ne saurez pas si c’est :

  • la description
  • la structure
  • une ressource manquante
  • un script
  • une dépendance

Et là, votre debug se transforme en enquête policière.

Suivez la spécification ouverte Agent Skills

Si vous voulez des Skills portables et alignés avec une norme, jetez un oeil aux recommandations sur agentskills.io. C’est utile si vous travaillez dans un écosystème multi outils.

Sécurité : ne donnez pas les clés du coffre à un fichier ZIP

Les Skills peuvent exécuter du code. Donc les règles de base s’appliquent :

  • soyez prudent avec les scripts
  • ne mettez jamais d’informations sensibles en dur (clés API, mots de passe)
  • vérifiez les Skills avant activation, surtout s’ils viennent d’ailleurs
  • utilisez les connexions MCP appropriées pour accéder à des services externes

Un Skill pratique n’a pas besoin d’être un Skill dangereux.

Idées de Skills concrets pour démarrer (et gagner du temps dès aujourd’hui)

Si vous cherchez l’inspiration, voici des exemples de Skills très rentables :

Skill “Brand Voice et rédaction”

  • applique un ton
  • impose une structure
  • vérifie les interdits (mots à éviter)
  • propose un titre et des variantes

Skill “Compte rendu de réunion”

  • transforme des notes brutes en CR
  • extrait décisions et actions
  • génère une checklist de suivi

Skill “Analyse CSV express”

  • charge un fichier
  • calcule KPI
  • produit graphiques simples
  • propose interprétation et pistes d’action

Skill “QA interne sur docs”

  • s’appuie sur REFERENCE.md
  • répond selon votre politique interne
  • cite la section pertinente

Pour voir des modèles prêts à l’emploi, il existe aussi un dépôt GitHub avec des exemples de Skills à consulter.

Mini checklist finale avant de publier votre Skill

  • un name clair et court
  • une description précise qui indique quand l’utiliser
  • un Skill.md lisible avec sections et règles
  • des ressources ajoutées si nécessaire
  • des scripts uniquement si vous en avez vraiment besoin
  • des dépendances explicites
  • un ZIP avec la bonne structure
  • une série de tests avant et après upload

Si vous respectez ça, votre Skill a de grandes chances de devenir un vrai accélérateur de productivité, et pas un fichier que vous oubliez dans un dossier “finalv7definitif”.

Source : Skills personnalisés dans Claude : le guide simple pour créer, tester et packager votre Skill.md comme un pro