Créer des commandes slash personnalisées dans Claude Code

Que sont les commandes slash personnalisées ?

Claude Code est livré avec des commandes slash intégrées comme /help et /clear, mais saviez-vous que vous pouvez facilement ajouter vos propres commandes ? Les commandes slash personnalisées vous permettent d’invoquer des prompts fréquents ou des tâches routinières avec un mot-clé court, et les maîtriser peut considérablement accélérer votre développement quotidien.

Au lieu de taper un long prompt comme « Examine le code de la branche actuelle » à chaque fois, il suffit de taper /review pour déclencher le même comportement. Partagez des commandes au sein de votre équipe et vous pouvez standardiser les critères de revue ou les procédures de release.

Emplacement et format des fichiers

Les commandes slash personnalisées sont de simples fichiers Markdown. Il existe deux emplacements de stockage :

• Spécifique au projet : .claude/commands/<nom-commande>.md
• Global à l’utilisateur : ~/.claude/commands/<nom-commande>.md

Les commandes spécifiques au projet peuvent être commitées dans votre dépôt et partagées avec les coéquipiers, tandis que les commandes globales de l’utilisateur sont disponibles dans tous vos projets. Le nom du fichier devient le nom de la commande, donc review.md devient /review.

Créer votre première commande

Commençons par la commande la plus simple possible. Exécutez ceci depuis la racine de votre projet :

mkdir -p .claude/commands
cat > .claude/commands/review.md <<'EOF'
Lis tous les changements actuellement dans la zone de staging Git et
examine-les sous les angles suivants :

- Bugs potentiels
- Cohérence des noms
- Couverture de tests manquante
- Préoccupations de sécurité

Si tu trouves des problèmes, signale-les avec les noms de fichiers et les numéros de ligne.
EOF

C’est tout. Quand vous tapez /review dans Claude Code, le contenu du fichier est envoyé comme prompt.

Accepter des arguments

Pour rendre les commandes plus utiles, laissez-les accepter des arguments. Utilisez l’espace réservé $ARGUMENTS dans votre Markdown et la chaîne que vous passez lors de l’invocation y sera injectée.

# .claude/commands/explain.md

Explique soigneusement le fichier ou symbole suivant, d'une manière
que les débutants puissent suivre.

Cible : $ARGUMENTS

Ton explication doit inclure :
1. Un résumé en une ou deux phrases de ce que fait le code
2. Un parcours étape par étape des lignes importantes
3. Un exemple d'utilisation réaliste
4. Les pièges courants à éviter

Invoquez-la avec /explain src/utils/parser.ts. Le jeton $ARGUMENTS est remplacé par src/utils/parser.ts avant l’exécution.

Commandes référençant plusieurs fichiers

En plus de passer les chemins de fichiers comme arguments, vous pouvez utiliser la syntaxe @ dans une commande pour charger explicitement des fichiers spécifiques.

# .claude/commands/check-types.md

Après avoir lu @tsconfig.json et @package.json, trouve toutes les
erreurs de type dans l'ensemble du projet.

Étapes :
1. Exécute `npx tsc --noEmit`
2. Groupe les erreurs par fichier
3. Suggère un ordre de priorité de correction
4. Trie d'abord par la taille de la zone impactée

Affiche le résultat sous forme de tableau.

Claude lit automatiquement tsconfig.json et package.json avant de commencer à travailler sur la commande.

En pratique : une commande de préparation de release

Voici un exemple qui encapsule un workflow de release typique dans une seule commande.

# .claude/commands/release.md

Prépare la release pour la version $ARGUMENTS.

Étapes :
1. Met à jour le champ `version` dans package.json à $ARGUMENTS
2. Ajoute une nouvelle section au début de CHANGELOG.md
   - Référence le git log depuis le tag précédent
   - Catégorise en feat / fix / docs / chore
3. Exécute `npm run test` et confirme que tous les tests passent
4. Exécute `npm run build` et confirme qu'il n'y a pas d'erreurs de build
5. Résume les changements et propose un message de commit

Important : N'exécute pas `git push` ni `npm publish` toi-même.
Laisse la confirmation finale à l'utilisateur.

Taper /release 1.4.0 gère tout, du bump de version à l’exécution des tests. Pour la sécurité, évitez les opérations destructives et laissez un humain confirmer l’étape finale.

Simuler des flags et options

Vous pouvez décrire une logique de branchement en Markdown pour simuler des flags.

# .claude/commands/test.md

Arguments : $ARGUMENTS

Suis ces règles :

- Si les arguments sont vides : exécute tous les tests
- Si les arguments contiennent `--unit` : exécute uniquement les tests unitaires
- Si les arguments contiennent `--e2e` : exécute uniquement les tests E2E
- Si un chemin de fichier est inclus : exécute uniquement les tests liés à ce fichier

Après l'exécution, analyse la cause des tests ayant échoué.

Des appels comme /test --unit ou /test src/auth.ts deviennent possibles.

Bonnes pratiques pour le partage en équipe

Placez les commandes spécifiques au projet dans .claude/commands/ et gérez-les avec Git pour que chaque membre de l’équipe utilise les mêmes commandes. Gardez ceci à l’esprit :

• Utilisez une convention de nommage cohérente : verbe en premier, noms courts (review, fix, explain)
• Documentez-les dans le README : rendez les commandes faciles à découvrir
• Évitez les opérations destructives : interdisez explicitement des choses comme git push --force ou rm -rf
• Spécifiez le format de sortie : gardez les résultats de revue cohérents avec des tableaux ou des checklists

Pour conclure

Les commandes slash personnalisées sont le chemin le plus court pour transformer Claude Code en « votre propre assistant IA personnel ». Commencez avec une ou deux commandes simples et ajoutez-en davantage chaque fois que vous repérez une tâche répétitive. Avant longtemps, elles deviendront une partie indispensable de votre workflow.

Pour les bases de Claude Code, consultez le guide de démarrage. Pour une automatisation plus avancée, voir Premiers pas avec l’Agent SDK, et pour des astuces sur le contexte, consultez Gestion du contexte.

Pour la documentation officielle, référez-vous à la documentation Anthropic.