L'accélération la plus rapide que j'ai obtenue dans Claude Code cette année n'était pas une mise à niveau du modèle. C'était apprendre à taper une seule barre oblique suivie de quatre lettres.
J'utilisais Claude Code quotidiennement depuis plus d'un an avant d'admettre quelque chose d'embarrassant : je laissais la majeure partie de son potentiel inexploité. J'ouvrais une session, tapais un paragraphe entier d'instructions, regardais le travail se faire, me heurtais à un mur, et commençais une session toute neuve en fermant complètement le terminal. À. Chaque. Fois. Je payais pour du contexte que je jetais sans cesse, ré-expliquais le même projet depuis zéro, et gaspillais du quota sur des conversations qui avaient tellement dévié du sujet que Claude devinait essentiellement.
Puis j'ai commencé à vraiment utiliser les commandes slash. Pas de la façon dont la documentation les liste — alphabétiquement, à plat, comme un glossaire que personne ne lit. Je parle des quatre ou cinq vers lesquelles je tends maintenant si réflexivement que mes doigts bougent avant que mon cerveau ait fini la pensée. Celles qui décident si une session de construction de deux heures ressemble à du flow ou à un combat contre l'outil.
Ceci est la version pratique de cela. Les commandes slash de Claude Code que j'utilise véritablement chaque jour, regroupées par le problème réel que chacune résout — du contexte devenu obsolète, un build qui a mal tourné, un plan que j'avais besoin de voir avant qu'une seule ligne de code soit écrite. Pour chacune : ce qu'elle fait, la façon exacte dont je l'invoque, et le moment précis où j'y recours dans le travail réel.
Quelques-uns des "commandes" qui circulent dans les tutoriels et vidéos se sont avérés être du jargon communautaire ou des fonctionnalités qui fonctionnent un peu différemment de ce que les gens décrivent. Je les signalerai honnêtement au fur et à mesure, car connaître l'image exacte est tout l'intérêt — une commande que vous pensez exister mais qui n'existe pas est pire que pas de commande du tout.
Commençons là où toute bonne session commence et finit : avec le contexte.
Que sont les commandes slash dans Claude Code ?
Les commandes slash sont des raccourcis que vous déclenchez en tapant / dans le prompt de Claude Code, ce qui ouvre un menu d'auto-complétion d'actions que vous pouvez exécuter sans écrire de longues instructions. Elles contrôlent la session elle-même — effacer le contexte, rembobiner le code, reprendre d'anciennes conversations, configurer l'interface — plutôt que d'être des prompts que vous envoyez au modèle.
Cette distinction est plus importante qu'elle n'en a l'air. Un message normal demande à Claude de faire quelque chose dans votre base de code. Une commande slash demande à Claude Code de faire quelque chose à la session dans laquelle vous travaillez. L'un édite des fichiers ; l'autre gère l'environnement dans lequel ces éditions se produisent.
L'auto-complétion apparaît dès que vous tapez / — dans le terminal et dans l'application de bureau — vous n'avez donc pas besoin de mémoriser les orthographes exactes. Tapez /re et vous verrez /rewind et /resume apparaître ensemble. C'est aussi comme ça que je découvre des commandes que j'avais oubliées, ce qui est la moitié de la raison pour laquelle je me donne la peine de taper la barre oblique au lieu de chercher un raccourci clavier dont je me souviens à moitié.
Voici ce que la plupart des aide-mémoire font mal : ils traitent les quarante-et-quelques commandes comme également dignes d'être apprises. Elles ne le sont pas. J'en utilise peut-être six quotidiennement et le reste presque jamais. Je ne vais donc pas tout lister. Je vais vous guider à travers la poignée qui mérite sa place dans la mémoire musculaire — et vous dire lesquelles internet a fausses.
La première est la commande que j'aurais dû apprendre le premier jour.
Gestion du contexte : /clear, /resume et /rewind
La plupart de la frustration que je ressentais autrefois dans Claude Code remontait à une seule cause racine : j'étais mauvais dans la gestion du contexte. Soit j'en avais trop (une conversation gonflée où Claude trébuchait sans cesse sur d'anciennes instructions non pertinentes) soit j'avais perdu le contexte que je voulais réellement (une session que j'avais fermée trop tôt et que je ne pouvais pas récupérer). Trois commandes ont résolu presque tout.
/clear — la réinitialisation que j'ai évitée bien trop longtemps
/clear efface l'historique de conversation actuel de la fenêtre de contexte et vous laisse repartir à neuf — sans supprimer votre mémoire de projet.
Cette seconde moitié est la partie que j'ai mal comprise pendant des mois, et il vaut la peine d'être précis car cela change la façon dont vous devriez utiliser la commande de manière agressive. Quand vous exécutez /clear, cela supprime tout de la fenêtre de contexte active : les échanges, les fichiers que Claude a lus, les impasses. Mais cela ne touche pas votre fichier CLAUDE.md. CLAUDE.md est rechargé à neuf au début de chaque session par conception, il survit donc à un /clear et est réinjecté. Votre briefing de projet reste. Seul le bagage conversationnel disparaît.
Je pensais autrefois qu'effacer signifiait "perdre tout et ré-expliquer tout le projet." Ce n'est pas le cas — pas si vous avez mis les choses durables (architecture, conventions, le schéma de base de données) dans CLAUDE.md où elles appartiennent. Cette prise de conscience est ce qui m'a finalement fait effacer constamment au lieu de le redouter.
Maintenant la règle que je suis : dès que je termine une tâche logique et passe à une sans rapport, j'efface. Fini de configurer l'authentification, sur le point de construire la page de facturation ? /clear. Deux raisons. Premièrement, une fenêtre de contexte obsolète pleine de détails d'authentification rend Claude moins bon dans le travail de facturation — il reconnaît des patterns sur les mauvaises choses, référence des fichiers sans importance, et occasionnellement édite "utilement" quelque chose que je n'ai jamais demandé de toucher. Deuxièmement, chaque token de ce contexte mort est un token pour lequel je paie et un token qui grignote mes limites d'utilisation. Une session longue et errante est coûteuse dans les deux sens.
Si vous n'adoptez qu'une seule commande de tout ce post, que ce soit celle-ci. Effacez entre les tâches. Votre qualité de production monte et votre consommation baisse en même temps, ce qui n'arrive presque jamais ensemble.
Il y a une commande apparentée qui vaut la peine d'être connue : /compact. Là où /clear jette entièrement la conversation, /compact la résume sous une forme compressée pour que vous gardiez l'essentiel tout en libérant du contexte. Je recours à /compact en plein milieu d'une tâche quand un travail individuel est devenu long mais que j'ai encore besoin de son historique ; je recours à /clear quand j'ai véritablement terminé et que je change de vitesse. Des outils différents pour des moments différents.
/resume — récupérer une conversation que vous pensiez perdue
/resume vous permet de rouvrir une conversation Claude Code précédente en la sélectionnant dans une liste, donc une session que vous avez fermée — ou même effacée — n'est pas nécessairement perdue.
C'est la commande qui m'a épargné un vrai chagrin. Imaginez le scénario : j'efface une session, change de tâche, et vingt minutes plus tard je réalise que j'avais besoin de quelque chose de la conversation que je viens d'effacer — une décision que nous avons prise, un extrait de code que Claude a généré, le raisonnement derrière une approche. Avant /resume, c'était parti et je le sentais.
Avec /resume, j'exécute la commande, obtiens une liste des sessions récentes, et choisis celle que je veux récupérer. C'est distinct du rembobinage dans une conversation active — /resume atteint à travers les sessions pour en récupérer une précédente entièrement. Voyez cela comme la différence entre annuler vos dernières modifications dans un document versus rouvrir un fichier que vous avez fermé hier.
Le workflow que j'ai développé : j'efface agressivement parce que je sais que /resume me couvre. La peur de perdre du contexte était ce qui me faisait accumuler. Une fois que j'ai eu confiance que je pouvais récupérer une ancienne session quand j'en avais véritablement besoin, effacer a cessé de sembler risqué et a commencé à ressembler à de l'hygiène.
/rewind — l'annulation pour le code, pas seulement pour les conversations
/rewind rembobine votre session à un point de contrôle antérieur, et peut restaurer votre code, votre conversation, ou les deux — indépendamment.
C'est la commande qui a changé le degré d'ambition avec lequel je laisse Claude travailler. Claude Code crée automatiquement un point de contrôle capturant l'état de votre code avant chaque modification, chaque fois que vous envoyez un prompt. Donc quand un changement multi-fichiers tourne mal — et lors d'un gros refactoring, ça arrive parfois — je ne panique pas et ne commence pas à revert des fichiers manuellement. J'ouvre /rewind.
Vous pouvez le déclencher de deux façons : tapez /rewind, ou appuyez sur Échap deux fois quand le champ de saisie du prompt est vide. Les deux ouvrent le menu de rembobinage montrant vos points de contrôle récents. Puis vous choisissez quoi restaurer :
- Restaurer le code et la conversation — revenez aux deux à ce point, comme si les dernières minutes n'avaient jamais eu lieu.
- Restaurer la conversation — rembobinez le chat à un message antérieur mais gardez votre code actuel. Utile quand le code est bien mais que la conversation a pris un chemin confus.
- Restaurer le code — revertez les changements de fichiers mais continuez à discuter. C'est celui que j'utilise le plus : "cette approche était mauvaise, annulez les fichiers, mais continuons à discuter pourquoi."
Il y a aussi des options "résumer à partir d'ici" / "résumer jusqu'ici" qui compriment une partie de la conversation pour récupérer du contexte — un joli chevauchement avec l'idée de /compact.
Une limitation que vous devez absolument connaître, car elle a brûlé des gens : /rewind ne suit que les modifications que Claude a faites via ses outils d'édition de fichiers. Les commandes Bash ne sont pas sauvegardées en point de contrôle. Si Claude a exécuté rm, mv ou cp, ces changements sont permanents — rembobiner ne les ramènera pas. Les points de contrôle persistent aussi entre les sessions et se nettoient automatiquement après 30 jours. Donc le rembobinage est un filet de sécurité pour les modifications, pas un substitut de git. Je commite encore souvent. Le rembobinage est pour les moments intermédiaires ; git est pour la vérité fondamentale.
Si vous voulez approfondir comment je structure l'utilisation des tokens autour de tout cet effacement et cette compaction, j'ai détaillé cela séparément dans mon guide pour réduire les coûts de tokens de Claude Code avec l'approche homme des cavernes — la discipline du contexte et la discipline des coûts sont la même compétence portant deux chapeaux.
Voilà pour le contexte. Le groupe suivant porte sur la qualité — faire réfléchir Claude avant d'agir.
Planification et qualité : mode plan et clarifier-puis-planifier
Le plus grand bond dans ma qualité de production n'est pas venu d'une commande de contexte. Il est venu du fait de forcer Claude à planifier avant d'écrire une seule ligne. Il y a deux façons dont je fais cela — une intégrée, une que je construis moi-même — et la seconde est la pièce maîtresse de tout ce post.
Mode plan — voir l'approche avant que du code soit écrit
Le mode plan est un état en lecture seule où Claude analyse votre base de code et propose un plan d'implémentation complet avant de toucher un fichier, pour que vous puissiez revoir et ajuster l'approche avant que l'exécution ne commence.
Note rapide de précision, car cela embrouille les gens : beaucoup de vidéos et transcriptions appellent cela "la commande /plan," et c'est seulement à moitié vrai. Le mode plan est intégré dans le cycle de permissions de Claude Code depuis longtemps — vous l'activez en appuyant sur Shift+Tab deux fois pour atterrir sur ⏸ mode plan activé en bas de votre terminal. À partir de Claude Code v2.1.0, il y a aussi une commande littérale /plan qui active le même mode, plus vous pouvez lancer avec claude --permission-mode plan ou en faire un défaut de projet dans .claude/settings.json. Donc si vous avez entendu "/plan" et cela ne semblait rien faire dans une version antérieure — c'est pourquoi. Le chemin Shift+Tab fonctionne toujours.
Voici ce que le mode plan fait réellement. Tant qu'il est actif, Claude conserve un accès complet à ses outils de lecture — Read, Glob, Grep, WebSearch, WebFetch — mais chaque outil d'écriture est bloqué : pas d'Edit, pas de Write, pas d'exécution Bash. Il lit votre base de code, cartographie les dépendances, raisonne à travers toute l'approche, et vous remet un plan numéroté. Vous le lisez. Vous le corrigez s'il est faux. Puis vous approuvez, et c'est seulement alors qu'il exécute.
Le moment où je recours au mode plan : toute tâche qui touche plus de deux ou trois fichiers, ou quoi que ce soit où je ne suis pas sûr à 100% que Claude et moi partageons le même modèle mental de comment le changement devrait se produire. Une migration de base de données. Un refactoring à travers les composants. Le branchement d'une nouvelle API dans un flux existant. Pour ceux-là, regarder le plan de Claude attrape le malentendu avant qu'il ne devienne trente minutes de code erroné que je dois ensuite rembobiner.
L'erreur que je vois les gens faire est d'utiliser le mode plan pour tout, y compris les modifications triviales d'un seul fichier, où il ajoute seulement de la friction. Le mode plan mérite sa place dans l'ambiguïté et l'échelle. Pour "ajoute un console.log ici," passez.
Le mode plan est puissant, mais il est réactif — Claude planifie en fonction de ce que je lui ai dit. La technique suivante résout le problème plus profond : que se passe-t-il quand mon prompt lui-même était incomplet.
Commandes slash personnalisées — construire une commande "clarifier, puis planifier, puis exécuter"
C'est la section que je vous dirais de lire deux fois. Les commandes slash personnalisées sont la fonctionnalité avec le plus grand effet de levier dans Claude Code que la plupart des gens ne touchent jamais, et elles sont véritablement simples à construire.
Une commande slash personnalisée est simplement un fichier Markdown. Vous créez un fichier dans .claude/commands/ (portée projet, partagé avec tous dans le repo) ou ~/.claude/commands/ (personnel, vous suit dans chaque projet). Le nom de fichier devient le nom de la commande. Le contenu du fichier devient le prompt envoyé à Claude quand vous l'invoquez. C'est tout le mécanisme.
Donc si j'exécute ceci :
mkdir -p .claude/commands
et crée un fichier nommé .claude/commands/build.md, alors taper /build dans n'importe quelle session au sein de ce projet injecte ce que j'ai écrit dans ce fichier comme mon prompt. La commande apparaît automatiquement dans le menu d'auto-complétion /.
Maintenant — pourquoi est-ce important ? Parce que le plus grand tueur de qualité dans le codage IA n'est pas le modèle. C'est l'écart entre ce que j'ai demandé et ce que je voulais réellement dire. J'écris un prompt vague, Claude fait des hypothèses raisonnables-mais-fausses pour combler l'écart, et j'obtiens du code confiant et propre qui résout le mauvais problème.
La solution est une commande qui force Claude à combler cet écart avant d'écrire quoi que ce soit. Voici la commande réelle que je garde dans mes repos. Appelez-la .claude/commands/scope.md :
# Clarifie la demande, puis planifie, puis construis.
Tu es sur le point d'implémenter : $ARGUMENTS
N'écris PAS de code encore. Travaille ces étapes dans l'ordre :
1. CLARIFIE. Pose-moi jusqu'à 5 questions spécifiques sur tout ce qui est
ambigu dans la demande — formes de données, cas limites, nommage, où cela
s'insère dans l'architecture existante, à quoi ressemble "terminé". Si quelque
chose est véritablement sans ambiguïté, ne remplis pas la liste — demande
seulement ce dont tu as besoin.
2. PLANIFIE. Une fois que j'ai répondu, reformule la tâche en une phrase, puis
donne-moi un plan d'implémentation numéroté : les fichiers que tu vas créer ou
modifier, l'ordre dans lequel tu les feras, et chaque décision que tu prends que
je devrais opposer maintenant plutôt qu'après que le code existe.
3. ATTENDS. Arrête-toi et laisse-moi approuver ou corriger le plan avant que tu
touches un seul fichier.
Ne commence à implémenter qu'après mon approbation.
Le marqueur $ARGUMENTS est le vrai truc — tout ce que je tape après le nom de la commande est inséré là. Donc j'exécute /scope ajouter les invitations d'équipe à la page de paramètres et Claude prend "ajouter les invitations d'équipe à la page de paramètres" comme la chose à clarifier et planifier.
Qu'est-ce que ça m'apporte en pratique ? Les questions de clarification sont là où se trouve la magie. La moitié du temps, les questions de Claude font remonter quelque chose que je n'avais pas encore décidé — "les utilisateurs invités devraient-ils obtenir un rôle immédiatement ou rester en attente jusqu'à ce qu'ils acceptent ?" — et y répondre à voix haute, avant qu'aucun code n'existe signifie que je n'obtiens jamais la mauvaise implémentation en premier lieu. L'étape du plan me permet ensuite d'opposer un veto à une approche à moindre coût, tant que ce sont encore des mots sur un écran plutôt que des fichiers sur disque.
Je ne peux pas vous donner un pourcentage net de combien cela améliore la production — et je veux être honnête à ce sujet, car j'ai vu circuler l'affirmation que les commandes personnalisées de clarifier-puis-planifier améliorent la qualité "jusqu'à 43% selon des rapports internes," et je n'ai jamais pu trouver de base réelle pour ce nombre. Donc je ne vais pas prétendre. Ce que je peux vous dire de l'utilisation quotidienne est qualitatif et constant : forcer la séquence clarifier-puis-planifier-puis-exécuter réduit significativement le nombre de réécritures "ce n'est pas ce que je voulais dire" que je fais. Le retravail que j'économise est tout le retour sur investissement. Que le chiffre ne soit pas vérifiable ne rend pas la technique moins réelle — cela signifie juste que je ne vais pas l'habiller d'une statistique que je ne peux pas défendre.
Si vous voulez approfondir la construction de ceux-ci, j'ai écrit une analyse complète de la commande slash personnalisée /advisor et la couche métacognitive qu'elle ajoute — les mêmes briques de construction, un objectif différent. Et la raison pour laquelle toute cette approche fonctionne se connecte directement à pourquoi l'ingénierie de contexte devient une compétence fondamentale à l'épreuve du futur : les développeurs qui gagnent avec ces outils ne sont pas ceux qui tapent le plus vite, ce sont ceux qui structurent le mieux le contexte et l'intention.
Si vous préférez que quelqu'un construise une configuration complète de commandes personnalisées et d'agents adaptée à votre stack plutôt que de l'assembler vous-même, c'est le genre de travail que j'accepte directement — vous pouvez voir ce que j'ai construit sur mon profil Fiverr.
Un mot rapide sur une commande sur laquelle les gens posent des questions mais qui n'existe pas comme ils le pensent.
À propos de "/goal" — un patron que vous construisez, pas un bouton sur lequel vous appuyez
On me pose des questions sur une commande "/goal" qui vous permettrait soi-disant de définir une tâche plus une définition de "terminé" et de faire travailler Claude jusqu'à ce qu'un second agent vérifie que c'est complet. J'ai investigué cela attentivement, et voici l'image honnête : il n'y a pas de commande slash /goal intégrée dans Claude Code qui fait cela. Je n'ai pas pu la confirmer dans la documentation actuelle, et vous ne devriez pas la chercher comme une fonctionnalité standard.
Ce qui est réel, c'est le patron derrière — et c'est un bon patron. Vous pouvez absolument construire vous-même un workflow orienté vérification : une commande personnalisée qui donne à Claude une tâche plus des critères explicites de "définition de terminé", associée à un sous-agent dont le seul travail est de vérifier le travail contre ces critères avant de le déclarer terminé. C'est quelque chose de constructible, pas quelque chose d'intégré. (Le Codex d'OpenAI, séparément, inclut une commande littérale /goal pour les exécutions autonomes — je l'ai testée et j'ai écrit comment la commande /goal de Codex se comporte réellement. Ne confondez pas les deux ; ce sont des outils différents.)
La conclusion : si un tutoriel vous promet un bouton magique /goal de Claude Code, soyez sceptique. La capacité est à vous d'assembler avec des commandes personnalisées et des sous-agents — ce qui est plus flexible de toute façon.
Maintenant les petites choses qui améliorent silencieusement chaque session.
Environnement et UX : /statusline et apprendre l'outil
Ceux-ci ne changent pas ce que Claude fait. Ils changent combien je peux voir pendant qu'il le fait — et à quelle vitesse je découvre des fonctionnalités dont je ne savais pas qu'elles existaient.
/statusline — une configuration unique qui rapporte à chaque session
/statusline configure la barre d'état en bas de votre terminal, vous permettant d'afficher des choses comme le modèle actif, l'utilisation du contexte et le coût — pour que vous puissiez voir d'un coup d'œil ce qui se passe sans deviner.
Encore une note de précision : les gens l'écrivent "/status line" (deux mots). La vraie commande est /statusline, un seul mot, dans l'auto-complétion. Vous l'exécutez une fois, configurez ce que vous voulez voir, et ensuite c'est simplement là à chaque session.
Pourquoi je m'en donne la peine : la visibilité de l'utilisation du contexte et des coûts. Quand ma barre d'état me montre à quel point la fenêtre de contexte se remplit, je sais qu'il est temps de /clear ou /compact avant que Claude ne commence à se dégrader — au lieu de remarquer la dégradation après coup. Voir le modèle actif me rappelle si je suis au bon niveau pour la tâche. C'est une petite configuration unique qui transforme un tas d'état invisible en quelque chose de lisible d'un coup d'œil. Pour la philosophie plus profonde de "voir et piloter tout ce que Claude fait," j'ai approfondi dans mon analyse de la couche visuelle de l'OS agentique.
/powerup et /radio — les deux que je mentionnerai mais ne survends pas
Deux autres commandes réelles, incluses par souci d'exhaustivité et d'honnêteté.
/powerup (introduit dans Claude Code v2.1.90) est un tutoriel interactif dans le terminal — des leçons animées qui enseignent chacune une chose que Claude Code peut faire et que la plupart des gens ratent. C'est véritablement utile pour découvrir des fonctionnalités, et je lui ai donné sa propre première impression complète dans mon article sur ce que /powerup enseigne vraiment, donc je ne répéterai pas cela ici.
/radio est aussi réel, et c'est exactement ce que ça semble être : ça ouvre Claude FM, une station de radio lo-fi que Anthropic opère, dans votre navigateur. Est-ce une commande de productivité ? Non. Est-ce que je l'utilise pendant les parties ennuyeuses d'un build ? Parfois. Je l'inclus parce que je vous ai dit que je donnerais l'image exacte, et l'image exacte est que ça existe et c'est un petit rien amusant. Traitez-le en conséquence.
Il y a aussi /btw — une façon plus légère de poser une question parallèle ou d'ajouter du contexte sans que ça ne gonfle votre fil de conversation principal, ce qui garde les longues sessions plus minces. C'est un mécanisme réel qui vaut la peine d'être connu si vous voulez vous clarifier en plein milieu d'une tâche sans faire dérailler le flux.
Voilà le registre honnête. Maintenant laissez-moi vous montrer à quoi ça ressemble quand tout est enchaîné sur du vrai travail.
À quoi ressemble une vraie session avec ces commandes enchaînées
Les commandes dans une liste sont abstraites. Voici comment elles s'enchaînent réellement lors d'une journée de construction normale pour moi.
J'ouvre Claude Code dans un projet. CLAUDE.md charge automatiquement, donc Claude connaît déjà la stack et les conventions — je ne ré-explique rien. Je veux ajouter une fonctionnalité, donc je tape /scope ajouter l'export CSV à la page de rapports. Ma commande personnalisée entre en action : Claude me pose quatre questions (quelles colonnes, quel format de date, génération côté serveur ou client, quel devrait être le nom du fichier), je réponds, il me donne un plan en cinq étapes, j'ajuste l'étape trois, j'approuve.
Il construit. À mi-chemin, la logique d'export s'emmêle avec la pagination existante et la sortie n'est pas correcte. Je ne démêle pas manuellement — j'ouvre /rewind, restaure le code à avant l'emmêlement en gardant la conversation, et dis "cette approche entrait en conflit avec la pagination, générons le jeu de données complet séparément." Récupération propre, peut-être quatre-vingt-dix secondes perdues.
Fonctionnalité terminée. Je /clear. Fenêtre fraîche, mémoire du projet intacte, zéro contexte obsolète qui fuit dans la tâche suivante. Ma barre d'état — configurée une fois avec /statusline il y a des semaines — montre que j'utilise à peine du contexte, ce qui est exactement comme une tâche fraîche devrait commencer.
Trois tâches plus tard, je réalise que j'ai besoin d'une décision d'une session que j'ai effacée plus tôt. /resume, je la choisis dans la liste, je récupère ce dont j'avais besoin, je retourne au travail.
Cinq commandes. Aucune d'entre elles n'a écrit de code. Toutes ont façonné les conditions dans lesquelles le code a été bien écrit. C'est tout l'intérêt — les commandes slash ne sont pas le travail, elles sont l'atelier.
La partie honnête : où j'avais tort, et ce qui vaut votre temps
Laissez-moi être direct sur les corrections, car regarder un praticien revenir sur ses propres hypothèses est plus utile qu'une liste propre qui prétend que tout est confirmé.
J'ai passé trop longtemps à traiter /clear comme une perte au lieu d'une hygiène — c'était une vraie taxe sur le workflow que j'ai payée pendant des mois. "/plan" comme commande autonome est plus récent (v2.1.0) que le mode plan Shift+Tab sur lequel il repose, donc si vous êtes sur une version plus ancienne, utilisez le raccourci clavier. "/statusline" est un mot, pas deux. Et la "commande /goal" que les gens décrivent comme intégrée à Claude Code ne l'est pas — c'est un patron que vous assemblez, et le confondre avec la commande /goal réelle de Codex brouille les eaux. Le chiffre de "43% d'amélioration de qualité" attribué aux commandes personnalisées n'a aucune base que j'aie pu trouver, donc je l'ai abandonné et je vous ai dit pourquoi au lieu de transformer un chiffre non vérifiable en une affirmation confiante.
Ce qui vaut véritablement votre temps, par ordre de priorité : /clear entre les tâches (gain le plus grand et le plus facile), une commande personnalisée clarifier-puis-planifier (plus grand gain de qualité), /rewind pour se remettre de mauvaises modifications (plus grande réduction de stress), et le mode plan pour tout ce qui est ambigu ou multi-fichiers (plus grand préventeur de "code erroné"). Le reste — /resume, /statusline, /compact, /btw — sont réels, utiles et dignes d'être connus, mais ce sont les seconds rôles.
Si vos sessions Claude Code ressemblent actuellement à de longues conversations errantes qui empirent plus elles durent, la solution n'est pas un meilleur modèle. C'est une barre oblique, quatre lettres, et la discipline d'effacer ce dont vous n'avez pas besoin. Allez construire une commande personnalisée cette semaine — l'exemple /scope ci-dessus, copié directement dans .claude/commands/scope.md — et utilisez-la sur votre prochaine vraie tâche. La première fois que les questions de clarification de Claude attraperont une mauvaise hypothèse avant qu'elle ne devienne du mauvais code, vous comprendrez pourquoi je tape cette barre oblique avant que mon cerveau ne finisse la pensée.
Questions fréquemment posées
Quelle est la différence entre /clear et /rewind dans Claude Code ?
/clear efface votre historique de conversation actuel pour commencer une tâche fraîche tout en conservant votre mémoire de projet CLAUDE.md, tandis que /rewind rembobine à un point de contrôle antérieur au sein d'une session active et peut restaurer votre code, votre conversation, ou les deux. Utilisez /clear quand vous passez à une tâche sans rapport ; utilisez /rewind quand une modification a mal tourné et que vous devez l'annuler. Voir la section de gestion du contexte ci-dessus pour l'analyse complète.
Est-ce que /clear supprime ma mémoire de projet CLAUDE.md ?
Non — /clear ne supprime que la conversation active de la fenêtre de contexte ; votre fichier CLAUDE.md est rechargé à neuf au début de chaque session, il survit donc à l'effacement. C'est exactement pourquoi vous pouvez effacer agressivement entre les tâches sans perdre le contexte durable de votre projet, tant que les choses importantes vivent dans CLAUDE.md.
Comment créer une commande slash personnalisée dans Claude Code ?
Créez un fichier Markdown dans .claude/commands/ (portée projet) ou ~/.claude/commands/ (personnel), et le nom de fichier devient le nom de la commande tandis que le contenu du fichier devient le prompt envoyé à Claude. Utilisez le marqueur $ARGUMENTS pour passer des entrées après le nom de la commande. L'exemple complet /scope clarifier-puis-planifier se trouve dans la section planification ci-dessus.
Y a-t-il une commande /plan ou est-ce le mode plan dans Claude Code ?
Les deux — le mode plan est intégré depuis longtemps dans le cycle de permissions (appuyez deux fois sur Shift+Tab), et à partir de Claude Code v2.1.0, il y a aussi une commande littérale /plan qui active le même état de planification en lecture seule. Si /plan ne fait rien sur votre configuration, vous êtes probablement sur une version plus ancienne ; le raccourci Shift+Tab fonctionne toujours.
Y a-t-il une commande /goal intégrée dans Claude Code ?
Non, il n'y a pas de commande /goal standard dans Claude Code qui exécute une tâche jusqu'à une définition de "terminé" avec vérification automatique. Cette capacité est un patron que vous construisez vous-même en utilisant une commande personnalisée plus un sous-agent de vérification. Le Codex d'OpenAI inclut une commande /goal séparée, mais c'est un outil entièrement différent.
Travaillons ensemble
Vous cherchez à construire des systèmes IA, automatiser des workflows, ou mettre à l'échelle votre infrastructure technique ? Je serais ravi d'aider.
- Fiverr (constructions sur mesure et intégrations) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design et branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
