Les slash commands sont la superpuissance cachée de Claude Code.

La plupart des gens utilisent /init, puis oublient que le système existe. C’est laisser 80 % de la productivité sur la table.

Bien utilisées, les slash commands transforment Claude Code en CLI opinionée : un keystroke = un workflow reproductible. Passons en revue les commandes intégrées, puis bâtissons un projet du dossier vide à l’app qui tourne avec rien d’autre que des slash commands.

Les quatre commandes intégrées qu’il faut connaître

/init

À lancer une fois par projet. Crée .claude/ avec settings.json, CLAUDE.md et agents/. Sans elle, chaque session démarre froide.

/agents

Ouvre le sélecteur de sub-agents. Les sub-agents sont des personas Claude spécialisés (on couvre l’ensemble dans l’article 5). Utilisez /agents pour invoquer code-reviewer, test-writer, migration-runner etc. sans retaper leurs system prompts.

/compact

La plus sous-estimée. À mesure qu’une session grandit, la fenêtre de contexte enfle avec les vieux appels d’outils et les fichiers abandonnés. /compact re-résume la conversation en gardant les décisions intactes.

/clear

Option nucléaire. Supprime tout l’historique. Utile quand vous passez de « implémenter la feature X » à « débuger un échec CI sans rapport » — contexte frais, attention fraîche.

Commandes personnalisées — le vrai levier

Les commandes personnalisées vivent dans .claude/commands/<nom>.md. Ce sont juste des fichiers markdown qui sont collés dans la conversation quand vous tapez /<nom>.

Exemple : /feature

.claude/commands/feature.md :

Tu vas implémenter une nouvelle fonctionnalité.

Utilise ce template :

# Objectif
{{décrire le résultat avec un chiffre quand c'est possible}}

# Contraintes
- Ne pas casser les tests existants.
- Ne pas ajouter de nouvelle dépendance sans demander.
- Garder les changements limités aux fichiers listés.

# Definition of Done
- pnpm test passe.
- pnpm lint propre.
- Ajouter une description de PR (1 paragraphe).

# Fichiers
{{lister les fichiers concernés}}

Attends que l'utilisateur remplisse les blancs avant de commencer.

Dans votre terminal :

> /feature

Claude Code l’étend. Vous remplissez les blancs. Votre structure de prompt est désormais imposée — chaque feature a la même forme.

Exemple : /test-and-fix

.claude/commands/test-and-fix.md :

1. Lance `pnpm test`.
2. Si échecs : lis chaque test qui échoue, déduis le bug, corrige le code (pas le test), relance.
3. Arrête-toi seulement quand `pnpm test` sort 0.
4. Rapporte un résumé de 3 lignes des changements.

Maintenant /test-and-fix est une commande « répare le build » à un seul keystroke. Magnifique pour trier un CI flaky.

Exemple : /release-notes

.claude/commands/release-notes.md :

1. `git log --oneline ${LAST_TAG}..HEAD`
2. Regroupe les commits en : features / fixes / chores.
3. Écris une entrée de changelog en markdown, sans blabla, max 25 lignes.
4. Sauvegarde dans CHANGELOG.md et stage-le.

De A à Z — construire un projet uniquement avec des slash commands

Démontrons. On va scaffolder un petit service Next.js + tRPC depuis un dossier vide, avec une règle : aucune édition manuelle, seulement des slash commands et des prompts.

mkdir todo-service && cd todo-service
claude

Dans Claude :

> /init

→ Crée .claude/ et demande un CLAUDE.md. Remplissez :

# Contexte du projet
- Petit service Next.js 14 + tRPC + drizzle pour des todos.
- TS strict, pnpm, vitest.

# Conventions
- Test : pnpm test
- Lint : pnpm lint
- Format : pnpm fmt

# Definition of done
- Tests passent, lint propre, pas de console.log dans src/.

Puis :

> /feature
> Objectif : Bootstrapper une app Next.js 14 avec tRPC + drizzle (sqlite) et une table todos.
> Contraintes :
>   - pnpm uniquement.
>   - Utiliser le starter officiel create-next-app + tRPC, pas un fork.
>   - TS strict.
> Definition of Done :
>   - pnpm dev tourne.
>   - GET /api/trpc/todos.list retourne [].
> Fichiers : (repo vide)

Claude scaffolde, installe, lance le dev server, frappe l’endpoint pour vérifier, rend un diff.

> /feature
> Objectif : Ajouter POST todos.create avec validation zod, persistance via drizzle.
> Contraintes :
>   - Réutiliser le client drizzle dans lib/db.ts.
>   - 1 vitest couvrant create + list.
> Definition of Done :
>   - vitest vert.
>   - typecheck propre.
> Fichiers : src/server/api/routers/todos.ts, lib/db.ts

Claude écrit la procédure, le schéma, le test, le lance, rend un diff.

> /test-and-fix

Si quelque chose a cassé, il le répare.

> /release-notes

Changelog écrit.

> git checkout -b feat/todos && git add . && git commit -m "feat: todos.create + list"

Vous n’avez pas ouvert un seul fichier. Le diff est relisable ; le travail est fait.

Anti-patterns

• /feature sans remplir les blancs. Annule l’intérêt ; l’agent devine.
• Commandes personnalisées qui se contentent de répéter un paragraphe. Une commande personnalisée doit encoder un workflow (étapes, checks), pas juste un ton.
• Stocker les slash commands hors du repo. Commitez .claude/commands/ pour que l’équipe partage le même vocabulaire.

L’angle équipe

Quand .claude/commands/ est dans git, vous expédiez en réalité une mémoire musculaire partagée. Les nouvelles recrues héritent gratuitement de votre /feature, /review, /release-notes. Au bout de 3 à 4 semaines, chaque équipe avec laquelle j’ai travaillé a 8 à 12 commandes personnalisées, et l’onboarding sur Claude Code passe de « une semaine » à « une matinée ».

---

Article suivant : Sub-agents — les 11 experts spécialisés à l’intérieur de Claude Code. Les slash commands réutilisent des prompts. Les sub-agents réutilisent des personas entiers. C’est ça, le déclic.