Commandes slash (Slash Commands) : Un seul / pour appeler toutes les actions rapides de Claude

📚 Navigation de la série : Le chapitre précédent 35 Contrôle et modes vous a appris à tendre ou à relâcher la laisse de Claude au cours d'une session (via les modes de permission et les interrupteurs comme /model ou /effort). Ce chapitre replace l'attention sur un point d'entrée que vous utilisez quotidiennement mais sans forcément en maîtriser tous les recoins : les commandes slash. Saisissez un simple / pour accéder à un menu regroupant le changement de modèle, l'effacement du contexte ou vos propres enchaînements d'actions personnalisés. Je vais vous présenter l'ensemble des commandes intégrées, puis vous expliquer comment concevoir les vôtres.

Beaucoup de personnes ont fait une erreur plutôt bête à leurs débuts avec Claude Code.

Chaque fois qu'elles voulaient vider la conversation et repartir de zéro, elles effectuaient sagement le rituel suivant : quitter claude avec Ctrl+C, puis relancer claude dans le terminal, attendre le rechargement du projet et la lecture de CLAUDE.md — le tout prenant une bonne dizaine de secondes. Après avoir fait cela pendant une semaine ou deux, elles pensaient encore : « C'est un redémarrage, c'est normal que ce soit comme ça ». Jusqu'à ce qu'elles tombent sur la commande /clear dans la documentation officielle, décrite en une phrase comme « démarrer une nouvelle conversation avec un contexte vide ». C'est là qu'elles ont réalisé : il suffisait de saisir trois caractères au sein de la session, et toutes ces fermetures et relances pendant deux semaines n'étaient qu'une perte de temps.

Et ce n'est pas tout. Elles ont découvert que /compact permettait de compresser les longues conversations pour continuer à échanger, /model de changer de modèle sans redémarrage, /init de générer CLAUDE.md en un clic... Autant d'actions qu'elles faisaient manuellement avec difficulté, ou dont elles ignoraient tout simplement l'existence. Ces commandes étaient là, sous leurs yeux, dans le menu déroulant déclenché par /, prêtes à être listées par un simple slash, sans qu'elles n'aient jamais pensé à le faire.

Si je partage cette anecdote, c'est pour vous éviter de faire les mêmes détours : les commandes slash ne sont pas des « fonctionnalités avancées », elles constituent le panneau de contrôle de base de Claude Code. La grande majorité des « méta-opérations » que vous souhaitez effectuer au cours d'une session — non pas lui demander de coder, mais configurer l'outil lui-même — trouvent leur point d'entrée dans ce seul symbole /. Ce chapitre va vous présenter les commandes intégrées pour que vous les connaissiez toutes, puis vous expliquer comment condenser vos invites quotidiennes répétitives sous forme de commandes personnalisées accessibles en un clic.

À la fin de ce chapitre, vous obtiendrez :

• Une définition simple de ce qu'est une commande slash, et pourquoi elle doit impérativement se situer en début de message ;
• Une liste des commandes intégrées classées par cas d'usage (comme /help, /clear, /compact, /init, /model, /agents, /mcp, /memory, etc.), à consulter selon vos besoins sans avoir à les apprendre par cœur ;
• La procédure complète pour concevoir votre propre commande slash : déposer un fichier markdown dans le répertoire .claude/commands/, y ajouter un frontmatter et passer des paramètres avec $ARGUMENTS ;
• Une technique avancée : configurer une commande pour qu'elle injecte d'elle-même des « données dynamiques » (comme un git diff) avant d'envoyer la requête à Claude ;
• Le concept de l'espace de noms (namespace), garantissant qu'une commande fournie par un plugin n'entre jamais en conflit avec les vôtres ;
• La relation exacte entre une commande slash et un Skill (en résumé : la commande slash est l'appel direct d'un Skill, comme détaillé au chapitre 26) ;
• Un exercice pratique pas à pas avec résultats attendus : concevoir et valider une commande /explain paramétrable en 5 minutes.

---

01 Comprendre : Ce qu'est réellement une commande slash, et pourquoi elle n'agit qu'en début de ligne

Commençons par une conclusion claire : les commandes slash sont des « consignes de contrôle » saisies dans votre session Claude — elles ne s'adressent pas à Claude pour lui faire faire du travail, mais commandent directement le programme Claude Code lui-même : changer de modèle, vider le contexte, lancer un processus ou ouvrir un panneau de configuration.

Si vous repensez aux trente chapitres précédents, vos interactions avec Claude se divisent en deux types d'expressions. D'une part, les requêtes de travail : « aide-moi à refactoriser cette fonction », « d'où vient cette erreur » — qui s'adressent au modèle. D'autre part, les méta-opérations : « vide la conversation pour recommencer », « bascule sur un modèle plus économique », « génère une description du projet » — qui ne devraient pas faire l'objet d'une discussion avec le modèle, mais disposer d'un interrupteur direct. Les commandes slash constituent le point d'entrée unique de ces interrupteurs.

Analogie : Les touches sérigraphiées d'une télécommande. Lorsque vous regardez la télévision, pour changer de chaîne, régler le volume, modifier la source ou ouvrir le menu, vous ne criez pas à l'écran « s'il te plaît, monte le son » ; vous appuyez sur la touche correspondante de votre télécommande. Chaque touche effectue une action précise, s'exécute instantanément, sans avoir à être expliquée et sans risque de contresens. Les commandes slash sont cette rangée de touches pour Claude Code : /clear est la touche pour effacer l'écran, /model celle pour changer de source (modèle), /help ouvre le menu — les exécuter déclenche une action figée codée dans le programme, ce qui n'a rien à voir avec « demander de l'aide au modèle ».

La documentation officielle définit leur rôle très simplement :

Les commandes contrôlent Claude Code depuis l'intérieur de la session. Elles permettent de changer rapidement de modèle, de gérer les permissions, de vider le contexte, de lancer des flux de travail, etc.

Il existe un point sur lequel les débutants trébuchent fréquemment, et sur lequel la documentation officielle insiste : les commandes slash ne sont identifiées qu'en début de message :

Les commandes ne sont reconnues qu'au tout début d'un message. Le texte qui suit le nom de la commande lui est transmis en tant que paramètre.

En clair : le symbole / doit impérativement être le premier caractère du message pour être interprété comme une commande. Si vous écrivez « explique-moi à quoi sert /clear », le /clear se trouvant au milieu de la phrase ne sera pas exécuté ; il sera envoyé à Claude comme du texte classique. Cette conception est logique — sans cela, mentionner /clear en discutant d'une commande viderait instantanément la session, ce qui serait ingérable. Retenez bien : la commande commence le message, et tout ce qui suit constitue ses paramètres.

Voici quelques situations concrètes pour illustrer quand utiliser ces « touches » :

• Vous réalisez en cours d'échange que le modèle manque de puissance — inutile de quitter et de rouvrir, saisissez /model pour basculer sur un modèle supérieur sur-le-champ sans couper la discussion.
• Une tâche est accomplie et vous souhaitez passer à un tout autre sujet — saisissez /clear pour nettoyer le plan de travail, sachant que la session précédente reste accessible via /resume.
• Vous venez de cloner un projet inconnu et voulez que Claude se l'approprie — saisissez /init pour qu'il analyse le code et génère un fichier CLAUDE.md initial.

Le point commun de ces actions : aucune ne consiste à faire coder Claude, elles servent toutes à configurer Claude Code lui-même — c'est le cœur de métier des commandes slash.

Comment connaître les commandes disponibles ? La méthode la plus simple consiste à saisir un slash / dans la session. Un menu apparaît instantanément, listant toutes les commandes accessibles dans votre contexte ; commencez à saisir des lettres pour filtrer la liste en temps réel. La documentation officielle le résume ainsi :

Saisissez / pour afficher toutes les commandes à votre disposition, ou saisissez / suivi de lettres pour filtrer la liste.

💡 Résumé en une phrase : Les commandes slash forment le « bloc de touches de contrôle » de Claude Code — elles pilotent le programme lui-même (changement de modèle, nettoyage de contexte, lancement de processus) et non le codage de l'IA ; elles doivent se situer au début du message, et un simple / affiche l'ensemble des commandes disponibles.

---

02 Liste des commandes intégrées : À consulter selon votre étape de travail

Il existe des dizaines de commandes intégrées, tenter de les apprendre toutes par cœur serait une perte de temps. La documentation officielle de Claude Code les présente d'ailleurs selon le déroulement typique d'une session — le choix des commandes découle de votre étape de travail. Nous avons regroupé ici les commandes les plus fréquentes selon cette logique : trouvez la ligne correspondant à ce que vous souhaitez accomplir.

Précisons un point : parmi ces commandes, la grande majorité correspond à des « commandes intégrées » (dont le comportement est figé dans la CLI pour exécuter une tâche précise), tandis qu'une minorité est désignée sous le terme de Skill — il s'agit de Skills packagés, c'est-à-dire d'invites fournies à Claude pour qu'il orchestre ses outils (comme /code-review ou /debug). Quelques rares autres sont désignées sous le terme de Workflow — ce sont des flux de travail dynamiques faisant intervenir plusieurs sous-agents en parallèle (comme /batch ou /deep-research). L'expérience d'utilisation est identique (saisie de / suivie du nom de la commande), seule l'implémentation sous-jacente diffère (ce point technique a été abordé au chapitre 26 sur les Skills).

Premier groupe : Initialisation et configuration lors de l'arrivée sur un projet

Commande	Effet	Quand l'utiliser
/init	Génère un fichier CLAUDE.md d'initialisation pour le projet	Premier lancement au sein d'un dépôt (détails au chapitre 12)
/memory	Édite la mémoire de CLAUDE.md et gère la mémoire automatique	Pour affiner les instructions après un /init (détails au chapitre 25)
/mcp	Gère la connexion et l'autorisation des serveurs MCP	Pour se connecter à des services externes (détails au chapitre 22)
/agents	Gère la configuration des sous-agents (subagents)	Pour configurer des assistants spécialisés (détails au chapitre 23)
/permissions	Gère les règles de permission (autoriser / demander / refuser)	Pour fixer la fréquence de confirmation avant action (détails au chapitre 20)

Ce groupe correspond aux étapes classiques d'initialisation : d'abord /init pour que Claude lise le code et propose un brouillon de CLAUDE.md, puis /memory pour corriger les éventuelles erreurs d'interprétation. Cela vous évite de rédiger ces explications à partir de zéro — la première fois qu'on déroule ce flux, c'est une excellente surprise.

Deuxième groupe : Ajustement de l'état en cours de tâche

Commande	Effet	Quand l'utiliser
/model	Change de modèle et l'enregistre par défaut pour les sessions suivantes	Pour basculer sur un modèle plus puissant ou plus économique
/clear	Démarre une nouvelle conversation avec un contexte vide (la précédente reste disponible via /resume)	Pour changer totalement de sujet et nettoyer le plan de travail
/compact	Compresse la conversation sous forme de résumé pour libérer du contexte	Quand la discussion est trop longue et sature le contexte (détails au chapitre 19)
/context	Affiche l'occupation du contexte sous forme de grille colorée	Pour visualiser la répartition de l'usage du contexte
/plan	Bascule directement en mode Plan	Pour concevoir un plan d'action sans modifier le code avant de grands changements

/clear et /compact sont souvent confondus, c'est précisément le piège décrit en introduction. Pour les distinguer simplement : utilisez /clear pour démarrer un sujet sans rapport (effacer tout le plan de travail), et /compact pour poursuivre la même tâche quand la discussion s'éternise (condenser l'historique sous forme de points clés pour continuer à travailler). Le chapitre 19 a détaillé cette paire, retenez simplement « changer de tâche = clear, continuer la tâche = compact ».

Troisième groupe : Vérifications avant livraison

Commande	Effet
/diff	Ouvre un visualiseur de diff interactif pour inspecter les modifications non validées
/review	Effectue la revue d'une PR au sein de la session active
/security-review	Analyse spécifiquement les modifications de la branche actuelle à la recherche de faiblesses de sécurité
/code-review	Inspecte le diff pour trouver des bugs et des simplifications, supporte l'option --fix pour appliquer directement les corrections

Quatrième groupe : Commandes diverses indispensables

Commande	Effet
/help	Affiche l'aide et les commandes disponibles
/config	Ouvre l'interface de configuration (thème, modèle, style de sortie...)
/doctor	Analyse l'état de votre installation et configuration, pressez f pour corriger automatiquement
/resume	Restaure une ancienne conversation par ID ou par nom, ou ouvre un sélecteur
/skills	Liste tous les Skills actuellement disponibles
/rewind	Restaure la conversation et/ou le code à l'état d'un checkpoint (sujet du prochain chapitre)

Note : Toutes les commandes ne s'affichent pas pour tout le monde. La documentation officielle est explicite — « la disponibilité dépend de votre plateforme, de votre forfait et de votre environnement ». Par exemple, /desktop n'apparaît que sous macOS et Windows lorsque vous êtes connecté via un abonnement Claude, et /upgrade n'est visible que pour les forfaits Pro et Max. Le menu qui s'affiche lorsque vous saisissez / correspond aux commandes réellement disponibles pour votre configuration (machine et compte) — fiez-vous à ce menu plutôt qu'à des captures d'écran tierces.

Cette liste n'est pas exhaustive (le catalogue officiel contient des dizaines de lignes), mais elle couvre 90% des scénarios courants. Pour le reste, si vous cherchez une commande, saisissez un slash / suivi de quelques lettres pour filtrer, c'est bien plus rapide que de parcourir la documentation.

💡 Résumé en une phrase : N'apprenez pas les commandes par cœur, consultez-les selon votre étape de travail — initialisation (/init /memory /mcp /agents), en cours de tâche (/model /clear /compact /context), livraison (/diff /review /code-review) et diverses (/help /doctor /resume) ; pressez / pour afficher les commandes réelles de votre environnement.

---

03 Concevoir sa propre commande : Déposer un fichier markdown dans .claude/commands/

Une fois les commandes intégrées maîtrisées, vous tirerez le meilleur des commandes slash en concevant les vôtres.

Pourquoi concevoir des commandes personnalisées ? Pensez à vos tâches répétitives quotidiennes avec Claude — répéter les mêmes consignes de commit à chaque fois, copier-coller le même message d'introduction pour relire une PR, ou insister pour qu'il « explique simplement sans jargonner ». Dès que vous copiez une invite pour la cinquième fois, c'est le signal qu'il est temps d'en faire une commande.

Analogie : Programmer une touche « macro » sur une télécommande. Les télécommandes universelles haut de gamme proposent une touche programmable — vous y enregistrez une suite d'actions fréquentes (allumer la TV → basculer sur HDMI 2 → régler le volume à 15), et un simple clic exécute tout l'enchaînement sans avoir à presser les touches une par une. Les commandes slash personnalisées sont cette touche macro : vous y « enregistrez » une invite répétitive, et appeler son nom renvoie automatiquement tout le texte.

Comment faire ? C'est d'une simplicité surprenante — déposez un fichier markdown dans le répertoire .claude/commands/, son nom déterminera celui de la commande. La documentation officielle l'explique clairement :

Un fichier dans .claude/commands/deploy.md... créera la commande /deploy.

Autrement dit, si vous créez un fichier .claude/commands/commit.md contenant vos règles de commit, il se transforme automatiquement en commande /commit. Le nom du fichier (sans l'extension .md) est le nom de la commande, sans aucune configuration supplémentaire.

Prenons un exemple basique. Créez un fichier .claude/commands/review.md et écrivez-y :

请审查我当前未提交的改动，重点看三件事：
1. 有没有缺失的错误处理
2. 有没有写死的配置值（端口、密钥、路径）
3. 有没有该补而没补的测试

用中文逐条列出，每条标明在哪个文件。

Une fois enregistré, saisir /review dans la session enverra l'intégralité de cette invite à Claude — c'est comme si vous aviez saisi tout ce texte mot pour mot, mais en seulement sept caractères.

Voici la distinction cruciale concernant l'emplacement d'enregistrement, similaire à ce qui a été vu pour les MCP et les Skills :

Emplacement	Portée de la commande	Suivi par git ?
Niveau projet .claude/commands/	Uniquement le projet actuel	Oui, disponible pour toute l'équipe
Niveau utilisateur ~/.claude/commands/	Tous vos projets	Non, strictement personnel

La logique est identique à celle des Skills : si la commande est propre au projet et doit être partagée avec vos collaborateurs (comme le processus de déploiement du dépôt), enregistrez-la au niveau projet pour qu'elle soit suivie par git ; s'il s'agit d'une routine personnelle réutilisable sur tous vos projets (comme vos habitudes d'explication de code), placez-la au niveau utilisateur dans ~/.claude/commands/. Quelques petites commandes globales rangées dans ~/.claude/commands/ seront ainsi disponibles partout, ce qui est bien plus pratique que de les reconfigurer à chaque fois.

💡 Résumé en une phrase : Une commande personnalisée enregistre une invite répétitive sous un seul mot — déposez un fichier markdown dans .claude/commands/, son nom devient la commande slash, sans configuration ; au niveau projet pour l'équipe, ou dans ~/.claude/commands/ pour votre usage personnel global.

---

04 Enrichir sa commande : Frontmatter et transmission de paramètres avec $ARGUMENTS

La commande /review précédente est opérationnelle, mais elle souffre d'une limite : son contenu est figé et n'accepte pas de paramètres. Vous ne pouvez pas lui demander de « relire seulement le fichier src/auth.ts » ; elle inspecte systématiquement l'ensemble des modifications. Pour rendre vos commandes dynamiques, vous devez ajouter deux éléments : le frontmatter et des placeholders de paramètres.

Récupérer les paramètres saisis avec $ARGUMENTS

Commençons par la transmission de paramètres. Claude Code propose le placeholder $ARGUMENTS — tout le texte saisi après le nom de la commande viendra remplacer ce placeholder. L'exemple de la documentation officielle est très parlant :

Fix GitHub issue $ARGUMENTS following our coding standards.

1. Read the issue description
2. Understand the requirements
3. Implement the fix

La documentation officielle en détaille l'effet ainsi :

Lorsque vous exécutez /fix-issue 123, Claude reçoit « Fix GitHub issue 123 following our coding standards... »

Vous voyez ? Saisir /fix-issue 123 injecte la valeur 123 à l'emplacement de $ARGUMENTS. Une commande générique avec des arguments variables — c'est là que réside toute la puissance des commandes personnalisées.

Un mécanisme de sécurité est d'ailleurs prévu : si vous passez des arguments mais que la commande ne comporte pas de placeholder $ARGUMENTS, Claude Code ajoute automatiquement la ligne ARGUMENTS: <votre saisie> à la fin de la requête « pour s'assurer que Claude reçoive bien votre saisie ». Ainsi, vos paramètres ne sont jamais perdus.

Passer plusieurs paramètres ? Utilisez $0 et $1 selon leur position

Comment faire si votre commande requiert plusieurs paramètres distincts ? Par exemple : « migrer le composant SearchBar de React vers Vue », ce qui représente trois valeurs différentes. Claude Code permet de cibler les arguments par leur position avec la syntaxe $ARGUMENTS[N] ou simplement $N (en commençant à 0) :

Migrate the $0 component from $1 to $2.
Preserve all existing behavior and tests.

Si vous lancez /migrate-component SearchBar React Vue, $0 prendra la valeur SearchBar, $1 prendra React et $2 prendra Vue. Attention à un détail important : ces variables positionnelles suivent le format de découpage des shells — les valeurs contenant des espaces doivent être entourées de guillemets pour constituer un paramètre unique. Par exemple, avec /my-cmd "hello world" second, $0 contiendra hello world ; sans les guillemets, il serait découpé par l'espace. (Le placeholder global $ARGUMENTS n'est pas concerné, il récupère toujours l'intégralité de la chaîne saisie.)

Configurer le comportement de la commande avec le frontmatter

La transmission de paramètres ne fait pas tout. Certaines commandes comme /deploy ou /commit ont des effets de bord importants — vous ne voulez pas que Claude prenne l'initiative de déployer votre code dès qu'il estime le travail terminé. C'est ici qu'intervient la configuration du frontmatter.

Le frontmatter est un bloc de configuration au format YAML délimité par deux lignes --- au tout début du fichier (nous avons rencontré ce concept au chapitre 26 sur SKILL.md ; les fichiers de commande supportent exactement le même format). Voici les deux clés les plus utiles :

---
description: 把当前改动暂存并提交
disable-model-invocation: true
---

把当前改动提交，commit 信息用中文、前缀按 feat/fix/docs：

1. 先跑测试套件
2. git add 改动
3. 用规范的中文信息提交

• description : explique en une phrase le rôle de la commande. Claude s'appuie dessus pour déterminer s'il doit appeler cette commande de lui-même. Il est fortement conseillé de la renseigner.
• disable-model-invocation: true : si configuré sur true, la commande ne peut être appelée que manuellement par vous ; Claude ne l'activera jamais de sa propre initiative. C'est une sécurité indispensable pour les tâches sensibles dont vous devez garder le contrôle exclusif (déploiements, commits, envois de messages).

C'est une noion fondamentale à intégrer pour éviter toute surprise liée à une initiative de l'IA : vos commandes personnalisées sont par défaut partagées entre vous et Claude. Saisir /commit est un appel manuel, mais si vous avez renseigné une description, Claude est susceptible de l'exécuter de lui-même s'il estime la situation appropriée. C'est l'illustration concrète de l'unification des commandes slash et des Skills (voir chapitre 26) — si vous craignez qu'il n'agisse à tort et à travers, verrouillez la commande en mode strictement manuel avec disable-model-invocation: true. C'est la première ligne à ajouter pour les opérations comme /commit, sous peine de le voir tenter de valider vos modifications de lui-même.

Effet souhaité	Configuration frontmatter
La commande a des effets de bord et doit être strictement manuelle	disable-model-invocation: true
Indiquer à Claude quand appeler cette commande	Renseigner la description
Restreindre les outils utilisables sans confirmation lors de son exécution	allowed-tools: Bash(git add *) Bash(git commit *)

💡 Résumé en une phrase : $ARGUMENTS capture l'intégralité de la saisie après la commande, et $0 / $1 ciblent les valeurs par position (les expressions contenant des espaces devant être entourées de guillemets) ; dans le frontmatter, description indique à Claude quand l'appeler, tandis que disable-model-invocation: true la verrouille en mode strictement manuel — à utiliser impérativement sur les actions sensibles.

---

05 Technique avancée : Injecter des données dynamiques dans la commande

À ce stade, vos commandes sont paramétrables, mais il existe une technique encore plus puissante : faire en sorte que la commande charge d'elle-même des données dynamiques du projet avant d'être transmise à Claude. Cette fonctionnalité se nomme l'injection de contexte dynamique (dynamic context injection) et constitue l'un des aspects les plus sous-estimés des commandes personnalisées.

Voyons son intérêt. La commande /review précédente contient la consigne « relis mes modifications non validées » — mais lorsque Claude reçoit ce message, il doit exécuter une commande git diff de lui-même pour en prendre connaissance. Est-il possible de lui fournir directement le résultat du diff avant qu'il ne lise la consigne ? Absolument.

La syntaxe consiste à insérer !`commande` — un point d'exclamation suivi d'une commande shell entre backticks. La documentation officielle l'explique clairement :

La syntaxe !`<command>` exécute une commande shell avant d'envoyer la requête à Claude. La sortie de la commande remplace le placeholder, de sorte que Claude reçoive les données réelles et non la commande elle-même.

Exemple pratique d'évolution de /review. Écrivez ceci dans .claude/commands/review.md :

## 当前改动

!`git diff HEAD`

## 说明

审查上面这段改动，重点看缺失的错误处理、写死的配置值、该补的测试。用中文逐条列出。

Que se passe-t-il avec la ligne !`git diff HEAD` ? La séquence d'exécution officielle se déroule ainsi :

1. Claude Code commence par exécuter la commande git diff HEAD ;
2. Le résultat de cette commande shell vient remplacer la ligne du placeholder ;
3. Claude reçoit alors une invite complète contenant directement votre diff réel à cet instant.

En d'autres termes, Claude ne reçoit pas la consigne « va lire le diff », mais directement « voici les modifications effectuées : ... [données réelles], fais-en la revue ». Il s'agit d'un prétraitement transparent : Claude n'exécute pas la commande shell, il ne voit que le résultat injecté. L'intégration de cette brique à la commande /review améliore nettement sa réactivité, l'IA se mettant au travail sans étape intermédiaire d'analyse.

Quelques détails à connaître pour éviter les pièges :

• Le point d'exclamation doit se situer en début de ligne ou après un espace pour être actif. S'il est collé à un caractère (comme KEY=!cmd), il sera interprété comme du texte classique et la commande shell ne s'exécutera pas.
• Pour les commandes complexes sur plusieurs lignes, n'utilisez pas la syntaxe en ligne, mais un bloc de code délimité commençant par ```! (avec une commande par ligne).
• Cette fonctionnalité peut être désactivée : le paramètre disableSkillShellExecution configuré sur true bloque toute exécution et remplace le placeholder par la mention [shell command execution disabled by policy]. C'est une sécurité importante pour les projets partagés — elle évite qu'un collaborateur malveillant n'injecte des scripts d'exécutions shell arbitraires dans les commandes du dépôt.

Astuce supplémentaire pour l'autocomplétion : ajoutez la clé argument-hint (par exemple : argument-hint: [issue-number]) dans le frontmatter. Lors de la saisie du nom de la commande, l'autocomplétion affichera une indication sur l'argument attendu. C'est précieux pour s'y reprendre lorsque les commandes se multiplient.

💡 Résumé en une phrase : La syntaxe !`commande` permet à la commande slash d'injecter des données dynamiques (comme un git diff) avant sa transmission à Claude, de sorte que l'IA traite directement les informations ; le point d'exclamation doit se placer en début de ligne, les blocs multi-lignes s'écrivent avec ```! et l'exécution peut être verrouillée globalement par sécurité via disableSkillShellExecution.

---

06 Espaces de noms : Pourquoi les commandes de plugins n'entrent jamais en conflit

À force d'accumuler vos propres commandes et d'installer des plugins tiers (qui en apportent également), une question pratique se pose : qu'en est-il des conflits de noms ? Si vous créez une commande /review et qu'un plugin installé en propose une identique, laquelle sera appelée ?

La réponse dépend de l'origine de la commande.

Entre vos propres commandes : Résolution par priorité

Si un fichier de commande dans .claude/commands/ et un Skill dans .claude/skills/ portent le même nom, la règle officielle s'applique :

如果 skill 和命令共享相同的名称，skill 优先。

En d'autres termes, si vous possédez un fichier .claude/commands/deploy.md et un dossier de Skill .claude/skills/deploy/SKILL.md, appeler /deploy exécutera le Skill. Mémorisez cette règle simple de priorité du Skill ; en pratique, vous éviterez de toute façon de créer des doublons.

Commandes issues de plugins : Ségrégation par espace de noms

Les plugins gèrent ce point de manière plus robuste — ils n'utilisent pas le même espace de nommage global. La documentation officielle l'explique ainsi :

插件 skills 使用 plugin-name:skill-name 命名空间，因此它们不能与其他级别冲突。

Analogie : Différencier des homonymes dans vos contacts. Si vous avez deux contacts nommés « Jean Dupont », vous ajouterez probablement une mention comme « Jean Dupont (Société A) » et « Jean Dupont (Société B) ». L'ajout d'un préfixe évite toute confusion. C'est exactement le rôle de l'espace de noms : la commande review du plugin my-plugin s'appelle chez vous /my-plugin:review, le nom du plugin faisant office de préfixe. Même si vous possédez votre propre commande /review, les deux coexistent sans aucune ambiguïté.

C'est pourquoi le chapitre 24 sur les plugins expliquait que « les Skills de plugins n'entrent jamais en conflit avec les vôtres » — grâce à cette nomenclature nom-du-plugin:nom-de-la-commande. Si plusieurs plugins importent une commande review, elles s'appelleront respectivement /plugin-a:review et /plugin-b:review.

Vous pouvez également rencontrer des commandes comportant un double underscore : les invites exposées par les serveurs MCP. Elles adoptent le format /mcp__<serveur>__<invite> et sont détectées dynamiquement. Ne soyez pas surpris devant une commande /mcp__github__xxx — elle provient d'un serveur MCP connecté (voir chapitre 22).

💡 Résumé en une phrase : En cas d'homonymie interne, le Skill l'emporte sur la commande ; les plugins recourent à la nomenclature nom-du-plugin:nom-de-la-commande pour éviter les conflits ; et les serveurs MCP exposent des commandes au format /mcp__<serveur>__<invite>. Identifier les préfixes évite toute confusion.

---

07 Commandes slash et Skills : Clarification en une phrase

Vous vous demandez peut-être : les commandes slash et les Skills se ressemblent beaucoup. Quelle est la différence entre un script rédigé dans .claude/commands/ et un fichier SKILL.md rangé dans .claude/skills/ ?

C'est une excellente question, qui soulève souvent des interrogations. Levons le voile :

Les commandes slash personnalisées ont été intégrées par l'éditeur au sein de l'architecture des Skills. Vos fichiers dans .claude/commands/ restent pleinement fonctionnels, mais le Skill constitue une version évoluée — il supporte des fichiers annexes, peut être déclenché automatiquement par Claude, et son contenu descriptif est chargé de manière optimisée (chargement dynamique à l'appel au lieu d'une précharge globale).

La documentation officielle le résume sans détour :

自定义命令已合并到 skills 中。.claude/commands/deploy.md 中的文件和 .claude/skills/deploy/SKILL.md 中的 skill 都会创建 /deploy 并以相同的方式工作。

Ces deux éléments ne sont donc pas opposés, mais représentent deux syntaxes pour une même fonctionnalité. Sous un autre angle : la « commande slash » est une méthode d'appel (vous saisissez / pour la déclencher), tandis que le Skill est l'« entité » exécutée. Le tableau du chapitre 26 a détaillé le rôle des Skills, des commandes slash et des sous-agents. Voici un comparatif pour choisir la bonne approche selon vos besoins :

Votre besoin	Commande classique (.claude/commands/xx.md)	Skill (.claude/skills/xx/SKILL.md)
Une simple invite, appelée uniquement manuellement	✅ Suffisant, le plus simple	Possible, mais disproportionné
Associer des modèles, scripts ou exemples de fichiers	❌ Impossible	✅ Oui, c'est un dossier pouvant contenir des fichiers annexes
Permettre à Claude d'appeler l'action de lui-même si besoin	Possible si une description est fournie, mais le Skill est optimisé pour cela	✅ Cas d'usage cible
Intégrer une documentation volumineuse sans saturer le contexte	❌ Impossible d'y joindre des fichiers de référence	✅ Supporte un sous-dossier de fichiers, la documentation est chargée dynamiquement à l'appel

Règle empirique : s'il s'agit d'une invite simple à appeler manuellement (comme /review), un fichier markdown classique dans .claude/commands/ est la solution la plus simple, ne cherchez pas plus loin ; si vous devez y adosser des modèles de fichiers, intégrer de la documentation sans saturer le contexte ou laisser Claude décider de son exécution, il est temps de concevoir un Skill (sa rédaction est détaillée aux chapitres 26 et 27, et vous pouvez automatiser sa création avec le script skill-creator du chapitre 28).

En clair, les commandes slash personnalisées étudiées ici constituent la porte d'entrée la plus légère vers l'écosystème des Skills. Commencez par automatiser vos invites de cette manière. Si vos besoins évoluent, vous migrerez naturellement vers un Skill — la documentation officielle précisant que « vos fichiers existants continueront de fonctionner », le répertoire .claude/commands/ restant une syntaxe officiellement supportée.

💡 Résumé en une phrase : Les commandes slash personnalisées ont été fusionnées dans l'architecture des Skills — les fichiers .claude/commands/ en sont la déclinaison la plus légère (une invite simple appelée manuellement). La transition vers un Skill complet s'impose pour joindre des fichiers, automatiser l'appel ou optimiser le chargement ; les deux syntaxes créent des commandes utilisables de manière identique.

---

08 Mise en pratique : Concevoir une commande /explain paramétrable en 5 minutes

La pratique est essentielle. Nous allons concevoir ensemble une commande slash fonctionnelle et paramétrable — /explain, conçue pour vulgariser du code ou une erreur. L'exercice ne nécessite aucun environnement complexe et peut être réalisé dans un dossier vide.

Étape 1 : Créer le répertoire des commandes (Mac / Linux)

Dans un projet de votre choix (ou un dossier vide créé pour l'occasion), créez le répertoire .claude/commands/ :

mkdir -p .claude/commands

Pour les utilisateurs de Windows : créez manuellement l'arborescence .claude\commands\ à la racine du projet.

Résultat attendu : Le dossier vide .claude/commands/ est présent à la racine.

Étape 2 : Rédiger le fichier de la commande

Avec votre éditeur favori, enregistrez le contenu suivant sous le chemin .claude/commands/explain.md :

---
description: 用大白话解释一段代码或一个报错。当用户想搞懂某段代码或某个报错时使用。
---

请用初学者能懂的大白话，解释下面这个东西：

$ARGUMENTS

要求：
1. 先一句话说它整体在干啥
2. 再逐行 / 逐段拆开说清楚
3. 如果是报错，指出最可能的原因和怎么改
4. 少堆术语，能用生活类比就用

Notez deux détails importants : le bloc --- initial définit le frontmatter, la clé description indiquant à Claude le rôle de la commande ; le placeholder $ARGUMENTS dans le corps du texte servira à injecter le code ou l'erreur transmis lors de l'appel.

Résultat attendu : Le fichier explain.md est présent dans le dossier .claude/commands/.

Étape 3 : Lancer Claude et vérifier la détection de la commande

claude

Une fois la session ouverte, saisissez uniquement un slash / (sans appuyer sur Entrée) et observez le menu déroulant :

Résultat attendu : La commande /explain s'affiche dans la liste, accompagnée de la description rédigée. Sa présence confirme qu'elle a été correctement chargée. Si elle n'apparaît pas, vérifiez l'emplacement du fichier — il doit se situer précisément sous .claude/commands/explain.md.

Étape 4 : Appeler la commande avec un paramètre

Testons-la en conditions réelles — saisissez le nom de la commande suivi de l'expression à analyser (qui viendra remplacer le placeholder $ARGUMENTS) :

/explain print(sum([1,2,3]) / len([1,2,3]))

Résultat attendu : Claude reçoit l'invite complète où $ARGUMENTS a été substitué par print(sum([1,2,3]) / len([1,2,3])). Il suit la structure demandée — une phrase globale (calcul de la moyenne de trois nombres), l'analyse pas à pas, des explications simples et des analogies. Saisir le nom de la commande et le code a appliqué l'ensemble de vos consignes de vulgarisation, illustrant la force du placeholder $ARGUMENTS.

Étape 5 : Effectuer un nouvel appel avec un paramètre différent

Appelons la même commande pour analyser un message d'erreur :

/explain ZeroDivisionError: division by zero

Résultat attendu : La commande /explain s'exécute à nouveau, mais avec le message d'erreur injecté dans $ARGUMENTS. Claude se concentre sur la consigne 3 pour expliquer la cause probable et sa résolution (division par zéro). Un modèle unique traitant des variables différentes — c'est le principal atout des commandes par rapport à la saisie manuelle.

Ces cinq étapes franchies, vous avez validé le socle de la conception des commandes slash : « le nom de fichier détermine la commande », « configuration de la description dans le frontmatter » et « passage d'arguments avec $ARGUMENTS ». Concevoir d'autres commandes suivra exactement le même principe, en ajustant simplement le nom du fichier, le corps de l'invite et les champs du frontmatter.

💡 Résumé en une phrase : Créer une commande se fait en trois points — un fichier markdown dans .claude/commands/ (le nom de fichier devenant le nom de commande), une description dans le frontmatter et un placeholder $ARGUMENTS ; saisissez / pour vérifier sa détection, puis testez-la avec des arguments variés pour vous l'approprier.

---

09 Résumé

Ce chapitre a exploré le fonctionnement des commandes slash — le véritable panneau de contrôle de Claude Code, regroupant des dizaines d'interrupteurs intégrés et vos propres flux personnalisés derrière un simple /.

Récapitulation des notions clés :

Concept à maîtriser	Réponse	Point clé
Qu'est-ce qu'une commande slash ?	Des consignes de contrôle pour Claude Code	Pilote le programme lui-même, doit débuter le message
Comment retenir les commandes intégrées ?	Les classer par étapes de travail	Configuration, exécution, livraison, diverses ; pressez / pour les lister
Comment concevoir ses commandes ?	Un fichier markdown dans .claude/commands/	Le nom de fichier définit la commande ; partage projet ou portée globale
Comment transmettre des paramètres ?	$ARGUMENTS / $0, $1	La saisie après la commande is injectée ; guillemets requis pour les expressions complexes
Comment injecter des données dynamiques ?	Syntaxe !`commande` pour injection	Exécute une commande shell et injecte le résultat (ex: git diff) dans la requête
Comment contrôler son exécution ?	Frontmatter	description pour l'indexation, disable-model-invocation pour le mode manuel
Existe-t-il des risques de conflits de noms ?	Des règles d'isolation par origine	Skill prioritaire, plugin par espace de noms, préfixe /mcp__ pour MCP
Quel rapport avec les Skills ?	Les deux concepts ont été unifiés	La commande slash est l'entrée la plus simple, le Skill s'impose pour les besoins évolués

Vous devriez désormais être en mesure de : comprendre le menu déroulant en saisissant /, identifier les commandes intégrées selon votre étape de travail ; automatiser vos invites fréquentes sous forme de fichier dans .claude/commands/ en exploitant $ARGUMENTS pour passer des paramètres et le frontmatter pour en contrôler le comportement ; distinguer la priorité en cas de collision de noms et le fonctionnement des espaces de noms pour les plugins ; et appréhender le fait que les commandes slash et les Skills partagent le même moteur — la commande étant la porte d'entrée la plus simple, pouvant évoluer vers un Skill si nécessaire.

Repenser au rituel fastidieux de redémarrage des premières semaines montre bien les économies de temps réalisées grâce au menu /. À l'avenir, chaque fois que vous voudrez interagir avec Claude Code, votre premier réflexe sera de taper un slash pour chercher un interrupteur adapté ou, à défaut, de prendre quelques minutes pour concevoir le vôtre. Cette habitude vous fera gagner un temps précieux.

---

Le prochain chapitre 37 « Checkpoints (Points de contrôle) » détaillera le rôle de /rewind, brièvement évoqué ici. Si Claude s'égare lors de modifications de code, comment revenir en arrière ? Vous ne pouvez pas vous contenter d'un git reset manuel systématique ou de rester passif. Nous verrons comment exploiter le système de checkpoints intégré à Claude Code pour sauvegarder et restaurer l'état du code et de la session comme dans un jeu vidéo. Pouvoir poser des points de sauvegarde automatiques à chaque étape clé vous donnera une bien plus grande liberté d'expérimentation.

---

Lectures recommandées

• Comment choisir une fonctionnalité : CLAUDE.md vs Skill vs Hook vs MCP vs Subagent
• Sécurité et limites des risques : Faut-il faire confiance à l'IA avec votre code ?
• Structure du projet : Qu'est-ce que Claude Code stocke dans votre projet ?