Claude Code est devenu l’un des outils les plus puissants pour coder avec l’IA directement depuis son terminal. Mais autour de lui, une série de commandes “secrètes” circule sur les réseaux : /ghost, OODA, L99, /godmode, BEASTMODE, etc.

Le problème ? Toutes ne sont pas de vraies commandes Claude Code.

Certaines sont des commandes slash officielles, reconnues par le CLI. D’autres sont plutôt des raccourcis de prompt, c’est-à-dire des mots-clés que l’on place au début d’une demande pour orienter le style de réponse de Claude. Enfin, certaines promesses sont clairement exagérées : non, /ghost ne rend pas magiquement un texte “indétectable”, et L99 ne débloque pas un mode expert caché dans Claude Code.

L’objectif de cet article est de faire le tri : quelles commandes sont utiles, comment les utiliser, et dans quels cas elles peuvent réellement débloquer votre workflow.

Commandes officielles vs “cheat codes” : la différence essentielle

Dans Claude Code, une vraie commande slash est une commande reconnue par le CLI, placée au début du message. La documentation officielle précise que les commandes permettent notamment de changer de modèle, gérer les permissions, effacer ou compacter le contexte, exécuter des workflows, ou encore afficher l’état de la session. Une commande n’est reconnue que si elle est placée au début du message.

Exemples de vraies commandes officielles :

/plan
/compact
/clear
/model
/effort
/memory
/agents
/review
/security-review

À côté de cela, on trouve des “commandes” comme :

/ghost
OODA
L99
/godmode
BEASTMODE
PERSONA
PARETO

Celles-ci ne sont généralement pas des commandes natives de Claude Code. Ce sont plutôt des conventions de prompt engineering : Claude lit le mot-clé, comprend l’intention, et adapte sa réponse. Une analyse récente de ces “cheat codes” indique que les claims viraux autour de /ghost, OODA ou L99 ne correspondent pas à des fonctionnalités cachées présentes dans le code de Claude Code.

Autrement dit : ils peuvent être utiles, mais il faut les utiliser comme des prompts structurants, pas comme des options système magiques.

/ghost : rendre les textes plus naturels, pas “indétectables”

Ce que /ghost est censé faire

/ghost est souvent présenté comme une commande qui permettrait de rendre un texte impossible à détecter comme étant généré par IA. Cette promesse est problématique, car aucun prompt ne garantit qu’un texte sera “indétectable”. Les détecteurs d’IA sont eux-mêmes imparfaits, et Claude Code ne possède pas officiellement une commande /ghost qui active un mode caché.

En pratique, /ghost fonctionne surtout comme une instruction de style : elle demande à Claude de retirer les formulations artificielles, les tournures trop lisses, le ton corporate, les phrases génériques et les transitions typiques des contenus IA. Un guide communautaire décrit /ghost comme un raccourci pour produire une écriture plus directe, utile pour des READMEs, des PR descriptions, des emails, des commentaires ou de la documentation.

Exemple d’utilisation

/ghost Réécris cette description de pull request pour qu’elle soit plus naturelle, directe et proche du style d’un développeur senior.

Texte :
Cette pull request vise à améliorer la robustesse globale du module d’authentification en introduisant une meilleure gestion des erreurs...

Résultat attendu

Claude devrait produire un texte plus sobre :

Cette PR améliore la gestion des erreurs dans le module d’authentification.

Changements principaux :
- meilleure distinction entre erreurs serveur et erreurs utilisateur ;
- messages plus clairs côté client ;
- ajout de tests sur les cas d’expiration de session.

Quand l’utiliser ?

/ghost est utile pour :

• des descriptions de pull request ;
• des messages Slack ;
• des emails techniques ;
• des README ;
• des articles ou contenus marketing à retravailler ;
• des commentaires de code trop verbeux.

Limite importante

Il vaut mieux éviter de le présenter comme une commande pour “bypasser” les détecteurs d’IA. La bonne formulation serait plutôt :

Réécris ce texte dans un style plus humain, plus direct, moins générique et moins promotionnel.

OODA : forcer Claude à décider au lieu de répondre “ça dépend”

Qu’est-ce que le framework OODA ?

OODA signifie Observe, Orient, Decide, Act. C’est un cadre de prise de décision qui pousse à analyser une situation en quatre temps :

1. Observer les faits.
2. Orienter l’analyse selon le contexte.
3. Décider.
4. Agir.

Dans Claude Code, OODA n’est pas documenté comme une commande officielle. C’est un mot-clé de prompt qui peut aider Claude à structurer une réponse plus opérationnelle. Des guides communautaires le présentent comme une manière d’éviter les réponses trop neutres du type “cela dépend”, en demandant à Claude d’arriver à une recommandation concrète.

Exemple d’utilisation pour une décision technique

OODA: Notre application utilise actuellement REST. Nous devons ajouter des fonctionnalités temps réel pour les notifications et le suivi d’état.

Contexte :
- équipe de 3 développeurs ;
- déploiements hebdomadaires ;
- stack Node.js + React ;
- peu d’expérience WebSocket en interne.

Doit-on utiliser WebSockets, SSE ou GraphQL subscriptions ?

Résultat attendu

Claude devrait répondre avec une structure de ce type :

Observe :
Vous avez besoin de temps réel, mais l’équipe est petite et doit livrer rapidement.

Orient :
Les notifications et les changements d’état ne nécessitent pas forcément une communication bidirectionnelle complète.

Decide :
Je recommande Server-Sent Events pour commencer.

Act :
1. Créer un endpoint /events côté backend.
2. Ajouter EventSource côté frontend.
3. Prévoir un fallback polling.
4. Mesurer la charge avant de passer à WebSocket.

Pourquoi c’est utile ?

OODA est particulièrement intéressant quand vous avez besoin d’une décision, pas d’un catalogue d’options.

Exemples :

OODA: Devons-nous refactorer ce module maintenant ou après la release ?

OODA: Quelle architecture choisir pour migrer cette app Laravel vers une API découplée ?

OODA: Est-ce que cette dette technique bloque réellement la roadmap ou peut attendre ?

Limite

OODA ne rend pas Claude infaillible. Il force surtout une meilleure structure de raisonnement. Pour des décisions sensibles, il faut toujours demander les risques, les hypothèses et les alternatives.

L99 : demander une réponse de niveau expert

Ce que signifie L99

L99 est souvent décrit comme un déclencheur de “niveau 99”, donc une demande de profondeur maximale. Là encore, ce n’est pas une commande officielle documentée par Anthropic. C’est plutôt une instruction courte qui signifie : “réponds comme un expert, avec un niveau de détail avancé”.

Des listes communautaires le présentent comme un raccourci pour obtenir plus de profondeur, notamment sur des sujets techniques complexes.

Exemple simple

L99: Analyse cette stratégie de cache pour une API e-commerce à fort trafic.

Contexte :
- Node.js + PostgreSQL ;
- Redis disponible ;
- catalogue produit mis à jour plusieurs fois par jour ;
- prix personnalisés selon les clients ;
- besoin de réduire la latence sous 150 ms.

Résultat attendu

Au lieu d’une réponse généraliste, Claude devrait entrer dans les détails :

- séparation entre cache catalogue et cache pricing ;
- invalidation par événement ;
- TTL différenciés ;
- cache stampede protection ;
- stratégie stale-while-revalidate ;
- risques liés aux prix personnalisés ;
- métriques à surveiller.

Meilleure alternative à L99

Au lieu d’écrire uniquement :

L99: Optimise mon architecture.

Il vaut mieux écrire :

Réponds comme un architecte logiciel senior. Va au niveau expert. Donne :
1. les risques ;
2. les compromis ;
3. l’architecture recommandée ;
4. les étapes de migration ;
5. les pièges à éviter ;
6. un exemple concret.

L99 peut être pratique, mais une instruction explicite reste plus fiable.

/plan : passer en mode plan avant de modifier le code

Contrairement à /ghost, OODA ou L99, /plan est une vraie commande Claude Code. Elle permet d’entrer directement en mode plan à partir de l’invite, avec une description optionnelle de la tâche. Exemple officiel : /plan fix the auth bug.

Exemple

/plan refactor the checkout flow to separate payment, validation and order creation

Quand l’utiliser ?

/plan est très utile avant :

• une refonte importante ;
• une migration ;
• une correction touchant plusieurs fichiers ;
• une tâche où vous voulez valider l’approche avant que Claude modifie le code.

Exemple de prompt amélioré

/plan migrate the legacy payment service to a provider-agnostic adapter pattern

Contraintes :
- ne pas casser l’API publique actuelle ;
- garder Stripe comme provider par défaut ;
- ajouter des tests unitaires ;
- proposer les étapes avant de modifier le code.

/compact : garder le contexte sans saturer la conversation

Claude Code peut accumuler beaucoup de contexte au fil d’une session. /compact sert à résumer l’historique de conversation afin de réduire la taille du contexte tout en conservant les informations importantes. La documentation SDK indique que /compact compacte l’historique en résumant les messages plus anciens tout en préservant le contexte utile.

Exemple

/compact

Quand l’utiliser ?

Utilisez /compact lorsque :

• la conversation devient longue ;
• Claude commence à perdre le fil ;
• vous avez terminé une grande étape ;
• vous voulez continuer sans repartir de zéro ;
• vous approchez des limites de contexte.

Bon réflexe

Avant de lancer /compact, vous pouvez demander :

Résume l’état actuel du projet, les décisions prises, les fichiers modifiés et les prochaines étapes. Puis je lancerai /compact.

Cela aide à garder un résumé plus propre.

/clear : repartir sur une nouvelle tâche

/clear permet de démarrer une nouvelle tâche tout en conservant la mémoire du projet. Dans le SDK, la documentation précise que /clear n’est pas disponible de la même manière qu’en mode interactif : chaque appel query() démarre déjà une nouvelle conversation.

Exemple

/clear

Quand l’utiliser ?

/clear est utile quand :

• vous changez complètement de sujet ;
• Claude reste bloqué dans une mauvaise direction ;
• vous voulez éviter que l’ancienne tâche influence la nouvelle ;
• vous passez d’un bug backend à un travail frontend sans lien direct.

/memory : améliorer les réponses sur la durée

/memory permet de modifier les fichiers de mémoire CLAUDE.md, d’activer ou désactiver la mémoire automatique et d’afficher les entrées de mémoire automatique.

Dans Claude Code, le fichier CLAUDE.md est important parce qu’il peut contenir les conventions du projet : commandes de test, architecture, règles de style, préférences d’équipe, pièges connus, etc.

Exemple

/memory

Ce qu’on peut y mettre

# Project conventions

- Use pnpm, not npm.
- Run tests with pnpm test.
- Components live in src/components.
- API routes live in src/app/api.
- Never modify generated Prisma files manually.
- Prefer small pull requests.

Pourquoi c’est puissant ?

Au lieu de répéter à chaque session :

Utilise pnpm, respecte notre architecture, ne touche pas aux fichiers générés...

Vous l’inscrivez dans la mémoire du projet.

/effort : ajuster le niveau de réflexion

/effort permet de définir le niveau d’effort du modèle. La documentation mentionne les niveaux low, medium, high, xhigh ou max, selon le modèle et l’environnement disponibles.

Exemple

/effort high

Ou :

/effort max

Quand l’utiliser ?

Niveau faible ou moyen :

/effort low

Pour :

• petites corrections ;
• reformulation simple ;
• génération de boilerplate ;
• tâches rapides.

Niveau élevé :

/effort high

Pour :

• bugs complexes ;
• architecture ;
• sécurité ;
• refactoring important ;
• analyse de performance.

Exemple concret

/effort high

Puis :

Analyse pourquoi cette suite de tests devient flaky uniquement en CI. Cherche les causes possibles dans le code, la config et les dépendances.

/agents et /batch : déléguer les tâches complexes

/agents ouvre le gestionnaire des agents auxquels Claude peut déléguer des sous-tâches. /batch est un skill qui orchestre des changements à grande échelle : il recherche dans la base de code, décompose le travail en unités indépendantes, puis peut générer des sous-agents dans des worktrees isolés.

Exemple avec /batch

/batch migrate all legacy Vue components in src/legacy to React components

Quand l’utiliser ?

/batch est pertinent pour :

• migrations massives ;
• refactoring multi-fichiers ;
• remplacement de librairie ;
• modernisation d’un ancien module ;
• changements répétitifs mais risqués.

Exemple plus précis

/batch Replace all direct Stripe SDK calls with our new PaymentProvider abstraction.

Contraintes :
- chaque changement doit être isolé ;
- ajouter ou mettre à jour les tests ;
- ne pas modifier le comportement public ;
- ouvrir une PR par zone fonctionnelle.

/review et /security-review : relire avant de livrer

Claude Code propose des commandes utiles avant de livrer une modification. /review sert à examiner une pull request localement, tandis que /security-review analyse les changements en attente sur la branche actuelle pour identifier des vulnérabilités potentielles comme l’injection, les problèmes d’authentification ou l’exposition de données.

Exemple

/security-review

Exemple avec contexte

Avant de merger cette branche, vérifie les risques de sécurité liés à l’authentification, aux permissions utilisateur et à la validation des inputs.

Quand l’utiliser ?

• avant une pull request ;
• avant une mise en production ;
• après un changement dans l’authentification ;
• après une modification de permissions ;
• après l’ajout d’un endpoint API ;
• après une manipulation de données sensibles.

Créer ses propres commandes slash

Claude Code permet aussi de créer des commandes personnalisées. La documentation explique que les commandes personnalisées peuvent être définies sous forme de fichiers Markdown. Le format historique utilise .claude/commands/, tandis que le format recommandé actuellement est plutôt .claude/skills//SKILL.md, qui permet une invocation slash et une invocation autonome par Claude.

Exemple : créer une commande /pr-ready

Fichier :

.claude/commands/pr-ready.md

Contenu :

Analyse les changements actuels et prépare la branche pour une pull request.

Étapes :
1. Lire le diff git.
2. Identifier les risques.
3. Vérifier les tests à lancer.
4. Proposer un titre de PR.
5. Proposer une description claire.
6. Lister les points à vérifier manuellement.

Utilisation :

/pr-ready

Exemple : commande de review SEO

Pour un projet web, vous pourriez créer :

.claude/commands/seo-review.md

Contenu :

Analyse les fichiers modifiés sous l’angle SEO.

Vérifie :
- structure des titres ;
- meta title ;
- meta description ;
- liens internes ;
- accessibilité ;
- performance ;
- contenu dupliqué ;
- opportunités de maillage interne.

Utilisation :

/seo-review

C’est ici que Claude Code devient vraiment intéressant : vous pouvez transformer vos workflows récurrents en commandes internes adaptées à votre projet.

Les “commandes” communautaires utiles à connaître

Voici quelques raccourcis non officiels, mais pratiques si vous les voyez comme des prompts.

Attention : toutes ces commandes ne sont pas forcément reconnues comme des commandes natives. La plupart fonctionnent simplement parce que Claude comprend l’intention exprimée par le mot-clé.

La meilleure façon d’utiliser ces commandes

Le bon réflexe n’est pas de croire qu’un mot magique débloque Claude Code. Le bon réflexe est de combiner :

1. une commande officielle quand elle existe ;
2. un contexte clair ;
3. des contraintes ;
4. un format de sortie attendu ;
5. un niveau de profondeur demandé.

Mauvais prompt

L99 optimise mon app

Bon prompt

L99: Analyse les performances de cette app Next.js.

Objectif :
- réduire le Time to First Byte ;
- améliorer le Largest Contentful Paint ;
- éviter les optimisations cosmétiques.

Contraintes :
- ne pas changer le design ;
- garder l’architecture actuelle ;
- prioriser les changements à fort impact.

Format attendu :
1. diagnostic ;
2. top 5 des problèmes probables ;
3. plan d’action ;
4. commandes à lancer ;
5. fichiers à inspecter.

Conclusion

Les commandes comme /ghost, OODA ou L99 peuvent aider à mieux piloter Claude Code, mais elles ne sont pas des fonctionnalités cachées garanties. Ce sont surtout des raccourcis de prompt utiles pour orienter le style, la profondeur ou la structure d’une réponse.

Les vraies commandes officielles de Claude Code — comme /plan, /compact, /memory, /effort, /agents, /batch, /review ou /security-review — sont souvent plus puissantes, car elles interagissent réellement avec le fonctionnement du CLI, la session, le contexte, les agents ou le projet.

La meilleure approche consiste donc à utiliser les commandes officielles pour contrôler Claude Code, et les raccourcis communautaires pour mieux formuler vos intentions.

En résumé :

Commandes officielles = contrôle réel du workflow.
Cheat codes = raccourcis de formulation.
Bon contexte = meilleurs résultats.

Sources

1. Documentation officielle Claude Code – liste des commandes disponibles, fonctionnement des commandes slash, /plan, /memory, /effort, /review, /security-review, /agents, /batch, etc.
2. Documentation officielle Claude Code SDK – utilisation des slash commands, /compact, création de commandes personnalisées, anciens dossiers .claude/commands/ et format recommandé .claude/skills//SKILL.md.
3. Amit Kothari – test critique des “Claude cheat codes”, notamment /ghost, OODA et L99, avec conclusion qu’ils ne correspondent pas à des fonctionnalités cachées natives.
4. DEV Community – guide communautaire expliquant des usages pratiques de /ghost, OODA, L99, SCAFFOLD et autres frameworks de prompt. Source utile pour comprendre les usages populaires, mais à considérer comme non officielle.
5. GitHub – cheatsheet communautaire listant de nombreux raccourcis de prompt Claude, dont /ghost, OODA, L99, PARETO, PERSONA, etc.
6. GitHub – collection communautaire de commandes slash Claude Code, avec workflows et outils prêts à l’emploi. Source utile pour s’inspirer de commandes personnalisées.

Thomas Pecriaux

Black Sheep Code

13 article(s) published — Wordpress, SEO, Prestashop, PHP Development

linkedin.com