Les Skills de Claude Code : comment j'ai automatise ma facon de coder

Le probleme : une IA sans methode

Vous demandez a Claude Code "ajoute un bouton de deconnexion". L'IA fonce. Elle ecrit du code, modifie trois fichiers, et vous livre un resultat. Parfois c'est exactement ce qu'il faut. Parfois elle a fait des hypotheses sur l'emplacement, le style, le comportement — et vous devez tout reprendre.

Le probleme n'est pas la qualite du code. C'est l'absence de processus. Un bon developpeur humain ne code pas immediatement. Il reflechit d'abord : ou placer le bouton ? Faut-il une confirmation ? Que se passe-t-il cote session ? L'IA saute cette etape si on ne l'y force pas.

C'est exactement ce que font les skills de Claude Code : ils imposent un workflow a l'IA avant qu'elle touche au code.

C'est quoi un skill ?

Un skill, c'est un fichier texte (Markdown) que Claude Code charge a la demande. Ce fichier contient des instructions, des checklists, des regles — un workflow complet que l'IA doit suivre pour accomplir un type de tache.

Pensez-y comme un mode operatoire. Quand un chirurgien opere, il suit un protocole precis — pas parce qu'il ne sait pas operer, mais parce que le protocole empeche les oublis. Les skills sont le protocole de l'IA.

Concretement, un skill est :

• Un fichier .md avec un frontmatter YAML (nom, description, declencheur)
• Stocke dans .claude/skills/ (local au projet) ou ~/.claude/skills/ (global)
• Invocable manuellement (/nom-du-skill) ou automatiquement par Claude Code quand il detecte un contexte pertinent

Claude Code supporte nativement le systeme de skills, mais la collection que j'utilise — superpowers — est un projet open source cree par Jesse Vincent (obra). Vous pouvez aussi creer les votres ou en installer depuis d'autres repos communautaires.

Le meta-skill : using-superpowers

Parmi tous les skills que j'utilise, il y en a un qui se distingue : using-superpowers. Ce n'est pas un skill qui fait quelque chose — c'est un skill qui dit a Claude Code comment utiliser tous les autres skills.

Sa regle centrale est simple :

Avant toute action ou reponse, verifie si un skill pourrait s'appliquer. Meme a 1% de chance, invoque-le.

Pourquoi est-ce necessaire ? Parce que sans cette regle, Claude Code a tendance a "rationaliser" le fait de ne pas utiliser un skill. Il se dit "c'est juste une question simple" ou "je vais d'abord explorer le code". Le meta-skill bloque ces reflexes et force la discipline.

Le skill definit meme une liste de pensees-pieges :

Pensee de l'IA	Realite
"C'est juste une question simple"	Les questions sont des taches. Verifie les skills.
"Laisse-moi d'abord explorer le code"	Les skills disent COMMENT explorer. Verifie d'abord.
"Ce skill est excessif ici"	Les choses simples deviennent complexes. Utilise-le.
"Je vais juste faire ce truc vite"	Verifie AVANT de faire quoi que ce soit.

Il definit aussi un ordre de priorite : les skills de processus (brainstorming, debugging) passent avant les skills d'implementation (frontend-design, etc.). La logique : on decide comment faire avant de faire.

Mes skills favoris et comment je les utilise

Brainstorming — reflechir avant de coder

C'est le skill que j'invoque le plus souvent. Chaque fois que je demande "ajoute X" ou "construis Y", le skill brainstorming se declenche et force Claude Code a :

1. Explorer le contexte du projet (fichiers, commits recents)
2. Poser des questions de clarification — une a la fois
3. Proposer 2-3 approches avec leurs compromis
4. Presenter un design et attendre mon approbation

La regle d'or : aucun code n'est ecrit tant que le design n'est pas approuve. Meme pour un "simple" bouton.

Dans mon workflow sur thisishumanmade.com par exemple, quand j'ai demande "ajoute une version anglaise du site", le skill brainstorming a d'abord identifie qu'il fallait restructurer les URLs (/en/ pour la homepage, /en/offer/ pour l'offre), adapter les chemins relatifs, et mettre a jour Firebase pour les traductions des statuts. Sans ce brainstorming, l'IA aurait probablement juste duplique le fichier HTML.

Systematic Debugging — debugger avec methode

Quand quelque chose ne marche pas, la tentation est de proposer un fix immediat. Le skill systematic-debugging force une approche differente :

1. Observer et reproduire le probleme
2. Formuler des hypotheses
3. Tester chaque hypothese methodiquement
4. Confirmer la cause racine avant de corriger

C'est un skill de type rigid — on le suit a la lettre, sans raccourci. La raison : le debugging est exactement le domaine ou les raccourcis coutent le plus cher. Un fix qui traite le symptome au lieu de la cause va revenir vous hanter.

Test-Driven Development — les tests d'abord

Le skill TDD impose le cycle classique : Red → Green → Refactor. Ecris un test qui echoue, ecris le code minimal pour le faire passer, puis refactorise. Claude Code applique naturellement ce cycle quand le skill est actif.

Ce qui est interessant, c'est que l'IA est particulierement bonne en TDD, parce qu'elle n'a pas l'impatience humaine de "juste ecrire le code d'abord". Une fois le skill charge, elle suit le protocole mecaniquement — exactement ce qu'on veut.

Verification Before Completion — pas de "c'est fini" sans preuve

Ce skill empeche Claude Code de declarer victoire trop tot. Avant de dire "c'est fait", il doit :

• Executer les commandes de verification (tests, build, lint)
• Confirmer que la sortie est celle attendue
• Fournir des preuves (output reel, pas des suppositions)

Combien de fois une IA vous a dit "voila, c'est corrige" alors que le code ne compile meme pas ? Ce skill elimine ce probleme.

Dispatching Parallel Agents — paralleliser intelligemment

Quand un plan d'implementation contient des taches independantes, ce skill permet de lancer plusieurs sous-agents en parallele. Chaque agent travaille sur sa tache sans bloquer les autres. C'est particulierement utile pour les migrations ou les refactorisations qui touchent beaucoup de fichiers.

Deep dive : anatomie d'un skill

Un skill est un fichier Markdown avec un frontmatter YAML. Voici la structure minimale :

---
name: mon-skill
description: Quand l'utiliser et pourquoi
---

# Mon Skill

## Checklist

1. **Premiere etape** — faire ceci
2. **Deuxieme etape** — faire cela
3. **Troisieme etape** — valider

## Regles

- Ne jamais faire X sans avoir fait Y
- Toujours verifier Z avant de continuer

Le frontmatter

• name — le nom du skill, utilise pour l'invoquer (/mon-skill)
• description — quand Claude Code doit l'utiliser. C'est la description qui permet au meta-skill using-superpowers de detecter si un skill s'applique a la tache en cours

Le corps du skill

C'est du Markdown libre. Vous pouvez y mettre :

• Des checklists que Claude Code doit suivre etape par etape
• Des regles (positives et negatives)
• Des exemples de bonne et mauvaise execution
• Des diagrammes (en syntaxe dot/Graphviz, que Claude Code peut interpreter)
• Des balises <HARD-GATE> pour les regles non-negociables

Ou les placer

# Skills globaux (tous les projets)
~/.claude/skills/mon-skill.md

# Skills locaux (ce projet seulement)
.claude/skills/mon-skill.md

Les skills locaux sont prioritaires sur les globaux. Cela permet d'avoir un skill de debugging generique au niveau global, et un skill specifique au framework du projet au niveau local.

Installer la collection superpowers

La collection superpowers de Jesse Vincent est celle que j'utilise au quotidien. Elle s'installe directement depuis Claude Code :

/install-plugin obra/superpowers

Les skills sont telecharges dans .claude/plugins/cache/ et disponibles immediatement. Le repo est ouvert, MIT-license : github.com/obra/superpowers.

En pratique : le workflow complet

Voici a quoi ressemble mon workflow typique avec les skills :

1. Je donne une instruction — "Ajoute un systeme de dark mode"
2. using-superpowers intercepte — il detecte que le skill brainstorming s'applique
3. brainstorming se lance — Claude me pose des questions : CSS variables ou classes ? Toggle automatique (prefers-color-scheme) ou manuel ? Ou placer le bouton ?
4. Je valide le design — Claude ecrit un plan d'implementation
5. writing-plans structure le plan — etapes numerotees, fichiers concernes, dependances
6. Implementation — Claude code en suivant le plan, etape par etape
7. verification-before-completion — avant de declarer "fini", Claude verifie que tout compile, que les tests passent, que le dark mode fonctionne reellement

Tout ce processus se passe automatiquement. Je n'ai pas a dire "fais un brainstorm d'abord" ou "verifie avant de finir". Les skills s'enchainent naturellement grace au meta-skill.

Creer vos propres skills

Le plus puissant dans ce systeme, c'est qu'il est extensible. Vous pouvez creer des skills adaptes a votre facon de travailler. Quelques idees :

• Un skill de review de code — checklist specifique a votre equipe (conventions, securite, performance)
• Un skill de migration — etapes a suivre quand vous migrez une librairie ou un framework
• Un skill de deploy — verification pre-deploy, tests de smoke, rollback si erreur
• Un skill de documentation — quand et comment documenter, quel format, ou placer les fichiers

La cle : un bon skill est prescriptif mais pas rigide. Il dit "fais ces etapes dans cet ordre" mais laisse de la marge sur le comment executer chaque etape. Trop vague et il ne sert a rien. Trop strict et il devient un carcan.

Commencez simple : prenez une tache que vous faites souvent, ecrivez les etapes que vous suivez a chaque fois, et transformez ca en skill. Vous serez surpris de voir a quel point ca change la qualite du travail de l'IA.

Les best practices officielles d'Anthropic

Apres avoir vu comment j'utilise les skills au quotidien, voyons maintenant les recommandations officielles d'Anthropic pour en ecrire de bons. Ces best practices viennent directement de la documentation officielle et s'appliquent que vous utilisiez Claude Code, le SDK Agent ou l'API.

Le message central : un bon skill est concis, bien structure, et teste en conditions reelles.

Principe n°1 : la concision avant tout

La fenetre de contexte est une ressource partagee. Votre skill cohabite avec le system prompt, l'historique de conversation, les metadonnees des autres skills, et votre requete. Chaque token compte.

La regle d'or d'Anthropic :

Claude est deja tres intelligent. N'ajoutez que le contexte qu'il ne possede pas deja.

Avant d'ecrire une ligne dans un skill, posez-vous trois questions :

• "Est-ce que Claude a vraiment besoin de cette explication ?"
• "Est-ce que je peux supposer qu'il sait deja ca ?"
• "Est-ce que ce paragraphe justifie son cout en tokens ?"

Exemple concret — extraire du texte d'un PDF :

Bien (~50 tokens) :

## Extraire du texte PDF

Utiliser pdfplumber pour l'extraction :

```python
import pdfplumber

with pdfplumber.open("file.pdf") as pdf:
    text = pdf.pages[0].extract_text()
```

Trop verbeux (~150 tokens) :

## Extraire du texte PDF

Les fichiers PDF (Portable Document Format) sont un format
courant qui contient du texte, des images, et d'autres contenus.
Pour extraire du texte d'un PDF, vous aurez besoin d'une
librairie. Il existe de nombreuses librairies, mais nous
recommandons pdfplumber parce qu'il est facile a utiliser...
```

La version concise suppose que Claude sait ce qu'est un PDF et comment fonctionnent les librairies. Trois fois moins de tokens, meme resultat.

Principe n°2 : calibrer les degres de liberte

Tous les skills ne doivent pas etre aussi directifs. Anthropic propose une analogie parlante : imaginez Claude comme un robot sur un chemin.

• Pont etroit avec des falaises — il n'y a qu'un seul passage sur. Donnez des instructions exactes, pas de marge. Exemple : une migration de base de donnees qui doit s'executer dans un ordre precis.
• Champ ouvert sans obstacle — plein de chemins menent au succes. Donnez la direction generale et laissez Claude trouver le meilleur chemin. Exemple : une review de code ou le contexte determine l'approche.

Trois niveaux :

Liberte	Quand l'utiliser	Exemple
Haute	Plusieurs approches valides, decisions contextuelles	Review de code, analyse de donnees
Moyenne	Un pattern prefere existe, avec des variations acceptables	Generation de rapports avec template personnalisable
Basse	Operations fragiles, coherence critique	Migration BDD, deploy en production

Bien structurer un skill

Le nommage

Anthropic recommande la forme gerondive (verbe + ing) pour les noms de skills : processing-pdfs, testing-code, managing-databases. C'est plus clair que des noms vagues comme helper ou utils.

Contraintes techniques du champ name :

• 64 caracteres maximum
• Minuscules, chiffres et tirets uniquement
• Pas de mots reserves (anthropic, claude)

La description — le facteur critique

La description dans le frontmatter est ce qui permet a Claude de decouvrir votre skill parmi potentiellement 100+ skills disponibles. Deux regles :

1. Ecrire a la 3e personne — la description est injectee dans le system prompt, un "I can help you" ou "You can use this" cree des problemes de decouverte
2. Inclure le "quoi" ET le "quand" — decrire ce que fait le skill et dans quel contexte l'utiliser

Exemples :

# Bien
description: Extract text and tables from PDF files, fill
  forms, merge documents. Use when working with PDF files
  or when the user mentions PDFs, forms, or document extraction.

# Mal
description: Helps with documents

La divulgation progressive (progressive disclosure)

Le SKILL.md doit rester sous 500 lignes. Au-dela, eclatez le contenu dans des fichiers separes que Claude charge a la demande :

pdf/
├── SKILL.md              # Instructions principales
├── FORMS.md              # Guide remplissage formulaires
├── reference.md          # Reference API
├── examples.md           # Exemples d'utilisation
└── scripts/
    ├── analyze_form.py   # Script utilitaire
    ├── fill_form.py      # Remplissage formulaire
    └── validate.py       # Validation

Quand l'utilisateur pose une question sur le remplissage de formulaire, Claude ne charge que FORMS.md — pas la reference API, pas les exemples. Resultat : moins de tokens consommes, plus de place pour l'historique de conversation.

Regle importante : gardez les references a un seul niveau de profondeur. Le SKILL.md pointe vers des fichiers, mais ces fichiers ne doivent pas pointer vers d'autres fichiers. Claude peut ne faire qu'un survol partiel des fichiers references en profondeur.

Workflows et boucles de feedback

Pour les taches complexes, Anthropic recommande deux patterns :

Les checklists copiables

Fournir une checklist que Claude peut copier dans sa reponse et cocher au fur et a mesure :

## Workflow de synthese

Copier cette checklist et suivre la progression :

```
Progression :
- [ ] Etape 1 : Lire tous les documents sources
- [ ] Etape 2 : Identifier les themes cles
- [ ] Etape 3 : Croiser les affirmations
- [ ] Etape 4 : Creer un resume structure
- [ ] Etape 5 : Verifier les citations
```

La checklist empeche Claude de sauter des etapes critiques et permet de suivre la progression visuellement.

Les boucles de validation

Le pattern action → validation → correction → boucle ameliore enormement la qualite :

1. Faire vos modifications dans document.xml
2. Valider immediatement : python scripts/validate.py
3. Si la validation echoue :
   - Analyser le message d'erreur
   - Corriger le probleme
   - Re-valider
4. Ne continuer QUE quand la validation passe

Ce pattern est exactement ce que fait le skill verification-before-completion dont on a parle plus haut — mais il peut s'appliquer a n'importe quel skill que vous creez.

Les erreurs a eviter

Trop d'options

Ne presentez pas 5 librairies au choix. Donnez un choix par defaut avec une alternative si necessaire :

# Mal
"Vous pouvez utiliser pypdf, ou pdfplumber, ou PyMuPDF,
ou pdf2image, ou..."

# Bien
"Utiliser pdfplumber pour l'extraction de texte.
Pour les PDF scannes necessitant de l'OCR,
utiliser pdf2image avec pytesseract."

Les informations perissables

Evitez les references temporelles qui deviendront fausses :

# Mal
"Si vous faites cela avant aout 2025, utilisez l'ancienne API."

# Bien
## Methode actuelle
Utiliser l'endpoint v2 : api.example.com/v2/messages

## Anciens patterns
<details>
<summary>API v1 legacy (deprecie 2025-08)</summary>
...
</details>

La terminologie incoherente

Choisissez un terme et gardez-le partout. Ne melangez pas "API endpoint", "URL", "API route" et "path" dans le meme skill. La coherence aide Claude a comprendre et suivre les instructions.

Developper un skill de facon iterative

La recommandation la plus interessante d'Anthropic concerne le processus de developpement lui-meme. Au lieu d'ecrire un skill parfait du premier coup, ils proposent un cycle avec deux instances de Claude :

1. Completez une tache sans skill — travaillez avec "Claude A" en prompting normal. Notez les informations que vous fournissez plusieurs fois
2. Demandez a Claude A de creer le skill — il connait nativement le format et la structure des skills
3. Testez avec Claude B — une instance fraiche avec le skill charge, sur des taches similaires
4. Observez le comportement — est-ce qu'il trouve les bonnes infos ? Applique les regles ? Rate quelque chose ?
5. Retournez a Claude A — "Quand Claude B a utilise ce skill, il a oublie de filtrer par date. Comment ameliorer ?"
6. Iterez — ce cycle observe-affine-teste est continu

Autre conseil : creez des evaluations avant d'ecrire le skill. Identifiez d'abord ou Claude echoue sans skill, construisez des scenarios de test, puis ecrivez le minimum d'instructions pour passer ces tests. C'est du TDD applique aux skills.

Skills avec code executable

Les skills peuvent embarquer des scripts utilitaires. Anthropic insiste sur un point : les scripts doivent resoudre les problemes, pas les deleguer a Claude.

# Bien — gere l'erreur explicitement
def process_file(path):
    try:
        with open(path) as f:
            return f.read()
    except FileNotFoundError:
        print(f"Fichier {path} non trouve, creation...")
        with open(path, "w") as f:
            f.write("")
        return ""

# Mal — laisse Claude se debrouiller
def process_file(path):
    return open(path).read()

Les avantages des scripts pre-faits par rapport au code genere a la volee :

• Plus fiable — teste et valide a l'avance
• Economie de tokens — pas besoin d'inclure le code dans le contexte
• Coherence — meme resultat a chaque execution

Point important : preciser dans le skill si Claude doit executer le script (le cas courant) ou le lire comme reference (pour comprendre la logique).

La checklist finale

Avant de partager un skill, verifiez ces points :

Categorie	A verifier
Qualite generale	Description specifique avec termes cles, incluant le "quoi" et le "quand"
	Corps du SKILL.md sous 500 lignes
	Pas d'information perissable
	Terminologie coherente
	Divulgation progressive si le contenu est volumineux
Code et scripts	Les scripts gerent les erreurs au lieu de les deleguer
	Pas de constantes magiques (valeurs justifiees)
	Packages requis listes et verifies
	Boucles de validation pour les operations critiques
Tests	Au moins 3 evaluations creees
	Teste avec les modeles prevus (Haiku, Sonnet, Opus)
	Teste avec des scenarios d'utilisation reels

Retour aux articles