Créer un skill Claude qui marche : 5 règles essentielles

10 avril 2026

80% des skills Claude sont ignorés par le modèle parce qu'ils sont mal structurés. Tu empiles des instructions depuis des mois dans un fichier CLAUDE.md de 500 lignes. Tu rajoutes une règle à chaque bug. Et Claude se noie dans le bruit. Il ignore la moitié de ce que tu lui as écrit.

Le problème, ce n'est pas Claude. C'est l'architecture de tes instructions. La différence entre un skill amateur et un skill pro tient à 5 principes simples que très peu de gens expliquent correctement sur le marché.

Dans cet article, tu vas découvrir :

• Pourquoi un skill est un employé spécialisé (et pas juste un fichier markdown)
• Les 5 règles d'or issues du code source leaké de Claude Code
• La différence concrète entre un skill 1.0 et un skill 2.0
• Un plan d'action en 12 minutes pour créer ton premier skill pro

Ce n'est pas magique. Mais si tu appliques ces principes, Claude activera tes skills au bon moment, suivra tes instructions et arrêtera de te poser des questions inutiles qui consomment tes tokens.

Qu'est-ce qu'un skill Claude exactement ?

Beaucoup font l'erreur de penser qu'un skill, c'est juste un fichier. Un fichier markdown qu'on pose dans un dossier et qui fait son travail. Non.

Un skill, c'est un employé spécialisé. Il y a une différence fondamentale entre donner des instructions en vrac et former un spécialiste. Un bon skill, c'est un employé qui sait quoi faire sans te poser mille questions par jour.

Concrètement, quand cet employé virtuel te pose des questions inutiles parce que ses instructions sont mal structurées, ça ne consomme pas de l'énergie. Ça consomme des tokens. Et les tokens, c'est de l'argent.

Point important : les skills ne sont pas réservés à Claude. Le concept s'applique à Claude AI (web et desktop), Claude Code, mais aussi Cursor, Gemini CLI ou Codex. Ce sont des dossiers et des fichiers d'instructions. L'objectif final d'un bon skill, c'est qu'il puisse fonctionner partout, peu importe l'outil. C'est ce qu'on appelle l'universalité.

Pourquoi ne pas confondre CLAUDE.md et skills ?

Quand on débute, les termes s'empilent. CLAUDE.md, skills, front matter, références. Ça peut sembler un bordel sans nom. Posons les bases clairement.

Le fichier CLAUDE.md

• Fichier unique, plus ou moins volumineux selon ta méthode
• Chargé à chaque session, même quand ce n'est pas utile
• Tout est mélangé : style, règles techniques, préférences
• Pas de chargement à la demande

Les skills

• Un dossier par compétence
• Chargés à la demande, uniquement quand Claude en a besoin
• Séparés et structurés
• Environ 100 tokens au scan initial (le front matter)

La règle est simple : CLAUDE.md pour les règles globales (langue, tutoiement, conventions). Les skills pour les expertises métier. Si tu crées un skill pour "écrire en français", c'est comme recruter un employé pour allumer la lumière. Même milliardaire, personne ne fait ça.

Comment est structuré un skill pro en 2026 ?

L'anatomie d'un bon skill a évolué. Depuis octobre 2025, on est passé des skills V1 aux skills V2, et la différence est massive.

Skill 1.0 (août 2025)

• Un simple fichier markdown dans Claude Command
• Pas de front matter, pas de chargement intelligent
• Pas de dossier référence
• Invocation uniquement manuelle

Skill 2.0 (depuis octobre 2025)

• Un dossier complet dans la configuration racine
• Front matter YAML (nom + description)
• Chargement progressif en 3 tiers : référence, script, asset
• Invocation automatique ou manuelle (avec la commande slash)

En pratique, un skill 2.0 se compose de 4 éléments :

1. skill.md : le routeur. C'est le seul fichier obligatoire. Il contient le front matter et les instructions. C'est lui qui orchestre tout le reste.
2. Dossier référence : la documentation détaillée chargée à la demande.
3. Dossier script : le code exécutable (Python, etc.).
4. Dossier assets : les templates, exemples, composants HTML.

Prenons un exemple concret. Un skill d'analyse fiscale pour un fiscaliste :

• skill.md : le routeur qui définit les étapes (avant l'analyse, pendant, après)
• Références : règles fiscales 2026, seuils TVA, barèmes IR, checklist bilan, anomalies courantes
• Scripts : parse_liasse.py, check_coherence.py
• Assets : template_rapport.md avec le code couleur et les composants du cabinet

Le skill.md agit comme un orchestrateur. Il dit : "Avant l'analyse, charge les références. Pendant, exécute les scripts. Après, génère le rapport avec l'asset." C'est lui qui donne les instructions de déclenchement, de vérification et de production.

Le chargement en 3 tiers

Claude charge tes skills de manière progressive :

1. Tiers 1 : nom + description. Environ 100 tokens. Toujours chargé.
2. Tiers 2 : si pertinent, il charge le corps du skill.md. Objectif : rester sous 5 000 tokens.
3. Tiers 3 : si nécessaire, il charge les références, scripts et assets.

Le plus intéressant : si tu as 10 skills avec des front matter bien rédigés, Claude peut ne consommer que 1 000 tokens au lieu de 50 000. Dans la communauté LE LABO IA, un membre (Amine) utilise 300 skills qu'il perfectionne depuis plus de 8 mois. Des skills avec 150 fichiers, des scripts Python, des orchestrateurs de skills. De vrais employés numériques.

Quelles sont les 5 règles d'or pour un skill efficace ?

Ces 5 principes font 80% de la différence entre un skill que Claude ignore et un skill qu'il active au bon moment. Certains viennent directement du code source leaké de Claude Code.

Règle 1 : écris à l'impératif

Claude, c'est un employé. Tu lui donnes des ordres, pas des suggestions. Pas "tu pourrais vérifier les tests". Non. "Vérifie les tests avant chaque commit." Point.

• ❌ "Tu pourrais vérifier les tests" → ✅ "Vérifie les tests avant chaque commit"
• ❌ "Il serait bien de documenter" → ✅ "Documente chaque fonction publique"

Nuance importante : l'impératif seul ne suffit pas. Il faut toujours expliquer le pourquoi. Les modèles de langage comprennent mieux les raisons que les ordres rigides. Le skill créateur interne d'Anthropic le dit lui-même : "Explique au modèle pourquoi c'est important, plutôt que d'empiler des musts rigides." Un ordre sans raison, c'est un poulet qui court sans tête.

Règle 2 : la négation seule ne suffit pas

La négation, c'est bien. "Ne fais pas ça." Mais si tu ne proposes pas d'alternative, le cerveau de Claude active d'abord le concept, puis applique la négation. Et le résultat : environ 50% de violations en plus.

• ❌ "Ne modifie jamais les tests" → ✅ "Ne modifie jamais les tests existants. Crée de nouveaux tests à la place"
• ❌ "N'utilise pas console.log" → ✅ "N'utilise pas console.log. Utilise le loggeur du projet"
• ❌ "Ne commite pas sans demander" → ✅ "Ne commite jamais automatiquement. Attends la demande explicite"

Ça paraît bête. On parle d'une vingtaine de caractères en plus. Mais ça change absolument tout. C'est comme avec un enfant de 8 ans : si tu lui dis "ne fais pas ça" sans lui expliquer quoi faire à la place, il est perdu.

Règle 3 : utilise l'architecture indentée

Des instructions plates, au même niveau, sans hiérarchie, c'est le chaos. Claude ne sait pas quand appliquer quelle règle. Il mélange tout.

Ce qu'il ne faut pas faire (structure plate) :

• Vérifie les tests
• Utilise TypeScript
• Vérifie les erreurs
• Documente le code
• Lance le build

Ce qu'il faut faire (architecture indentée avec du markdown) :

• Avant de coder : lis le fichier cible, identifie les tests
• Pendant le code : TypeScript strict, vérifie les types
• Après le code : lance le build, documente

C'est le même contenu. Mais avec une structure temporelle et hiérarchique, Claude sait quand appliquer quelles règles. Utilise les balises H2, H3 en markdown et crée des sections qui correspondent à des phases de travail.

Règle 4 : inclus du code dans tes skills

Un skill, ce n'est pas que du texte. Beaucoup sont restés avec la mentalité des GPTs ou des skills 1.0. En 2026, tu peux et tu dois embarquer des exemples de code.

• JSON : pour les schémas de données attendus, les structures exactes à produire
• Python : pour les scripts mathématiques (fiscalistes, comptables, tout métier avec du calcul)
• HTML : pour les templates de sortie, les composants de charte graphique

Tu peux aussi utiliser des blocs de code entre triple backticks que Claude va reproduire à l'identique. Et le résultat : Claude reproduit tes patterns au lieu de les deviner. C'est la combinaison la plus puissante avec les autres règles. Très peu de gens en parlent sur le marché.

Règle 5 : exploite le dossier référence

S'il y a un dossier plus important que les autres (hors skill.md), c'est celui-là. Le principe est recommandé directement dans le code source leaké de Claude Code.

Le skill.md dit quoi faire. Le dossier référence dit comment en détail.

• Garde ton skill.md court : moins de 500 lignes de préférence
• Déplace dans le dossier référence : documentation détaillée, specs API, exemples longs
• Claude charge ces fichiers à la demande, uniquement quand c'est nécessaire

Ne sois pas rigide sur ce que tu mets dans ce dossier. Tout ce qui est trop long ou trop détaillé pour le skill.md a sa place dans les références.

Comment rendre la description de ton skill "pushy" ?

Claude a tendance à ne pas activer les skills. Il préfère gérer seul. C'est frustrant quand tu débutes, parce que tes skills ne se déclenchent pas au bon moment.

La solution : rendre ta description pushy dans le front matter.

• ❌ Description vague : "Aide avec les documents". Même un humain ne saurait pas quand l'activer.
• ✅ Description pushy : "Extrait le texte des PDF, remplit les formulaires. Utilisé quand l'utilisateur travaille avec des PDF ou mentionne des formulaires."

Avec une description optimisée, l'activation passe de 20% à 90%. Et si tu ajoutes la négation avec alternatives dans le corps du skill, tu t'assures qu'il ne s'activera jamais quand tu ne veux pas.

Tu peux aussi invoquer manuellement un skill avec la commande slash. Par exemple : /lancer-analyse-fiscale. Mais l'objectif, c'est qu'à terme, Claude les déclenche tout seul grâce à un front matter bien rédigé.

Quand créer un skill ou plusieurs skills distincts ?

La question revient souvent. Tu as un workflow complexe : est-ce un seul skill ou trois ?

La règle : si tu peux décrire le skill en une phrase, c'est un skill. Si tu as besoin de trois phrases, c'est trois skills.

Un seul domaine = un skill avec des sous-sections

Exemple : un skill de code review qui couvre la sécurité, la performance et les conventions dans un même flux de travail.

Plusieurs domaines = plusieurs skills

Exemple : deploy + test + review. Trois skills séparés que Claude active selon le contexte.

Quelques exemples par métier :

• Avocat : analyse de contrat, recherche de jurisprudence, rédaction de conclusions (3 skills)
• Concierge : multilingue + réservation + priorisation (3 skills)
• Concessionnaire : devis auto, suivi relance, fiches véhicules (3 skills)
• Fiscaliste : analyse fiscale avec liasses, anomalies et veille dans un flux unique (1 skill)
• SEO : audit SEO, content SEO (2 skills)
• Créateur de contenu : scripts vidéo, SEO, génération de miniatures, planning (plusieurs skills)

Quand tu avanceras en technique, tu pourras créer des orchestrateurs qui combinent 10 skills dans un seul. Mais ça demande un niveau d'architecture avancé. Pour commencer, respecte la règle "une phrase = un skill".

Comment créer ton premier skill pro en 12 minutes ?

Assez de théorie. Voici ton plan d'action concret.

Étape 1 : crée le dossier (0 minute)

Dans ta configuration racine Claude, dans le dossier skills, crée un sous-dossier pour ton skill. Par exemple : skills/analyse-fiscale/.

Étape 2 : écris le front matter (3 minutes)

Rédige le nom et la description pushy. Tu peux te faire aider par une IA pour cette partie. L'essentiel : que la description soit précise, avec les déclencheurs contextuels.

Étape 3 : rédige les instructions (5 minutes)

Dans ton skill.md, applique les 3 règles clés :

• Impératif : des ordres clairs avec le pourquoi
• Sections structurées en markdown : avant, pendant, après
• Négation + alternatives : chaque "ne fais pas" doit avoir un "fais plutôt"

Étape 4 : déplace la doc lourde (2 minutes)

Tout ce qui dépasse 500 lignes ou qui relève de la documentation détaillée va dans le dossier reference/.

Étape 5 : teste avec 5 prompts (2 minutes)

Vérifie que le skill se déclenche automatiquement en langage naturel, et qu'il se déclenche aussi manuellement avec la commande slash. Ajuste la description si l'activation est trop faible.

Et le résultat : tu as une configuration plus solide que 90 à 95% des power users qui utilisent Claude au quotidien.

Skill amateur vs skill pro : la comparaison

Pour synthétiser tout ce qu'on a couvert, voici la différence en un coup d'oeil.

Le skill amateur

• Un skill.md de 347 lignes sans structure
• Pas de front matter
• Tout mélangé dans un seul fichier
• Instructions conditionnelles et vagues
• Négations sans alternatives
• Zéro hiérarchie
• Claude l'ignore 80% du temps

Le skill pro

• Un skill.md de 120 lignes avec 3 dossiers références
• Front matter avec description pushy
• Skill.md propre + références pour les détails
• Instructions à l'impératif avec le pourquoi
• Négation avec alternatives systématiques
• Sections formatées en markdown avec titres hiérarchisés
• Claude l'active automatiquement au bon moment

100 skills amateurs, c'est l'équivalent de 3 ou 4 skills pro. La quantité ne compense pas la qualité de l'architecture.

Meydeey, Architecte IA & Automatisation

+110 entrepreneurs formés au Vibe Coding et à l'automatisation IA. Fondateur du Labo IA, +30K abonnés YouTube.

YouTube LinkedIn Communauté