Je me suis surpris à taper le même prompt de 200 mots pour la quatrième fois en une semaine. « Écris un message de commit conventionnel pour les changements en stage, garde la première ligne sous 72 caractères, référence l'issue s'il y a un numéro dans le nom de la branche… » À. Chaque. Fois. C'est le signal qu'il faut s'arrêter et créer une commande slash. Alors configurons les commandes slash et les skills de Claude Code pour ne plus jamais retaper ça.
Les deux fonctionnalités font la même chose en substance — emballer des instructions pour les réutiliser — mais elles sont conçues pour des usages différents. Les commandes slash sont pour les choses que vous déclenchez. Les skills sont pour les choses que Claude déclenche quand une tâche le demande. Comprenez cette distinction et le reste coule de source.
Les commandes slash : vos raccourcis
Une commande slash est un prompt sauvegardé que vous lancez avec /nom. Vous en créez une en déposant un fichier markdown dans .claude/commands/ dans votre projet. Le nom du fichier devient la commande.
Réglons définitivement ce problème de prompt pour les messages de commit. Créez .claude/commands/commit.md :
Écris un message de commit conventionnel pour les changements actuellement en stage.
Règles :
- Première ligne de moins de 72 caractères, mode impératif (« Add », pas « Added »).
- Préfixe de type : feat, fix, refactor, docs, test ou chore.
- Si le nom de la branche contient un numéro d'issue, référence-le dans le corps.
- Montre-moi le message. N'exécute pas git commit toi-même.
Commence par exécuter `git diff --staged` pour voir ce qui a changé.
Maintenant, dans n'importe quelle session, je tape /commit et Claude fait tout le boulot. Quatre caractères au lieu de deux cents mots. Le fichier est la commande — tout ce qu'il contient est envoyé comme prompt quand je l'invoque.
Passer des arguments
Les commandes deviennent encore plus utiles quand elles acceptent des entrées. Utilisez $ARGUMENTS comme espace réservé. Voici .claude/commands/explain.md :
Explique comment $ARGUMENTS fonctionne dans cette base de code.
Trouve où c'est défini, trace comment c'est utilisé et donne-moi un
résumé court en langage simple. Utilise un sous-agent pour faire la
recherche afin de ne pas remplir notre conversation de dumps de fichiers.
Ensuite /explain le flux d'authentification insère « le flux d'authentification » à cet endroit. Une commande, des usages infinis. J'en ai maintenant une douzaine — /test, /review, /changelog — et elles ont silencieusement supprimé la majeure partie du travail répétitif de ma journée.
Les skills : les instructions que Claude utilise de lui-même
Les commandes slash sont parfaites quand vous savez ce que vous voulez. Mais parfois vous voulez que Claude applique des connaissances spécialisées automatiquement, en plein milieu d'une tâche, sans que vous ayez à vous souvenir d'invoquer quoi que ce soit. C'est le rôle d'une skill.
Une skill est un dossier contenant un fichier SKILL.md. Le haut de ce fichier décrit quand la skill s'applique. Claude garde cette description en tête, et quand une tâche correspond, il charge les instructions complètes de lui-même. Vous ne tapez pas de commande. Ça arrive, c'est tout.
Imaginons que votre équipe ait une façon très précise d'écrire les migrations de base de données. Créez .claude/skills/migrations/SKILL.md :
---
name: migrations
description: Comment écrire des migrations de base de données dans ce projet.
À utiliser lors de la création, de l'édition ou de la revue d'un fichier de migration.
---
Les migrations se trouvent dans db/migrations, nommées avec un préfixe d'horodatage UTC.
Chaque migration doit :
- Être réversible : inclure un up et un down.
- Ne jamais supprimer une colonne dans la même migration qui arrête d'y écrire.
Répartissez-le sur deux déploiements.
- Envelopper les changements de schéma dans une transaction.
Avant d'en écrire une, lisez les trois migrations les plus récentes pour correspondre au style.
Maintenant, quand je demande à Claude « d'ajouter une migration pour la nouvelle colonne archived_at », il remarque que la tâche correspond à la description de la skill, charge ces règles et les suit — sans que je prononce le mot « skill ». C'est toute la magie. Les connaissances apparaissent exactement quand elles sont pertinentes et restent en retrait le reste du temps.
Laquelle construire ?
Voici la règle simple que j'utilise.
Créez une commande slash quand vous décidez de l'exécuter. Messages de commit, génération d'un changelog, lancement d'une revue spécifique — ce sont des actions délibérées. Vous les invoquez.
Créez une skill quand Claude doit décider. Conventions de code, règles métier, standards de formatage — tout ce qui doit s'appliquer automatiquement dès qu'une tâche correspondante se présente. Vous ne voulez pas devoir penser à taper /migrations à chaque fois que vous touchez la base de données. Vous voulez que les règles soient simplement là.
Une bonne heuristique : si la phrase commence par « à chaque fois que Claude fait X, il devrait... » — c'est une skill. Si elle commence par « parfois je veux... » — c'est une commande.
La description est la partie porteuse
Pour les skills surtout, la ligne description est capitale. C'est ainsi que Claude décide si la skill s'applique. Une description vague, et la skill ne se déclenche jamais. Soyez précis sur le déclencheur : « À utiliser lors de la création, de l'édition ou de la revue d'un fichier de migration » dit à Claude exactement quand la réveiller. « Trucs de base de données » ne suffit pas.
C'est le même principe qu'une bonne description d'outil, honnêtement. Vous écrivez pour un agent qui doit décider, sur le moment, si ce truc est pertinent. Donnez-lui un oui ou non clair.
Commencez par ce qui vous agace le plus
Ne vous asseyez pas pour en construire vingt d'un coup. Vous devinerez mal ce dont vous avez vraiment besoin. Attendez plutôt de ressentir la friction — ce quatrième retapé, cette règle que vous réexpliquez sans cesse — et construisez celle-là. Là, tout de suite. Ça prend deux minutes et le bénéfice est immédiat.
Toute ma collection a grandi ainsi, une irritation à la fois. La commande de commit est venue de retaper des prompts de commit. La skill migrations est venue d'avoir commis la même erreur de migration deux fois. Chacune a résolu une irritation réelle et précise que je pouvais nommer.
Alors voici votre devoir. La prochaine fois que vous vous surprenez à taper un prompt que vous avez déjà tapé, arrêtez. Ouvrez .claude/commands/, créez un fichier, collez le prompt. Vous venez de vous racheter chaque copie future de ces deux minutes. Faites-le dix fois et votre configuration Claude Code cessera de sembler générique pour commencer à vous ressembler.