Recherchez « commandes Claude Code » et vous tomberez toujours sur la même liste : /clear, /compact, /model, et quelques dizaines d'autres, copiées directement de la documentation. C'est utile, mais cela répond à la mauvaise question. Ces commandes contrôlent l'outil. Elles ne changent en rien le comportement de l'agent dès que vous lui demandez de coder quelque chose. Cet article présente les deux types de commandes, les commandes intégrées qui pilotent l'outil et les commandes personnalisées qui guident le travail, et explique pourquoi c'est avec ces dernières que vous obtiendrez le plus de résultats.
Que sont les commandes Claude Code ?
Les commandes Claude Code sont des raccourcis clavier qui commencent par un slash. Il en existe deux types, et leur différence est plus importante que n'importe quelle commande individuelle. Les Commandes slash intégrées sont livrées avec Claude Code et contrôlent la session elle-même : vider le contexte, changer de modèle, modifier la mémoire. Les Commandes personnalisées sont celles que vous écrivez vous-même, sous la forme d'un petit fichier markdown qui devient un flux de travail réutilisable à appeler par son nom. Les commandes intégrées contrôlent l'outil. Les commandes personnalisées contrôlent le travail.
Les commandes intégrées de Claude Code qui valent le détour
La plupart des gens installent Claude Code et n'utilisent qu'environ dix pour cent de ses capacités. Voici les commandes intégrées qui valent vraiment la peine, regroupées par tâche. Claude Code évolue vite, considérez donc ce guide comme une carte et lancez /help pour obtenir la syntaxe exacte de votre version.
/clear efface la conversation, /compact résume et continue, /context montre ce qui remplit la fenêtre/memory parcourt ce que Claude a appris ; CLAUDE.md contient les règles de votre projet, chargées à chaque session/model change de modèle selon la tâche, /config ajuste les paramètres, /output-style modifie la façon dont Claude s'exprime/hooks affiche les scripts qui s'exécutent automatiquement lors des modifications et autres événements. Voir le guide des hooks/help pour obtenir la liste complète et à jour.Une dernière astuce qui n'est pas une commande slash mais qui a toute sa place ici : appuyez sur Shift+Tab jusqu'à ce que la saisie affiche plan. Claude analyse et propose l'intégralité des modifications sans toucher aux fichiers, et vous validez d'abord. Deux minutes de réflexion qui évitent des heures de développement inutile. C'est la meilleure habitude à prendre pour débuter.
Comment écrire votre propre commande personnalisée
C'est la partie que les articles de blog oublient de mentionner, et c'est pourtant tout l'intérêt. Déposez un fichier markdown dans .claude/skills/<name>/SKILL.md décrivant les étapes souhaitées, et il devient /<name>. Claude peut aussi l'appeler de lui-même quand la situation s'y prête. Vos commandes personnelles se trouvent dans ~/.claude/skills/. Ajoutez celles du projet dans git pour que toute votre équipe partage le même flux de travail, sans copier-coller ni explications répétitives. Une commande n'est rien d'autre qu'une bonne habitude, écrite une fois pour toutes là où l'agent la lira vraiment.
Les commandes qui contrôlent l'agent, pas l'outil
Voici le fond du problème. Les commandes intégrées ne sont que le strict minimum. Si votre agent continue de trop en faire, de deviner vos intentions ou de vous dire « ça devrait marcher » pour du code qu'il n'a jamais exécuté, c'est parce qu'aucune commande intégrée n'influe sur son comportement. Le comportement est défini par les commandes personnalisées que vous lui donnez, ou par celles que vous n'avez jamais pris le temps d'écrire.
C'est exactement ce qu'est kitstarter : un ensemble de commandes personnalisées qui forcent l'agent à se comporter comme un développeur méticuleux plutôt que pressé. Chacune d'elles est un véritable flux de travail, pas un simple prompt à copier-coller. Voici ce que propose cet ensemble.
| Commande | Ce qu'elle fait | Quand l'utiliser |
|---|---|---|
/start | Vous pose des questions de clarification jusqu'à ce que l'objectif soit parfaitement clair, puis rédige un plan court ainsi qu'un CLAUDE.md et attend votre feu vert. | Tout au début, avant d'écrire le moindre fichier. Demander d'abord, coder ensuite. |
/step | Réalise le plan étape par étape, avec un point de sauvegarde dès qu'une étape fonctionne réellement. | Une fois le plan validé, pour avancer par étapes courtes, sûres et réversibles. |
/check | Prouve qu'une modification fonctionne en l'exécutant ou en l'ouvrant réellement, puis indique ce qu'il a observé. | Chaque fois que vous vous apprêtez à accepter un « ça devrait marcher » comme réponse. |
/fix | Trouve la cause réelle du problème avant de modifier quoi que ce soit, au lieu d'accumuler les correctifs temporaires. | Quand quelque chose ne fonctionne pas et qu'un deuxième correctif n'a rien résolu non plus. |
/review | Analyse le diff réel avec un œil neuf par rapport à l'objectif initial, et signale ce qui est risqué, incomplet ou hors sujet. | Avant de commiter, et avant de montrer votre travail à qui que ce soit. |
/secrets | Détecte les fuites de clés API, les fichiers .env exposés et les secrets dans le code frontend avant que tout ne devienne public. | Avant le premier déploiement, et avant chacun des suivants. |
/ship | Met le projet en ligne : déploie, configure les variables d'environnement de production et fournit une URL fonctionnelle. | Une fois le travail validé, pour obtenir une URL à partager. |
/recover | Vous ramène à un état fonctionnel quand tout casse ou que git devient effrayant, sans aggraver la situation. | Au moment précis où vous êtes tenté de supprimer le dossier pour tout recommencer à zéro. |
/polish | Corrige à la racine les détails qui donnent à un écran un aspect généré par IA, sans se contenter de retouches superficielles. | Quand ça fonctionne, mais que le rendu a encore l'air généré. |
Remarquez leur point commun. Chacune d'elles impose une règle sur quand s'arrêter et ce qu'il ne faut pas faire, ce sur quoi l'agent par défaut n'a aucun avis. C'est le même principe derrière les cinq archétypes de l'ingénierie IA : la compétence ne consiste pas à produire plus de code, mais à contraindre l'agent à respecter la fonction de valeur requise par la situation.
Les commandes intégrées contrôlent l'outil. Les commandes personnalisées contrôlent l'agent.
Apprenez les commandes intégrées une bonne fois pour toutes. Elles vous permettent de piloter Claude Code plus rapidement, et /clear, /compact ainsi que le mode plan vont à eux seuls changer votre quotidien. Mais la liste des commandes intégrées n'est pas ce qui sépare ceux qui obtiennent un travail propre et prêt à être déployé de ceux qui se retrouvent avec du code bâclé mais produit avec assurance. Cette différence tient au comportement, et le comportement dépend d'un ensemble de commandes personnalisées. Vous pouvez les écrire vous-même, une bonne habitude après l'autre, ou installer un ensemble qui les intègre déjà. Dans tous les cas, les commandes qui comptent vraiment sont celles qui forcent votre agent à demander avant de coder et à s'arrêter quand c'est fini.
Questions fréquentes
Quelles sont les commandes intégrées de Claude Code ? Des raccourcis clavier commençant par un slash qui contrôlent la session : le contexte (/clear, /compact, /context), la mémoire (/memory), les modèles et la configuration (/model, /config, /output-style), et l'automatisation (/hooks). Lancez /help pour obtenir la liste exacte de votre version.
Comment créer une commande slash personnalisée ? Créez un fichier dans .claude/skills/<name>/SKILL.md contenant les étapes souhaitées. Il devient /<name>. Les commandes personnelles vont dans ~/.claude/skills/ ; commitez celles du projet pour que votre équipe les partage.
Quelle est la différence entre une commande et un skill ? Deux aspects d'une même chose. Le skill est le fichier SKILL.md contenant les instructions. La commande est le moyen de le déclencher, en tapant /name.
Par quelles commandes vaut-il mieux commencer ? /clear et /compact pour garder un contexte propre, le mode plan avant les modifications importantes, puis des commandes de comportement personnalisées : une qui demande avant de coder, une qui prouve qu'une modification fonctionne, et une qui compare le diff à l'objectif initial.
Installez les commandes qui le font filer droit
kitstarter est cet ensemble : /start, /step, /check, /fix, /review, /ship et bien d'autres, pour forcer Claude Code, Codex et Antigravity à demander avant de coder, à rester sobres et à éviter le rendu généré par IA.