Un skill Claude Code, c'est un dossier contenant un fichier SKILL.md avec des instructions réutilisables que Claude charge tout seul quand votre tâche correspond, ou que vous déclenchez à la main avec /nom-du-skill. Les Claude Code Skills suivent le standard ouvert Agent Skills, le même format fonctionne donc dans plusieurs outils IA. Contrairement à un fichier CLAUDE.md, toujours chargé en mémoire, le corps d'un skill ne se charge qu'au moment où il sert : votre documentation de référence ne coûte quasiment rien tant que vous n'en avez pas besoin. Concrètement, un skill vous évite de recoller les mêmes consignes dans le chat à chaque session. Voici ce qu'est un skill, comment en installer un, comment créer le vôtre, et surtout quand utiliser un skill plutôt qu'un CLAUDE.md, un slash command ou un MCP.
Qu'est-ce qu'un skill Claude Code ?
Un skill Claude Code est une capacité que vous ajoutez à Claude sous forme de fichier texte. Vous écrivez un SKILL.md, Claude l'ajoute à sa boîte à outils, et il s'en sert quand c'est pertinent. Rien de plus. Pas de plugin à compiler, pas de dépendance à installer : un dossier, un fichier markdown, et c'est actif.
Ce fichier a deux parties. D'abord un bloc de frontmatter YAML entre deux ---, qui contient au minimum une description : c'est elle qui dit à Claude quand utiliser le skill. Ensuite le corps en markdown, qui contient les instructions que Claude suit quand le skill se déclenche. La documentation officielle recommande de garder ce corps sous 500 lignes et de déplacer les longues références dans des fichiers annexes, chargés seulement à la demande.
La vraie question n'est pas « qu'est-ce qu'un skill », c'est « pourquoi ça existe ». Réponse : parce que vous vous répétez. Vous recollez la même checklist de déploiement, le même format de commit, les mêmes conventions d'API dans le chat, session après session. Un skill capture cette procédure une fois. Et là où un CLAUDE.md garde ces instructions en permanence dans le contexte (donc paie leur coût en tokens à chaque tour), le skill ne charge son contenu que lorsqu'il tourne. C'est la différence structurelle à retenir : le CLAUDE.md est une mémoire permanente, le skill est une compétence à la demande.
Détail qui compte pour qui vient de l'ancienne version de Claude Code : les custom commands ont fusionné dans les skills. Un fichier .claude/commands/deploy.md et un skill .claude/skills/deploy/SKILL.md créent tous les deux la commande /deploy et fonctionnent pareil. Vos anciennes commandes continuent de marcher. Les skills ajoutent juste des options en plus : un dossier pour les fichiers annexes, du frontmatter pour contrôler qui déclenche quoi, et la capacité pour Claude de charger le skill automatiquement.
Comment installer et activer un skill
Installer un skill Claude Code, ça veut dire deux choses très différentes selon d'où il vient : soit vous le posez vous-même dans le bon dossier, soit vous l'installez depuis une marketplace de plugins.
Le cas le plus simple : un skill est un dossier, vous le mettez au bon endroit, il s'active. L'emplacement décide de qui peut l'utiliser.
| Emplacement | Chemin | S'applique à |
|---|---|---|
| Personnel | ~/.claude/skills/<nom>/SKILL.md |
Tous vos projets |
| Projet | .claude/skills/<nom>/SKILL.md |
Ce projet uniquement |
| Plugin | <plugin>/skills/<nom>/SKILL.md |
Là où le plugin est activé |
| Entreprise | Via les managed settings | Toute l'organisation |
Un skill personnel vous suit partout. Un skill projet, commité dans .claude/skills/, est partagé avec toute votre équipe via git. Quand un même nom existe à plusieurs niveaux, l'entreprise l'emporte sur le personnel, qui l'emporte sur le projet. Claude Code surveille les dossiers de skills en direct : ajouter ou modifier un SKILL.md sous ~/.claude/skills/ prend effet dans la session en cours, sans redémarrage.
Le second cas : installer depuis une marketplace. Claude Code a un système de plugins officiel. Par exemple, pour installer le plugin skill-creator qui vous aide à construire et tester vos propres skills, vous tapez :
/plugin install skill-creator@claude-plugins-official
Une fois le skill en place, deux façons de l'activer. Vous le déclenchez à la main en tapant /nom-du-skill, ou vous laissez Claude le charger tout seul quand votre demande correspond à sa description. C'est là que la qualité de la description fait tout : si elle contient les mots que vous diriez naturellement, Claude trouve le skill. Sinon, il passe à côté. Pour vérifier qu'un skill est bien reconnu, demandez simplement à Claude « quels skills sont disponibles ? ».
Créer votre propre skill, pas à pas
C'est ici que la plupart des tutoriels FR s'arrêtent à la théorie. Passons au concret. Créons un skill qui résume les changements non commités de votre dépôt git et signale ce qui est risqué. Trois étapes.
1. Créez le dossier. On le met dans les skills personnels, pour qu'il soit dispo sur tous vos projets :
mkdir -p ~/.claude/skills/resume-changements
2. Écrivez le SKILL.md. Le nom du dossier devient la commande que vous tapez. Enregistrez ceci dans ~/.claude/skills/resume-changements/SKILL.md :
---
description: Résume les changements non commités et signale ce qui est risqué. À utiliser quand l'utilisateur demande ce qui a changé, veut un message de commit, ou une revue de son diff.
---
## Changements en cours
!`git diff HEAD`
## Instructions
Résume les changements ci-dessus en deux ou trois puces, puis liste les risques : gestion d'erreur manquante, valeurs codées en dur, tests à mettre à jour. Si le diff est vide, dis qu'il n'y a rien de non commité.
La ligne !`git diff HEAD` est le vrai tour de force. C'est de l'injection de contexte dynamique : Claude Code exécute la commande et remplace la ligne par sa sortie avant même que Claude lise le skill. Résultat : les instructions arrivent avec votre diff réel déjà inséré. Le skill ne raisonne pas sur ce que Claude imagine de votre code, il raisonne sur votre arbre de travail réel. Cette syntaxe !`commande` marche pour n'importe quelle commande shell.
3. Testez. Ouvrez un projet git, modifiez un fichier, lancez claude. Demandez « qu'est-ce que j'ai changé ? » (Claude déclenche le skill tout seul) ou tapez /resume-changements (déclenchement manuel). Dans les deux cas, vous obtenez un résumé de votre édition et une liste de risques.
Vous voulez aller plus loin ? Ajoutez des fichiers annexes dans le dossier : un reference.md avec la doc détaillée, un scripts/ avec un script Python que Claude exécute. Le SKILL.md reste court et pointe vers ces fichiers, qui ne se chargent que quand ils servent. C'est le principe : le skill reste léger, la connaissance lourde attend en coulisses.
CLAUDE.md vs Skills vs Slash Commands vs MCP : lequel pour quoi
Voici la question que tout le monde se pose sur les forums et que personne ne tranche proprement en français. Quatre mécanismes, on les confond, et on utilise le mauvais. Mettons-les à plat.
| Mécanisme | Quand c'est chargé | À quoi ça sert | Comment on déclenche |
|---|---|---|---|
| CLAUDE.md | Toujours, en permanence | Des faits, conventions, contexte stable du projet | Automatique, jamais invoqué |
| Skill | À l'usage seulement | Une procédure ou une connaissance à la demande | /nom ou auto par Claude |
| Slash command | À l'usage, sur votre commande | Une action que vous voulez contrôler | /nom uniquement |
| MCP | Serveur branché en continu | Connecter Claude à des outils et données externes | Claude appelle l'outil |
La logique se résume en une phrase par ligne.
CLAUDE.md, c'est de la mémoire. Des faits que Claude doit toujours avoir sous les yeux : la stack, les conventions de nommage, l'architecture. Toujours chargé, donc à garder court. Si une section de votre CLAUDE.md est devenue une procédure en plusieurs étapes plutôt qu'un fait, c'est le signal : elle doit devenir un skill.
Un skill, c'est une compétence. Une procédure que Claude sort du placard quand elle sert, et range après. Depuis la fusion, un slash command n'est qu'un skill que vous déclenchez à la main : mettez disable-model-invocation: true dans le frontmatter et Claude ne le lancera jamais tout seul (utile pour un /deploy que vous ne voulez surtout pas voir partir parce que « le code a l'air prêt »). À l'inverse, user-invocable: false cache le skill du menu pour n'en laisser l'usage qu'à Claude, pratique pour une connaissance de fond qui n'est pas une action.
Un MCP, c'est une prise. Le Model Context Protocol ne charge pas des instructions, il branche Claude sur un outil ou une source de données externe : votre GitHub, une base de données, un navigateur. C'est la confusion la plus fréquente, alors soyons nets : un skill dit à Claude comment faire quelque chose, un MCP lui donne accès à quelque chose. Vous voulez que Claude suive votre process de revue ? Skill. Vous voulez qu'il lise vos issues GitHub en direct ? MCP. Les deux se complètent, ils ne se remplacent pas.
Les skills les plus utiles pour un founder
Si vous buildez seul ou en petite équipe, vous n'avez pas le temps de réinventer des workflows. Bonne nouvelle : Claude Code arrive avec des skills fournis d'office, prêts à taper. Les plus rentables quand on shippe un MVP :
/code-review: une revue de vos changements avant de merger. Le filet de sécurité que vous n'avez pas quand vous êtes le seul dev./runet/verify: lancent votre app et confirment qu'un changement marche vraiment, au lieu de se fier aux tests. Pour un founder non technique qui n'est jamais sûr que « ça tourne », c'est précieux./debug: de l'aide au diagnostic quand quelque chose casse et que vous ne savez pas par où commencer./doctor: un check-up de votre configuration Claude Code./claude-api: la référence à jour sur les modèles et l'API Claude, utile dès que vous branchez du Claude dans votre produit.
Mais le vrai levier, ce ne sont pas les skills fournis. C'est d'écrire les vôtres, parce qu'ils encodent votre façon de bosser. Trois candidats évidents pour un founder :
- Un skill de commit qui applique votre format de message et scanne le diff avant de committer (comme l'exemple plus haut, en version étendue).
- Un skill de conventions produit : votre design system, vos règles d'API, votre ton de copie. Claude les applique sans que vous les recolliez.
- Un skill de déploiement en
disable-model-invocation: true, pour garder la main sur le timing.
Et si vous voulez industrialiser, le plugin skill-creator va plus loin : il génère des cas de test, lance chaque skill dans un sous-agent isolé, et compare le résultat avec et sans skill. Vous ne devinez pas si votre skill marche, vous le mesurez. C'est exactement la discipline qu'on applique en interne chez swanbase quand on outille les founders qu'on accompagne : un workflow qu'on ne mesure pas est un workflow qu'on croit efficace.
Un dernier réflexe. Un skill n'est utile que si Claude le trouve. La cause numéro un d'un skill qui « ne se déclenche pas » n'est pas un bug, c'est une description trop vague. Écrivez-la avec les mots que vous diriez vraiment, pas avec du jargon. La description est le seul pont entre votre besoin et votre skill.
Pour aller plus loin
FAQ
Qu'est-ce qu'un skill dans Claude Code ?
Un skill est un dossier contenant un fichier SKILL.md (frontmatter YAML plus instructions markdown) qui étend ce que Claude sait faire. Claude le charge automatiquement quand la tâche correspond à sa description, ou vous le déclenchez à la main avec /nom-du-skill. Les skills suivent le standard ouvert Agent Skills, donc le même fichier fonctionne dans plusieurs outils IA.
Comment installer un skill dans Claude Code ?
Deux façons. Soit vous placez le dossier du skill au bon endroit : ~/.claude/skills/<nom>/ pour un usage sur tous vos projets, ou .claude/skills/<nom>/ pour un seul projet. Soit vous l'installez depuis une marketplace de plugins, par exemple /plugin install skill-creator@claude-plugins-official. Claude Code détecte les nouveaux skills en direct, sans redémarrage.
Quelle est la différence entre un skill et un MCP ?
Un skill donne à Claude des instructions sur comment faire quelque chose (une procédure, des conventions). Un MCP (Model Context Protocol) branche Claude sur un outil ou une source de données externe, comme GitHub ou une base de données. En résumé : le skill dit comment faire, le MCP donne accès à quoi faire. Les deux se combinent.
CLAUDE.md ou skill : lequel choisir ?
Utilisez CLAUDE.md pour des faits stables que Claude doit toujours avoir en tête (stack, conventions, architecture) : c'est toujours chargé. Utilisez un skill pour une procédure que Claude ne sort qu'au moment utile : son corps ne se charge qu'à l'usage, donc il ne coûte pas de tokens en permanence. Règle simple : si une section de votre CLAUDE.md est devenue une procédure en étapes, transformez-la en skill.
Quels sont les skills les plus utiles pour démarrer ?
Les skills fournis d'office rendent service tout de suite : /code-review pour relire vos changements, /run et /verify pour confirmer qu'une modification marche, /debug pour diagnostiquer une panne, /doctor pour vérifier votre config. Ensuite, le plus rentable est d'écrire vos propres skills (commit, conventions produit, déploiement) parce qu'ils encodent votre façon de travailler.
