Claude Code Skills : comment automatiser tes routines de dev en 30 secondes

Tu utilises Claude Code tous les jours, et tu te retrouves à ré-expliquer les mêmes consignes à chaque session ? "Fais un commit conv-commits", "review le diff avant de merger", "déploie sur le VPS comme d'habitude"… Tu fatigues, Claude répond bien mais à chaque fois tu repars de zéro.

La solution s'appelle les Skills. C'est sorti en 2025 chez Anthropic, et franchement, c'est le truc le plus sous-coté de Claude Code. Tu écris un petit fichier markdown, tu le poses dans un dossier, et Claude apprend à exécuter une routine tout seul, sans qu'on lui répète. Voici comment t'y mettre en 30 secondes.

C'est quoi une Skill exactement ?

Imagine que tu embauches un nouveau dev junior. Tu lui dis : "quand on commit, ici on suit le format conventional commits, type(scope): message court, et avant de pousser tu lances npm test". Tu lui répètes ça une seule fois, il l'écrit dans son carnet, et après il le fait tout seul.

Une Skill, c'est exactement ça. Un playbook que Claude apprend. Tu décris une routine en markdown, tu la poses dans le dossier .claude/skills/ma-skill/SKILL.md, et c'est tout. La prochaine fois que tu dis "commit le tout", Claude reconnaît la situation, charge la Skill correspondante, et déroule la procédure que tu lui as écrite.

L'analogie qui marche le mieux : c'est un bouton "fais-le-moi-comme-d'habitude". Sauf que ce bouton, c'est Claude qui décide tout seul de l'appuyer en lisant ton prompt.

L'anatomie d'une Skill (3 minutes pour comprendre)

Une Skill, c'est 3 morceaux seulement : un frontmatter, une description, un workflow. Voici un exemple complet pour un commit conventionnel :

---
name: conv-commit
description: Crée un commit git en respectant le format
  conventional commits (type(scope): message). À utiliser
  quand l'utilisateur demande de committer ses changements.
---

# Conventional commit

1. Lis le diff avec `git diff --staged`
2. Détermine le type : feat / fix / chore / docs / refactor
3. Format final : `type(scope): message court à l'impératif`
4. Lance `git commit -m "..."` puis `git status`
5. Ne JAMAIS push sans accord explicite

C'est tout. 12 lignes, et tu as transformé une routine fastidieuse en automatisme. Le détail qui compte le plus :

• Le frontmatter (bloc ---) : c'est le seul truc obligatoire. name identifie la Skill, description sert au matching.
• La description : la pièce maîtresse. C'est ce que Claude lit pour décider s'il doit activer la Skill. Sois concret, mentionne les déclencheurs ("quand l'utilisateur demande X").
• Le workflow : ton playbook, en clair. Liste numérotée, contraintes explicites, étapes ordonnées.

5 Skills à créer dès aujourd'hui

Si tu veux des idées concrètes pour démarrer, voici les 5 que je conseille à 99% des devs qui débutent avec Claude Code. Tu peux toutes les créer en une après-midi.

Pour chaque Skill, applique la même recette : une description claire avec déclencheurs explicites, un workflow numéroté de 4-8 étapes, et des contraintes négatives ("ne jamais push sans accord", "ne pas modifier les tests existants"). Cette dernière partie évite 80% des dérapages.

Skills vs Hooks vs Sub-agents : qui fait quoi ?

C'est la question qui revient tout le temps. Les trois mécaniques ont l'air similaires, mais elles répondent à des besoins très différents. Le tableau qui suit règle le débat.

La règle simple : Skills pour 80% des cas. Hooks quand tu veux une garantie absolue ("toujours formatter avant de commit, sans exception"). Sub-agents quand la tâche mérite son propre thread (recherche longue, refacto massive, audit complet d'un repo).

Comment Claude choisit la bonne Skill (le matching)

Là où ça devient malin : tu n'as jamais besoin de dire "active la skill conv-commit". Au démarrage de chaque session, Claude scanne le dossier .claude/skills/, lit les frontmatters, et garde les descriptions en mémoire.

Quand tu envoies un prompt comme "commit ces changements stp", Claude fait du matching sémantique entre ta demande et les descriptions disponibles. Si une Skill matche, il charge le contenu complet du SKILL.md et suit le workflow. Sinon, il répond normalement.

D'où la règle d'or : ta description doit contenir les verbes et noms que tu utilises naturellement quand tu demandes la chose. Si ta description dit "génère un commit message" mais que toi tu écris toujours "commit ça", il y a friction. Réécris la description pour qu'elle parle ta langue.

Combien de temps tu gagnes vraiment ?

Sur une journée type de dev qui utilise Claude Code activement, voici comment se répartit le temps gagné grâce aux Skills (estimation basée sur nos sessions internes) :

Le vrai gain s'accumule. Une Skill que tu utilises 5 fois par jour pendant 200 jours = 1000 déclenchements gratuits. Voici la courbe du temps cumulé sauvé sur une Skill type :

Comment t'y mettre — la roadmap 4 phases

Si tu veux passer de zéro à "j'ai 5 Skills qui tournent" sans te disperser, voici le séquencement qu'on conseille à nos devs :

Skills built-in, Skills perso, Skills de la communauté

Trois sources, trois usages. Les Skills built-in sont fournies par Anthropic (création de docx, manipulation d'images, etc.). Les Skills perso, tu les écris pour ton workflow. Les Skills communautaires, tu les chopes sur GitHub — il y a déjà des dépôts entiers de Skills partagées (review PR, audit sécu, refacto Python…).

Le piège classique : cumuler 30 Skills communautaires "au cas où". Mauvaise idée. Plus tu as de Skills, plus le matching devient ambigu. Mieux vaut 5 Skills affûtées que 30 Skills approximatives. Élague régulièrement.

3 erreurs à éviter quand tu débutes

Article rédigé par Inno-Mation, agence française d'automatisation IA — basé sur notre usage interne quotidien de Claude Code et les retours de nos clients dev en 2025-2026.