Skills Claude Code : créer, ranger et partager les vôtres
Pour maîtriser skills, sous-agents et automatisations sur un vrai projet, la formation Claude Code de Dyma consacre un chapitre aux skills, puis les met en pratique dans la deuxième partie de son projet fil rouge. Ce guide montre comment créer un skill pour Claude Code, où le ranger, comment contrôler qui le déclenche et comment le partager avec votre équipe. Tout a été vérifié le 2 novembre 2026 sur la documentation officielle d’Anthropic (Claude Code 2.1.316). Il parle des skills dans Claude Code ; ceux de l’application Claude, sur le web et sur ordinateur, feront l’objet d’un article à part.
Qu’est-ce qu’un skill dans Claude Code ?
Un skill empaquette un savoir-faire : relire un diff, déployer, écrire un article au format de votre blog. Vous écrivez les instructions une fois, Claude les applique chaque fois que c’est utile. Les skills de Claude Code suivent le standard ouvert Agent Skills, partagé par plusieurs outils d’IA, et Claude Code y ajoute ses propres options.
Leur force est le chargement progressif. Au démarrage, Claude ne voit que la description de chaque skill ; le contenu complet n’arrive dans la conversation qu’à l’usage. Vous pouvez donc en installer beaucoup sans alourdir chaque requête, à la différence du fichier CLAUDE.md, chargé en entier à chaque session.
| Module | Quand il se charge | Pour quoi |
|---|---|---|
| CLAUDE.md | À chaque session, en entier | Les faits et conventions du projet |
| Skill | La description toujours, le reste à l’usage | Une procédure ou un savoir-faire |
| Hook | Il ne se charge pas : il s’exécute | Ce qui doit toujours se produire |
Créer son premier skill
-
Créez un dossier à son nom, par exemple
~/.claude/skills/resume-changements/. - Écrivez SKILL.md : un en-tête avec la description, puis les instructions en Markdown.
- Soignez la description : elle dit ce que fait le skill et quand s’en servir.
-
Testez-le en tapant
/resume-changements, puis en demandant simplement « qu’est-ce qui a changé ? ».
Voici un skill adapté de l’exemple officiel. La syntaxe !`git diff HEAD` exécute la commande avant l’envoi à Claude, et sa sortie prend sa place :
---
description: Résume les changements non commités et signale ce qui est risqué. À utiliser quand on demande ce qui a changé, un message de commit ou une relecture du diff.
---
## Changements en cours
!`git diff HEAD`
## Instructions
Résume les changements ci-dessus en deux ou trois points, puis liste les risques :
gestion d'erreur manquante, valeurs en dur, tests à mettre à jour.
Si le diff est vide, dis qu'il n'y a aucun changement.Tous les champs de l’en-tête sont facultatifs ; seule la description est recommandée. Sans champ name, le nom du dossier devient la commande. La documentation conseille de garder SKILL.md sous 500 lignes.
Où ranger ses skills ?
| Portée | Dossier |
|---|---|
| Vous, dans tous vos projets | ~/.claude/skills/<nom>/ |
| Le projet, pour toute l’équipe | .claude/skills/<nom>/, à committer |
| Un sous-dossier d’un monorepo | <dossier>/.claude/skills/<nom>/ |
| Un plugin | skills/<nom>/ dans le plugin |
| L’organisation | Les réglages gérés par l’administrateur |
À nom égal, le skill de l’organisation l’emporte sur le vôtre, qui l’emporte sur celui du projet. Les skills de plugins portent le nom du plugin en préfixe (/plugin:skill) et n’entrent jamais en conflit. Si une ancienne commande de .claude/commands/ porte le même nom qu’un skill, c’est le skill qui gagne.
Qui déclenche le skill : vous ou Claude ?
Par défaut, les deux. Deux champs de l’en-tête changent ce comportement :
| Réglage | Vous | Claude |
|---|---|---|
| Par défaut | Oui | Oui, quand la description correspond |
| Réservé à vous | Oui | Non : sa description n’est même plus en contexte |
| Réservé à Claude | Non : caché du menu / | Oui |
On réserve un skill à vous-même avec la ligne disable-model-invocation: true dans son en-tête, et à Claude avec user-invocable: false. Le premier réglage convient aux skills qui ont des effets de bord, comme un déploiement : vous ne voulez pas que Claude le lance de sa propre initiative. Le second convient à un savoir de fond, que Claude consulte sans que ce soit une action à lancer.
Les champs utiles de l’en-tête
| Champ | Effet |
|---|---|
description |
Ce que fait le skill et quand l’utiliser ; c’est ce que lit Claude pour décider |
argument-hint |
L’indice affiché à l’autocomplétion, par exemple
[numéro-ticket]
|
allowed-tools |
Les outils permis sans confirmation pendant le tour qui lance le skill |
model, effort |
Le modèle et le niveau de réflexion pour la suite du tour |
context: fork |
Exécute le skill dans un sous-agent isolé, sans l’historique |
paths |
Limite l’activation automatique à certains fichiers |
hooks |
Des hooks actifs une fois le skill lancé |
Un champ inconnu est ignoré sans erreur. La liste complète, une vingtaine de champs, figure dans la référence de la documentation.
Passer des arguments à un skill
Ce que vous tapez après le nom du skill remplace $ARGUMENTS dans les instructions. Avec la ligne Corrige le ticket GitHub $ARGUMENTS selon nos conventions., la commande /corrige-ticket 123 donne « Corrige le ticket GitHub 123… ». Pour plusieurs arguments, $0, $1 et $2 les prennent dans l’ordre. Sans aucun de ces repères, Claude Code ajoute les arguments à la fin, précédés de ARGUMENTS:.
Attention à la position : /deploy staging en début de message lance le skill ; le même texte au milieu d’une phrase n’est qu’une autorisation donnée à Claude de s’en servir.
Organiser un skill en plusieurs fichiers
Un skill peut emporter des références, des exemples et des scripts. Claude ne lit une annexe que lorsqu’il en a besoin, et exécute les scripts sans les charger dans son contexte :
mon-skill/
├── SKILL.md (obligatoire : vue d'ensemble, liens vers le reste)
├── reference.md (documentation détaillée, lue au besoin)
├── exemples.md (exemples, lus au besoin)
└── scripts/
└── helper.py (exécuté, pas chargé)Citez chaque annexe depuis SKILL.md par un lien Markdown, pour que Claude sache qu’elle existe.
Partager ses skills avec son équipe
Trois voies, selon la documentation : committer .claude/skills/ dans le dépôt, publier un plugin qui contient un dossier skills/, ou déployer les skills pour toute l’organisation par les réglages gérés. Un plugin regroupe skills, agents, hooks et serveurs MCP et s’installe avec la commande /plugin. Par exemple, le plugin skill-creator, qui aide à écrire et tester d’autres skills :
/plugin install skill-creator@claude-plugins-officialSi Claude Code répond que le plugin est introuvable, ajoutez d’abord la marketplace officielle avec /plugin marketplace add anthropics/claude-plugins-official.
Les skills fournis avec Claude Code
Claude Code arrive avec ses propres skills, dont /code-review (relecture du diff), /simplify, /debug, /loop (relancer une tâche à intervalle) et /batch. Leur disponibilité varie selon la plateforme et le plan. Pour faire le point sur les vôtres, /skills les liste avec leur coût en contexte, /skill-doctor repère ceux qui coûtent sans servir, et /reload-skills recharge ceux que vous venez de modifier.
Un mot sur l’application Claude et l’API : elles acceptent aussi des skills au format Agent Skills, mais seulement six champs d’en-tête (name, description, license, compatibility, metadata, allowed-tools), et l’exécution de commandes par point d’exclamation n’y fonctionne pas. Un skill écrit pour Claude Code n’y passe donc pas toujours tel quel.
Aller plus loin
Les skills prennent tout leur sens avec les autres modules : CLAUDE.md pour le contexte permanent, les hooks pour les garde-fous, MCP pour les outils externes. Pas encore installé ? Suivez notre guide installer Claude Code, puis le tutoriel Claude Code.
La formation Claude Code vous fait écrire vos propres skills sur un projet complet. Pour concevoir vos propres agents avec les API des modèles, la formation IA pour développeurs prend le relais ; pour l’usage quotidien de Claude, voyez la formation Claude.