Définissez des slash commands réutilisables sous forme de fichiers Markdown, partagez-les avec l'équipe via git et couvrez les tâches fréquentes comme la revue de code, la génération de tests et les descriptions de PR.
Claude Code inclut quelques slash commands intégrées — /help, /clear, /compact. Mais celles qui accélèrent vraiment votre flux de travail, ce sont celles que vous écrivez vous-même.
Cet article explique comment concevoir un système de slash commands réutilisables pour que toute l'équipe partage la même bibliothèque de prompts, plutôt que de réécrire les descriptions de tâches depuis zéro à chaque fois.
Dans Claude Code, une slash command personnalisée est simplement un fichier Markdown. Placez-le dans le bon répertoire, Claude Code le détecte au démarrage, et taper /nom-du-fichier l'active.
Le contenu du fichier est le prompt envoyé à Claude. C'est tout.
Pas de syntaxe spéciale, pas de format de configuration — un fichier .md est une commande.
Deux emplacements, deux rôles :
| Emplacement | Chemin | Portée |
|---|---|---|
| Projet | .claude/commands/ |
Projet actuel uniquement, peut être commité dans git |
| Utilisateur | ~/.claude/commands/ |
Tous les projets, personnel |
Le niveau projet est au cœur du partage en équipe. Commitez .claude/commands/ dans git et tous ceux qui clonent le dépôt disposent automatiquement du jeu de commandes complet.
Le niveau utilisateur convient aux habitudes personnelles — vos vérifications de style de code préférées, ou des intégrations d'outils que vous seul utilisez.
À la racine du projet :
mkdir -p .claude/commands
Créez .claude/commands/review.md :
Passez en revue la qualité du code des modifications actuelles. Concentrez-vous sur :
1. Les erreurs logiques et les cas limites
2. La clarté du nommage
3. Le code dupliqué qui mérite d'être extrait
4. Les problèmes de sécurité (injection SQL, XSS, secrets exposés)
Donnez des suggestions concrètes et actionnables — pas de conseils génériques.
Redémarrez Claude Code et tapez /review pour l'activer.
Les commandes à contenu fixe ont une utilité limitée. $ARGUMENTS les rend flexibles — ce que l'utilisateur tape après /commande est substitué dans le prompt.
Exemple .claude/commands/test.md :
Écrivez des tests pour ce qui suit : $ARGUMENTS
Exigences :
- Couvrir le chemin nominal et les cas limites
- Les noms des tests doivent être auto-explicatifs
- Utilisez des données réelles plutôt que des mocks si possible
Utilisation :
/test la méthode login de la classe UserAuthentication
Claude reçoit :
Écrivez des tests pour ce qui suit : la méthode login de la classe UserAuthentication
Exigences :
...
$ARGUMENTS peut apparaître n'importe où dans le prompt et être utilisé plusieurs fois.
Une commande, une responsabilité
N'écrivez pas une commande "tout-en-un". /review est pour la revue de code, /test pour écrire des tests, /pr pour les descriptions de PR. Les commandes ciblées sont plus faciles à mémoriser et à réutiliser.
Écrivez des prompts concrets, pas abstraits
Mauvais :
Aide-moi à optimiser ce code
Bon :
```
Optimisez ce code pour les performances. Priorisez :
1. Réduire les requêtes inutiles à la base de données (problèmes N+1)
2. Éviter les calculs répétés dans les boucles
3. Remplacer les recherches linéaires par des structures de données plus efficaces
Conservez l'interface inchangée — ne modifiez que l'implémentation.
```
Des contraintes concrètes mènent à des résultats ciblés.
Ajoutez un frontmatter à vos commandes
Le champ description apparaît dans la liste des commandes de Claude Code, pour que les membres de l'équipe comprennent rapidement l'utilité de chaque commande :
---
description: Passe en revue les modifications actuelles pour un retour sur la qualité du code
---
Passez en revue la qualité du code des modifications actuelles...
Pour un projet Rails, ces commandes couvrent les tâches de développement quotidien les plus fréquentes :
.claude/commands/review.md — Revue de code
Passez en revue les modifications dans git diff. Vérifiez :
- Les erreurs logiques et la gestion des cas limites
- Les problèmes de sécurité : injection SQL, vérifications d'autorisation
- La clarté du nommage
- La logique dupliquée qui mérite d'être extraite
Pour chaque problème, indiquez l'emplacement précis et une suggestion concrète.
```
.claude/commands/test.md — Générer des tests
Écrivez des tests pour ce code : $ARGUMENTS
Utilisez RSpec. Couvrez : chemin nominal, cas limites, conditions d'erreur.
Format de nommage : describe ... context ... it ...
Utilisez des objets réels par défaut ; mockez uniquement les dépendances externes si nécessaire.
```
.claude/commands/pr.md — Description de PR
En vous basant sur git diff et le log des commits, générez une description de PR.
Format :
(2-3 phrases résumant ce qui a été fait)
(Contexte et motivation)
(Comment vérifier ce changement)
Soyez concis, rédigé pour un relecteur de code.
```
.claude/commands/explain.md — Expliquer le code
Expliquez ce que fait $ARGUMENTS :
- Quelle est sa responsabilité globale ?
- Comment fonctionne la logique clé ?
- Quels cas limites méritent d'être notés ?
Écrivez pour un développeur nouveau sur cette partie du code. Concentrez-vous sur le pourquoi, pas seulement sur le quoi.
```
Certaines habitudes sont personnelles et ne doivent pas être imposées à toute l'équipe. Placez-les dans ~/.claude/commands/ :
~/.claude/commands/standup.md — Préparation du standup quotidien
```markdown
En vous basant sur le git log d'aujourd'hui et les TODOs ouverts, préparez un résumé pour le standup :
- Ce que j'ai terminé hier
- Ce que je prévois de faire aujourd'hui
- Des blocages éventuels
Maximum 5 phrases.
```
~/.claude/commands/refactor.md — Suggestions de refactoring
```markdown
Analysez $ARGUMENTS et suggérez des améliorations de refactoring.
Ne soulevez que des changements vraiment utiles — ne refactorisez pas pour refactoriser.
Pour chaque suggestion, expliquez : quel problème cela résout, combien de travail cela implique, quel est le risque.
```
La vraie valeur des commandes personnalisées n'est pas la productivité individuelle — c'est donner à l'équipe un vocabulaire commun.
Commitez .claude/commands/ dans votre dépôt et documentez les commandes disponibles dans votre README ou CLAUDE.md. Les nouveaux membres ont la bibliothèque de prompts accumulée par l'équipe dès qu'ils clonent le dépôt, sans avoir à tout découvrir par eux-mêmes.
À mesure que le projet évolue, les commandes évoluent aussi. Si un prompt ne fonctionne pas bien, corrigez une ligne et poussez — toute l'équipe reçoit la mise à jour. C'est la façon la moins coûteuse d'ancrer l'ingénierie de prompts au niveau de l'équipe.
.claude/
├── commands/
│ ├── review.md # Revue de code
│ ├── test.md # Générer des tests
│ ├── pr.md # Description de PR
│ └── explain.md # Expliquer le code
└── settings.json