Les Skills de Claude Code : comment j'ai automatisé ma façon de coder

Quand l'IA code sans méthode, elle fonce tête baissée. Les skills de Claude Code imposent une discipline - brainstorming avant d'implémenter, debugging systématique, TDD. Voici comment je les utilise au quotidien, puis les best practices officielles d'Anthropic pour écrire des skills efficaces.

Le problème : une IA sans méthode

Vous demandez à Claude Code « ajoute un bouton de déconnexion ». L'IA fonce. Elle écrit du code, modifie trois fichiers, et vous livre un résultat. Parfois c'est exactement ce qu'il faut. Parfois elle a fait des hypothèses sur l'emplacement, le style, le comportement - et vous devez tout reprendre.

Le problème n'est pas la qualité du code. C'est l'absence de processus. Un bon développeur humain ne code pas immédiatement. Il réfléchit d'abord : où placer le bouton ? Faut-il une confirmation ? Que se passe-t-il côté session ? L'IA saute cette étape si on ne l'y force pas.

C'est exactement ce que font les skills de Claude Code : ils imposent un workflow à 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 à la demande. Ce fichier contient des instructions, des checklists, des règles - un workflow complet que l'IA doit suivre pour accomplir un type de tâche.

Pensez-y comme un mode opératoire. Quand un chirurgien opère, il suit un protocole précis - pas parce qu'il ne sait pas opérer, mais parce que le protocole empêche les oublis. Les skills sont le protocole de l'IA.

Concrètement, un skill est :

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

Claude Code supporte nativement le système de skills, mais la collection que j'utilise - superpowers - est un projet open source créé par Jesse Vincent (obra). Vous pouvez aussi créer les vôtres ou en installer depuis d'autres repos communautaires.

Le méta-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 à Claude Code comment utiliser tous les autres skills.

Sa règle centrale est simple :

Avant toute action ou réponse, vérifie si un skill pourrait s'appliquer. Même à 1 % de chance, invoque-le.

Pourquoi est-ce nécessaire ? Parce que sans cette règle, Claude Code a tendance à « 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 méta-skill bloque ces réflexes et force la discipline.

Le skill définit même une liste de pensées-pièges :

Il définit aussi un ordre de priorité : les skills de processus (brainstorming, debugging) passent avant les skills d'implémentation (frontend-design, etc.). La logique : on décide comment faire avant de faire.

Mes skills favoris et comment je les utilise

Brainstorming - réfléchir 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 déclenche et force Claude Code à :

1. Explorer le contexte du projet (fichiers, commits récents)
2. Poser des questions de clarification - une à la fois
3. Proposer 2-3 approches avec leurs compromis
4. Présenter un design et attendre mon approbation

La règle d'or : aucun code n'est écrit tant que le design n'est pas approuvé. Même pour un « simple » bouton.

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

Systematic Debugging - debugger avec méthode

Quand quelque chose ne marche pas, la tentation est de proposer un fix immédiat. Le skill systematic-debugging force une approche différente :

1. Observer et reproduire le problème
2. Formuler des hypothèses
3. Tester chaque hypothèse méthodiquement
4. Confirmer la cause racine avant de corriger

C'est un skill de type rigid - on le suit à la lettre, sans raccourci. La raison : le debugging est exactement le domaine où les raccourcis coûtent le plus cher. Un fix qui traite le symptôme 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. Écris un test qui échoue, écris le code minimal pour le faire passer, puis refactorise. Claude Code applique naturellement ce cycle quand le skill est actif.

Ce qui est intéressant, c'est que l'IA est particulièrement bonne en TDD, parce qu'elle n'a pas l'impatience humaine de « juste écrire le code d'abord ». Une fois le skill chargé, elle suit le protocole mécaniquement - exactement ce qu'on veut.

Verification Before Completion - pas de « c'est fini » sans preuve

Ce skill empêche Claude Code de déclarer victoire trop tôt. Avant de dire « c'est fait », il doit :

• Exécuter les commandes de vérification (tests, build, lint)
• Confirmer que la sortie est celle attendue
• Fournir des preuves (output réel, pas des suppositions)

Combien de fois une IA vous a dit « voilà, c'est corrigé » alors que le code ne compile même pas ? Ce skill élimine ce problème.

Dispatching Parallel Agents - paralléliser intelligemment

Quand un plan d'implémentation contient des tâches indépendantes, ce skill permet de lancer plusieurs sous-agents en parallèle. Chaque agent travaille sur sa tâche sans bloquer les autres. C'est particulièrement utile pour les migrations ou les refactorisations qui touchent beaucoup de fichiers.

Les best practices officielles d'Anthropic

Après avoir vu comment j'utilise les skills au quotidien, voyons maintenant les recommandations officielles d'Anthropic pour en écrire 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 structuré, et testé en conditions réelles.

Principe n°1 : la concision avant tout

La fenêtre de contexte est une ressource partagée. Votre skill cohabite avec le system prompt, l'historique de conversation, les métadonnées des autres skills, et votre requête. Chaque token compte.

La règle d'or d'Anthropic :

Claude est déjà très intelligent. N'ajoutez que le contexte qu'il ne possède pas déjà.

Avant d'écrire 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 déjà ça ? »
• « Est-ce que ce paragraphe justifie son coût en tokens ? »

La version concise suppose que Claude sait ce qu'est un PDF et comment fonctionnent les librairies. Trois fois moins de tokens, même résultat.

Principe n°2 : calibrer les degrés de liberté

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

• Pont étroit avec des falaises - il n'y a qu'un seul passage sûr. Donnez des instructions exactes, pas de marge. Exemple : une migration de base de données qui doit s'exécuter dans un ordre précis.
• Champ ouvert sans obstacle - plein de chemins mènent au succès. Donnez la direction générale et laissez Claude trouver le meilleur chemin. Exemple : une review de code où le contexte détermine l'approche.

Bien structurer un skill

Le nommage

Anthropic recommande la forme gérondive (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 caractères maximum
• Minuscules, chiffres et tirets uniquement
• Pas de mots réservés (anthropic, claude)

La description - le facteur critique

La description dans le frontmatter est ce qui permet à Claude de découvrir votre skill parmi potentiellement 100+ skills disponibles. Deux règles :

1. Écrire à la 3e personne - la description est injectée dans le system prompt, un « I can help you » ou « You can use this » crée des problèmes de découverte
2. Inclure le « quoi » ET le « quand » - décrire ce que fait le skill et dans quel contexte l'utiliser

La divulgation progressive

Le SKILL.md doit rester sous 500 lignes. Au-delà, éclatez le contenu dans des fichiers séparés que Claude charge à la demande. Quand l'utilisateur pose une question sur le remplissage de formulaire, Claude ne charge que le fichier concerné - pas la référence API, pas les exemples. Résultat : moins de tokens consommés, plus de place pour l'historique de conversation.

Règle importante : gardez les références à un seul niveau de profondeur. Le SKILL.md pointe vers des fichiers, mais ces fichiers ne doivent pas pointer vers d'autres fichiers.

Les erreurs à éviter

Trop d'options

Ne présentez pas 5 librairies au choix. Donnez un choix par défaut avec une alternative si nécessaire.

Les informations périssables

Évitez les références temporelles qui deviendront fausses (« si vous faites cela avant août 2025... »). Documentez la méthode actuelle, et reléguez les anciens patterns dans un bloc dépliable marqué comme déprécié.

La terminologie incohérente

Choisissez un terme et gardez-le partout. Ne mélangez pas « API endpoint », « URL », « API route » et « path » dans le même skill. La cohérence aide Claude à comprendre et suivre les instructions.

Développer un skill de façon itérative

La recommandation la plus intéressante d'Anthropic concerne le processus de développement lui-même. Au lieu d'écrire un skill parfait du premier coup, ils proposent un cycle avec deux instances de Claude :

1. Complétez une tâche sans skill - travaillez avec « Claude A » en prompting normal. Notez les informations que vous fournissez plusieurs fois
2. Demandez à Claude A de créer le skill - il connaît nativement le format et la structure des skills
3. Testez avec Claude B - une instance fraîche avec le skill chargé, sur des tâches similaires
4. Observez le comportement - est-ce qu'il trouve les bonnes infos ? Applique les règles ? Rate quelque chose ?
5. Retournez à Claude A - « Quand Claude B a utilisé ce skill, il a oublié de filtrer par date. Comment améliorer ? »
6. Itérez - ce cycle observe-affine-teste est continu

Autre conseil : créez des évaluations avant d'écrire le skill. Identifiez d'abord où Claude échoue sans skill, construisez des scénarios de test, puis écrivez le minimum d'instructions pour passer ces tests. C'est du TDD appliqué aux skills.