Les skills Claude Code sont une des briques les plus sous-utilisées de l’outil. C’est dommage parce qu’elles transforment n’importe quelle procédure répétitive en un automatisme intelligent. Une fois écrites, vous les invoquez en une ligne et Claude applique la bonne démarche, avec les bons outils, dans le bon ordre. Finie la répétition de prompts, fini l’oubli d’une étape.
Dans ce guide, on voit ce qu’est concrètement un skill, la différence avec un subagent (que vous pouvez aussi utiliser), comment créer votre premier skill en 5 minutes, 5 exemples qui tournent chez moi et les bonnes pratiques pour que vos skills restent utiles sur la durée. Pratique, direct, pas de théorie inutile.
Skill, c’est quoi ?
Un skill, c’est une procédure nommée que Claude Code charge à la demande. Vous lui dites « fais X comme je te l’ai appris » et Claude va lire la fiche du skill, suivre les étapes, utiliser les outils décrits, et produire le résultat attendu.
Techniquement, un skill est un fichier markdown dans .claude/skills/ (niveau projet) ou ~/.claude/skills/ (niveau utilisateur). Il contient :
- Un nom : le mot-clé pour l’invoquer
- Une description : quand l’utiliser (c’est ça qui déclenche l’invocation automatique)
- Des instructions : la procédure à suivre, souvent sous forme d’étapes numérotées
- Optionnel : des exemples, des contre-exemples, des règles
Contrairement à un subagent, un skill ne lance pas une instance séparée de Claude. Il charge ses instructions dans votre session en cours. Vous gardez votre contexte, votre historique, vos outils.
Pourquoi les skills transforment votre workflow
Le problème classique sans skill : vous répétez la même procédure 3 fois par semaine. « Avant de commit, lance lint, puis tests, puis tape le bon format de message. » À chaque fois, vous devez redire les étapes, ou pire, Claude en oublie une.
Avec un skill « commit » bien écrit, vous tapez « commit en suivant mes règles » et Claude applique exactement la procédure : lint, tests, format conventional commits, Co-Authored-By à la fin. Toujours. Sans oubli.
Trois bénéfices immédiats :
- Reproductibilité : la même procédure donne toujours le même résultat, peu importe le jour
- Mémoire d’équipe : en versionnant les skills dans Git, vos collègues bénéficient des mêmes procédures, sans tradition orale
- Qualité constante : les étapes critiques (tests, lint, vérif sécurité) ne sont plus oubliées
Le ROI est évident dès qu’une procédure est utilisée 3 fois. Si vous la faites 10 fois par semaine, le skill paye son écriture dans la journée.
Skill vs Subagent : la bonne intuition
Question qu’on me pose systématiquement. La réponse courte : ils ne répondent pas au même besoin.
Skill : une marche à suivre que Claude charge dans votre session. Votre Claude principal exécute les étapes, modifie vos fichiers, utilise vos outils habituels. Zéro isolation, zéro appel supplémentaire.
Subagent : une mission déléguée à une instance séparée de Claude, qui travaille dans son propre contexte et renvoie juste un résumé.
Règle pratique :
- Procédure qui modifie votre code = skill (ex : « prépare un commit », « génère les tests », « refactor ce module »)
- Exploration qui produit un rapport = subagent (ex : « audit sécurité », « explore codebase pour trouver X », « analyse perf »)
Et les deux se combinent très bien : un skill « deploy » peut lancer un subagent « security-audit » avant de pousser. Le skill garde la main sur l’exécution, le subagent fait l’audit lourd sans polluer le contexte.
Créer votre premier skill (5 minutes)
Créons un skill « prepare-commit » qui prépare un commit proprement : lint, tests, puis commit avec message conventional.
Étape 1 : créez le dossier skills
mkdir -p .claude/skillsÉtape 2 : créez le skill
Créez .claude/skills/prepare-commit.md :
---
name: prepare-commit
description: Prépare un commit propre : lint, tests unitaires, puis commit au format conventional. À invoquer avant chaque commit significatif.
---
# prepare-commit
Tu prépares un commit dans ce projet. Suis cette procédure dans l'ordre, ne saute aucune étape.
## 1. Vérifier l'état
- `git status` pour voir les fichiers modifiés
- Si rien de stagé, demander à l'utilisateur ce qu'il veut commiter
## 2. Qualité
- Lance `npm run lint`. Si erreurs, stoppe et demande à l'utilisateur
- Lance `npm run test`. Si tests rouges, stoppe et demande
## 3. Message de commit
Génère un message au format conventional commits :
- `feat(scope): description` pour une feature
- `fix(scope): description` pour un bugfix
- `docs(scope): description` pour de la doc
- `refactor(scope): description` pour un refactor
Le message doit :
- être en français
- commencer par un verbe d'action (ajouter, corriger, refactorer)
- tenir sur une ligne de 72 caractères max
## 4. Commit
Exécute `git commit -m "..."` avec le message généré.
Ajoute `Co-Authored-By: Claude <noreply@anthropic.com>` en fin de message.
## Règle dure
Ne JAMAIS utiliser `--no-verify`. Si le pre-commit hook rejette, corrige le problème.Étape 3 : utilisez-le
Dans Claude Code, tapez :
utilise le skill prepare-commitClaude va charger la procédure et l’appliquer. Vous verrez les étapes s’exécuter, lint et tests tourner, puis le commit se faire avec le bon format.
En bonus, si votre description mentionne clairement « avant un commit », Claude peut proposer le skill automatiquement quand il détecte que vous vous apprêtez à commiter. C’est la magie de l’invocation automatique basée sur la description.
5 skills qui valent vraiment le détour
1. prepare-commit (vu plus haut)
Probablement le plus rentable. Un commit par jour = un gain par jour.
2. write-doc
Rédige la doc d’une fonctionnalité. Procédure : lire le code, comprendre le flow, produire README + exemples. Tonalité définie dans le skill (pédagogique, exemples concrets, pas de jargon).
3. deploy-staging
Déploiement sur l’environnement de staging. Procédure : vérifier branch, lancer build, push vers la bonne remote, tagger, notifier Slack. Un skill = zéro oubli.
4. add-feature-flag
Ajoute un feature flag dans le projet. Procédure : déclarer le flag dans config, ajouter le wrapper dans le code, mettre à jour la doc, créer un ticket de cleanup dans Linear. Parfait pour uniformiser les pratiques d’équipe.
5. debug-production
Diagnostic d’un incident prod. Procédure : récupérer les logs, checker le statut des services, regarder la dernière deploy, tester les endpoints clés. Checklist automatisée qui fait gagner 10 min à chaque alerte.
Ce que vous remarquerez : chaque skill encode un « savoir-faire d’équipe » qu’on aurait autrefois écrit dans un Notion oublié. Là, il est dans Git, appliqué automatiquement, à jour.
Skills et slash commands
Claude Code associe souvent skills et slash commands. La différence :
- Slash command : une commande explicite tapée par l’utilisateur, genre
/commitou/deploy. Claude exécute immédiatement la procédure associée. - Skill : une procédure que Claude peut invoquer automatiquement quand la description correspond à l’intention de l’utilisateur.
Les deux ne sont pas exclusifs. Un même fichier peut définir à la fois un skill et servir de base à un slash command. En pratique, je code d’abord le skill (avec une bonne description), puis si je l’utilise explicitement tout le temps, j’en fais aussi un slash command dans .claude/commands/.
Règle perso : description précise dans le skill = invocation automatique fréquente. Pas besoin de multiplier les slash commands si la description fait le travail.
Organiser vos skills dans un projet
Quand votre projet grossit, vous allez accumuler 5, 10, 20 skills. Sans organisation, ça devient le bazar. Ce qui marche chez moi :
Par domaine
Un skill par « famille d’actions » : un pour git (commit, push, release), un pour l’édition de contenu, un pour le déploiement, un pour la doc. Pas un skill par variation. Trop granulaire = oubli.
Description qui déclenche
Le champ description est ultra-important. Il doit décrire QUAND utiliser le skill, pas CE QU’IL FAIT. Exemple :
- Mauvais : « Commit propre avec lint et tests »
- Bon : « À invoquer quand l’utilisateur s’apprête à committer des changements significatifs, ou dit des choses comme ‘commit ça’ ou ‘prépare un commit' »
Claude scan les descriptions pour proposer le bon skill. Si la description est trop vague, l’invocation automatique ne se déclenche pas.
Partage entre projets
Les skills vraiment transverses (ex : « rédige-article-bilingue ») vont dans ~/.claude/skills/ utilisateur. Les skills spécifiques au projet restent dans .claude/skills/.
Bonnes pratiques (testées)
1. Numérote les étapes
Une procédure non numérotée est une procédure que Claude peut réordonner. Étapes numérotées = exécution dans l’ordre.
2. Ajoute les règles dures
Au bout de la procédure, section « règles dures » ou « jamais faire ». Ex : « ne jamais utiliser –force-push sur main ». Claude y est sensible.
3. Termine par une vérif
Dernière étape : un moyen de vérifier que la procédure a réussi. Ex : « lance git log -1 pour confirmer que le commit est bon ». Ça évite les « c’est fait » quand en fait non.
4. Pas de copier-coller de CLAUDE.md
Ne duplique pas dans le skill ce qui est déjà dans CLAUDE.md. Claude a les deux. Skills courts = skills lus entièrement.
5. Itère
Tu utilises un skill 5 fois, tu remarques qu’il lui manque une étape ? Ajoute-la. Un skill vit, il évolue avec le projet.
6. Versionne dans Git
Les skills sont du code. PR, review, historique. Pas de modification discrète, pas de skill qui pourrit dans le dossier d’un collègue.
Questions fréquentes
Les skills sont-ils disponibles partout ou juste dans Claude Code CLI ?
Ils sont disponibles dans tous les environnements qui embarquent Claude Code : CLI, Claude Desktop, extensions IDE qui l’utilisent. Ils ne fonctionnent pas sur claude.ai (qui n’a pas accès à votre système de fichiers).
Peut-on créer des skills qui s’invoquent tous seuls ?
Oui. Si votre description est assez précise (« à invoquer quand X… »), Claude propose automatiquement le skill. Vous gardez la main pour valider, mais vous n’avez pas à taper le nom explicitement.
Les skills fonctionnent ils avec les MCP ?
Parfaitement. Un skill peut demander à Claude d’utiliser un outil MCP précis (ex : « crée un ticket Linear via le MCP Linear »). Tant que le serveur MCP est configuré, le skill pilote l’intégration.
Un skill peut il en appeler un autre ?
Oui, dans ses instructions : « étape 4 : invoquer le skill security-check ». C’est un excellent moyen de composer des workflows complexes à partir de briques simples.
Combien de skills dans un projet ?
Pas de limite technique. En pratique, au-delà de 20-25, l’organisation devient clé. Dossiers par domaine, noms clairs, descriptions précises.
Les skills consomment-ils beaucoup de tokens ?
Non. Un skill n’est chargé en contexte QUE quand Claude l’utilise. Sa présence dans le dossier ne coûte rien. Seule la liste des skills disponibles (nom + description) est chargée en permanence, pour que Claude sache ce qu’il peut invoquer.
Différence avec les slash commands ?
Slash command = invocation explicite par l’utilisateur avec une commande. Skill = procédure que Claude peut invoquer automatiquement basé sur la description, ou que l’utilisateur peut mentionner par son nom. Les deux peuvent pointer vers la même procédure.
En résumé
Les skills sont votre mémoire d’équipe exécutable. Une procédure qu’on répète chaque semaine devient un skill, et ce skill encode vos bonnes pratiques pour toujours. Commencez par prepare-commit, ajoutez write-doc, puis au fil du temps identifiez les 5-10 procédures qui vous font vraiment gagner du temps.
Le meilleur signal pour créer un skill : vous vous entendez dire à Claude « comme d’habitude » ou « comme on a fait la dernière fois ». C’est là qu’il manque un skill.
Pour aller plus loin sur Claude Code et ses capacités avancées, voyez notre guide complet Claude Code.
Articles similaires
Dans la catégorie Claude