Commandes personnalisées

Claude Code est livré avec des commandes intégrées, accessibles en tapant /. Vous les utiliserez tous les jours, mais elles ne connaissent rien de votre projet. Dès qu’une même consigne revient chaque semaine — auditer les dépendances, écrire des tests selon vos conventions, préparer une release —, la retaper à l’identique devient absurde. Vous pouvez créer vos propres commandes pour automatiser ces tâches répétitives, et le mécanisme est plus simple que ce que l’on imagine : une commande n’est rien d’autre qu’un fichier Markdown contenant le prompt que vous auriez écrit à la main.

Créer une commande personnalisée

Pour créer une commande, mettez en place cette structure de dossiers dans votre projet :

Trouvez le dossier .claude dans le répertoire de votre projet
Créez un nouveau répertoire commands à l’intérieur
Créez un fichier Markdown avec le nom de votre commande (ex: audit.md)

Le nom du fichier devient le nom de la commande : audit.md crée la commande /audit. Comme ces fichiers vivent dans le dépôt, ils se versionnent et se partagent naturellement. La commande que vous écrivez ce matin est disponible pour toute l’équipe après un simple git pull, et elle évolue avec le projet au lieu de rester dans un fichier de notes personnel.

Exemple : commande d’audit

Voici un exemple pratique d’une commande qui audite les dépendances du projet :

Effectue un audit de securite des dependances du projet :

1. Execute npm audit pour trouver les packages vulnerables
2. Execute npm audit fix pour appliquer les mises a jour
3. Lance les tests pour verifier que les mises a jour n'ont rien casse
4. Resume les resultats

Le contenu du fichier n’a rien de magique : c’est mot pour mot le message que vous auriez tapé. Ce qui change, c’est que la procédure est désormais figée. Personne n’oubliera de relancer les tests après le npm audit fix, parce que l’étape 3 est écrite dans le fichier et non dans la mémoire de celui qui lance l’audit un vendredi soir.

Après avoir créé le fichier, vous devez redémarrer Claude Code pour qu’il reconnaisse la nouvelle commande. C’est l’oubli classique des débuts : la commande n’apparaît pas dans la liste, on soupçonne une faute de frappe dans le chemin, on déplace le fichier deux fois, alors qu’il suffisait de relancer la session.

Commandes avec arguments

Une commande entièrement figée ne va pas très loin, car vous voudrez presque toujours lui désigner une cible. Le placeholder $ARGUMENTS remplit ce rôle : tout ce que vous tapez après le nom de la commande vient s’y substituer.

Ecris des tests complets pour : $ARGUMENTS

Conventions de test :
- Utilise Vitest avec React Testing Library
- Place les fichiers de test dans un dossier __tests__
- Nomme les fichiers de test [nom].test.ts(x)

Couverture :
- Teste les cas nominaux (happy path)
- Teste les cas limites (edge cases)
- Teste les etats d'erreur

Vous pouvez ensuite lancer cette commande avec un chemin de fichier :

/write_tests le fichier use-auth.ts dans le dossier hooks

Regardez la structure de ce fichier, car c’est le modèle à reprendre pour toutes vos commandes : la partie variable tient dans $ARGUMENTS, tandis que la partie stable — vos conventions de test, votre exigence de couverture — est écrite une fois pour toutes et ne dépend plus de ce que chacun pense à préciser. Les arguments peuvent être n’importe quel texte destiné à donner du contexte à Claude ; une phrase en français fonctionne aussi bien qu’un chemin de fichier, comme le montre l’exemple ci-dessus.

Avantages clés

Le gain le plus visible est l’automatisation : un workflow en cinq étapes devient une commande unique, et le coût de le déclencher tombe presque à zéro. Vient ensuite la cohérence, souvent plus précieuse encore, car les mêmes étapes sont suivies à chaque fois, quel que soit le développeur qui lance la commande ou le jour de la semaine. Une revue de sécurité exécutée à l’identique par cinq personnes vaut mieux que cinq revues improvisées, même si chacune d’elles est faite avec sérieux.

Ces fichiers servent aussi de vecteur de contexte : ils fournissent à Claude des instructions et des conventions spécifiques qu’il serait fastidieux de rappeler à chaque demande, comme votre bibliothèque de test ou votre organisation de dossiers. La flexibilité complète le tableau grâce aux arguments, qui permettent d’adapter une même commande à un fichier, un module ou une fonctionnalité différente sans jamais dupliquer le fichier.

Les commandes personnalisées sont particulièrement utiles pour les workflows spécifiques à un projet : lancer des suites de tests, déployer du code ou générer du boilerplate selon les conventions de votre équipe. Pour commencer, prenez la tâche que vous avez le plus répétée cette semaine — c’est celle dont le fichier sera rentabilisé le plus vite.