Claude Code est la seule interface de Claude qui installe réellement des Skills depuis le disque, ce qui signifie que les conseils à son sujet diffèrent de tout ce qui a été écrit sur les instructions personnalisées. Voici un guide pratique : comment fonctionne le dossier, ce qui fait qu’un Skill mérite d’être conservé et où les gens perdent leur temps.
Comment fonctionnent les Skills dans Claude Code
Les Skills se trouvent dans un répertoire .claude/skills/. Chaque Skill est un sous-dossier contenant un fichier SKILL.md. Deux emplacements sont importants :
-
Projet -
.claude/skills/à l’intérieur du dépôt. Le Skill accompagne le code, donc toute l’équipe y a accès. C’est ici que doit se trouver tout ce qui concerne spécifiquement le projet. - Personnel - le même chemin dans votre répertoire personnel. Il s’applique à tout ce sur quoi vous travaillez. C’est ici que doivent se trouver vos propres habitudes.
Contrairement aux instructions personnalisées, qui ne peuvent contenir qu’un seul élément à la fois, Claude Code peut contenir de nombreux Skills et charger celui qui correspond à ce que vous faites. Cela change la nature d’un bon Skill : sa description doit être suffisamment précise pour que le bon soit sélectionné, et suffisamment ciblée pour qu’il ne soit pas sélectionné pour tout.
Ce qui fait qu’un Skill mérite réellement sa place
Après en avoir créé beaucoup, le constat est toujours le même. Les bons Skills encodent des décisions, pas des informations.
Un Skill qui explique ce qu’est une API REST gaspille des tokens sur quelque chose que le modèle connaît déjà. Un Skill qui indique « dans ce dépôt, chaque point de terminaison renvoie les erreurs au format RFC 7807, et les trois exceptions sont héritées du code ancien et ne doivent pas être reproduites » mérite d’être conservé indéfiniment, car il s’agit d’une décision que le modèle ne peut pas déduire.
Le test est simple : si un ingénieur compétent qui rejoint votre équipe devrait en être informé, mettez-le dans un Skill. S’il est censé déjà le savoir, laissez-le de côté.
Les catégories qui valent la peine
Revue de code selon les standards de l’équipe
Les commentaires de revue génériques sont du bruit. Un Skill de revue qui contient les conventions réelles de votre équipe, c’est-à-dire les sujets dont vous avez débattu et sur lesquels vous vous êtes mis d’accord, transforme la revue d’une opinion en une liste de contrôle.
Conventions de test
Quel framework utiliser, comment nommer un test, ce qui doit être simulé et ce qui ne doit jamais l’être, ainsi que le niveau de couverture considéré comme suffisant pour cette base de code. Sans ces indications, vous obtenez des tests dans le style le plus courant dans les données d’entraînement.
Débogage et gestion des incidents
Où se trouvent les journaux, quel tableau de bord répond à quelle question, et les quatre éléments à vérifier avant de faire remonter le problème. C’est le Skill qui s’amortit tout seul à 3 heures du matin.
Infrastructure et déploiement
La séquence de déploiement, ce qu’il est sûr d’exécuter sur la production et ce qui ne l’est pas, ainsi que les migrations qui nécessitent une fenêtre de maintenance. L’objectif est d’encoder les aspects dangereux.
Documentation et rédaction technique
Où se trouve la documentation, quelle structure suit une page, et la différence, dans votre style maison, entre un tutoriel et une documentation de référence.
Ce qu’il faut éviter
Les tutoriels de langage. Un Skill qui explique la syntaxe Python à Claude revient à expliquer la syntaxe Python à quelque chose qui la connaît déjà.
Les Skills fourre-tout gigantesques. Un seul Skill couvrant le frontend, le backend, les tests et le déploiement sera chargé en permanence, tout en étant généralement peu pertinent. Divisez-le.
Tout ce qui sera obsolète dans un mois. Les numéros de version, les objectifs du sprint en cours, le nom de la personne d’astreinte. Les Skills sont faits pour les décisions durables.
Les descriptions vagues. Si la description n’indique pas clairement quand le Skill s’applique, il ne sera soit jamais sélectionné, soit toujours sélectionné. Les deux situations sont inutiles.
Commencer avec un modèle plutôt qu’une page blanche
La partie la plus difficile n’est pas l’idée, mais sa structure : savoir jusqu’où aller dans la précision, quoi laisser de côté et comment rédiger la description pour que la sélection fonctionne. C’est cette partie qu’il vaut la peine de reprendre à partir de quelque chose qui a déjà été testé.
Nous publions des fichiers de Skills par rôle pour les développeurs, les équipes DevOps et les architectes, rédigés en .md brut et utilisables soit comme Skill Claude Code, soit en les collant dans les instructions personnalisées :
Skills Claude Code →
Skills pour développeurs →
Skills DevOps →
Skills pour architectes →
Si vous n’utilisez pas Claude Code et êtes arrivé ici par hasard, l’équivalent pour Claude sur le web est les instructions personnalisées.
KissMySkills est une place de marché indépendante et n’est pas affiliée à Anthropic, OpenAI ou à une quelconque autre entreprise d’AI, et ne bénéficie de leur soutien ni n’est liée à elles. Claude Code est un produit d’Anthropic.
