Slash commands custom

Qu’est-ce qu’une slash command ?

Dans Claude Code, une slash command est un fichier Markdown placé dans un dossier conventionnel. Quand l’utilisateur tape /nom-de-la-commande dans le prompt, le contenu du fichier est injecté comme prompt à l’agent. C’est un mécanisme purement déclaratif : pas de code à écrire, pas d’API à appeler.

Point clé : Une slash command n’est pas un script. C’est un prompt encapsulé dans un fichier, que l’agent exécute comme n’importe quelle instruction utilisateur. La différence avec un prompt tapé à la main : reproductibilité et partage.

Emplacement des fichiers

Le nom du fichier (sans extension) devient la commande. Un fichier .claude/commands/review.md crée la commande /review.

Anatomie d’un fichier de commande

Le contenu du fichier .md est le prompt envoyé à l’agent. Il peut contenir des instructions structurées, des contraintes, un format de sortie attendu, et même la variable $ARGUMENTS pour recevoir des paramètres de l’utilisateur.

# .claude/commands/review.md

Fais une revue de code du diff actuel.

## Contraintes
- Vérifie la cohérence avec l'architecture hexagonale
- Signale les violations de SRP
- Propose des refactorings concrets

## Format de sortie
Liste chaque remarque avec :
1. Fichier et ligne
2. Sévérité (critique / avertissement / suggestion)
3. Explication et correction proposée

Point clé : La variable $ARGUMENTS capture tout ce que l’utilisateur tape après la commande. Exemple : /refactor-extract UserService.cs remplace $ARGUMENTS par UserService.cs dans le prompt.

Cas d’usage et bonnes pratiques

Workflows récurrents typiques

• /review — Revue de code structurée avec critères prédéfinis
• /security-review — Audit sécurité ciblé (injections, auth, secrets)
• /refactor-extract-method — Extraction de méthode guidée avec vérification des tests
• /ddd-aggregate-from-spec — Génération d’un agrégat DDD à partir d’une spécification métier
• /init — Bootstrap d’un CLAUDE.md pour un nouveau projet

Règles de conception

Un seul objectif par commande. Une commande qui fait review + refactoring + tests est trop ambitieuse. L’agent perd le fil et la qualité chute.

Spécifier le format de sortie. Sans format explicite, l’agent produit du texte libre difficilement exploitable. Imposer une structure (tableau, checklist, JSON) rend la sortie actionnable.

Inclure les contraintes d’architecture. Une commande /review générique ne vérifie pas les règles spécifiques du projet. Mentionner explicitement hexagonal, DDD, conventions de nommage.

Piège classique : Créer une commande trop générique (/do-everything) ou, à l’inverse, trop spécifique (/rename-variable-in-line-42). Le bon grain se situe au niveau du workflow : une tâche que l’équipe répète régulièrement avec les mêmes critères de qualité.

Commandes projet vs utilisateur

La distinction entre les deux portées est stratégique pour une équipe :

Point clé : Les commandes projet doivent être traitées comme du code : revues, versionnées, documentées. Elles encodent le savoir-faire de l’équipe.

Attention : En cas de conflit de noms, la commande projet a priorité sur la commande utilisateur. Cela peut créer de la confusion si un développeur s’attend à sa version personnelle.

Slash commands vs hooks vs CLAUDE.md

Ces trois mécanismes sont complémentaires mais ne couvrent pas les mêmes besoins :

Règle simple : Une slash command est un workflow déclenché à la demande. Un hook est une garantie automatique. CLAUDE.md est un guidage permanent. Les trois se complètent sans se remplacer.