Chapitre 10.2 — Commandes slash sur-mesure

⏱️ TL;DR — Une commande sur-mesure, c’est un fichier Markdown dans .claude/commands/ (projet) ou ~/.claude/commands/ (perso) : son nom devient /nom, son contenu est le prompt injecté quand tu l’invoques. C’est le moyen le plus simple d’encapsuler un prompt que tu répètes (« relis cette PR selon nos critères », « génère un commit conventionnel »). Plus léger qu’une skill : une commande est un raccourci de prompt, pas une capacité riche avec ressources. Tu peux lui passer des arguments.

🎯 Objectifs

Créer une commande slash sur-mesure.
Lui passer des arguments.
Choisir entre commande et skill.
Ranger tes commandes (projet vs perso).

Créer une commande

Une commande, c’est un fichier Markdown dont le nom de fichier donne le nom de la commande, et dont le contenu est le prompt :


.claude/commands/revue.md      →  /revue
~/.claude/commands/commit.md   →  /commit

Exemple, .claude/commands/revue.md :


Relis le diff courant selon nos critères TaskFlow :
- correction (bugs, cas d'erreur/vide, revalidation après mutation) ;
- respect du CLAUDE.md (no-any, server actions, tokens, UI depuis @/components/ui) ;
- pas de hors-périmètre.
Pour chaque point : fichier:ligne, problème, gravité. N'invente rien.

Désormais, taper /revue injecte ce prompt. Tu as encapsulé un prompt récurrent : plus besoin de le réécrire à chaque fois.

Passer des arguments

Une commande peut recevoir des arguments que tu places dans le prompt (via un emplacement dédié, souvent $ARGUMENTS). Exemple .claude/commands/scaffold.md :


Scaffolde une nouvelle feature nommée « $ARGUMENTS » au gabarit TaskFlow
(queries/actions/schema/components + tests), selon le CLAUDE.md.

Usage : /scaffold projects → l’argument projects est injecté. Ça rend la commande paramétrable sans en faire dix variantes.

📚 Aller plus loin — La syntaxe exacte des arguments (et d’éventuelles options avancées : exécuter une commande shell dans le prompt, référencer un fichier…) est dans la doc. Le principe — un fichier Markdown = une commande, son contenu = le prompt — est stable ; vérifie les détails de syntaxe au moment d’écrire.

Commande ou skill ?

Les deux s’invoquent par /nom, d’où la confusion (CONTEXT.md). La distinction :

	Commande	Skill
Nature	un prompt figé injecté	une capacité (instructions + ressources + logique)
Déclenchement	par toi (`/nom`)	par toi ou par le modèle (si ça matche)
Richesse	simple, un fichier	peut embarquer scripts, références, progressive disclosure
Idéal pour	un prompt récurrent	un workflow réutilisable et « intelligent »

Règle : prompt récurrent simple → commande ; workflow riche, éventuellement auto-déclenché, avec ressources → skill (Partie 9). Commence par une commande ; si le besoin grossit (ressources, déclenchement auto, logique), promeus-la en skill.

💡 Réflexe d’architecte — Ne sur-ingénie pas. Beaucoup de choses que les gens transforment en skills sont juste des prompts récurrents → une commande d’une ligne suffit. La skill se justifie quand il y a de la logique, des ressources, ou un auto-déclenchement souhaité. Commande d’abord, skill si ça le mérite.

Ranger ses commandes

Projet (.claude/commands/) : versionnées, partagées avec l’équipe (ex. /revue avec vos critères). Tout contributeur en hérite.
Perso (~/.claude/commands/) : tes raccourcis à toi, sur tous tes projets (ex. /commit à ton goût).

Comme les autres briques, elles peuvent aussi provenir d’un plugin (préfixées, cf. 9.4). Ta config actuelle n’a aucune commande sur-mesure — un gisement simple : la première /revue ou /commit te fait gagner du temps dès aujourd’hui.

🧭 Sur TaskFlow — On ajoutera à TaskFlow une commande /revue (les critères de revue du projet) — versionnée, donc partagée. C’est le pendant « léger » de l’agent reviewer (P8) : la commande injecte les critères dans la session courante ; l’agent, lui, relit dans un contexte isolé. On choisit selon qu’on veut un regard dans la session (commande) ou à côté (subagent).

✏️ Exercices

Exercice 1 — Ta première commande. Repère un prompt que tu réécris souvent. Crée-le en commande (.claude/commands/nom.md). Invoque /nom : gain de temps ?

✅ Solution

Bons candidats : /revue (tes critères de revue), /commit (format de message), /test (générer les tests d’un fichier). Dès la deuxième invocation, tu rentabilises. C’est l’automatisation la plus simple de tout l’écosystème — et souvent la plus négligée.

Exercice 2 — Commande ou skill ? Prends 3 idées d’automatisation. Pour chacune, tranche commande (prompt simple) vs skill (logique/ressources/auto-déclenchement). Sur quel critère ?

✅ Solution

Critère : y a-t-il de la logique, des ressources, ou un besoin d’auto-déclenchement ? Si non → commande (plus simple). Si oui → skill. « Injecte mes critères de revue » = commande ; « scaffolde une feature avec un template et s’active sur “nouvelle feature” » = skill. On commence commande, on promeut si ça grossit.

🧠 Quiz de révision

1. Comment crée-t-on une commande sur-mesure ?

Un fichier Markdown dans .claude/commands/ (projet) ou ~/.claude/commands/ (perso) : le nom de fichier = /nom, le contenu = le prompt injecté à l’invocation.

2. Comment paramétrer une commande ?

Avec des arguments injectés dans le prompt (emplacement dédié, souvent $ARGUMENTS) : /scaffold projects passe projects. Ça évite de multiplier les variantes.

3. Commande vs skill : la distinction ?

La commande est un prompt figé injecté (par toi). La skill est une capacité (instructions + ressources + logique), invocable aussi par le modèle. Prompt simple → commande ; workflow riche → skill.

4. Quand promouvoir une commande en skill ?

Quand le besoin gagne de la logique, des ressources, ou un souhait d’auto-déclenchement. Tant que c’est un prompt simple, la commande suffit — ne sur-ingénie pas.

5. Projet vs perso pour une commande ?

Projet (.claude/commands/, versionné) pour la partager à l’équipe (ex. /revue avec vos critères) ; perso (~/.claude/commands/) pour tes raccourcis transverses (ex. /commit).

Chapitre suivant : Plugins : le catalogue — ce qui est disponible d’un clic.