Ta boîte à outils : commandes slash et le dossier .claude/ de A à Z

Ton projet a grandi : il te faut une carte

En huit chapitres, le projet de Léa a accumulé des skills, des hooks, des subagents, des fichiers de réglages et une mémoire projet. Tout fonctionne — mais si on te demandait de dessiner où vit chaque pièce, saurais-tu le faire ? Ce chapitre te donne la carte complète. Ce n'est pas du rangement pour le plaisir : savoir précisément où vit chaque mécanisme, c'est savoir où chercher quand quelque chose ne marche pas, et où ajouter la prochaine brique sans casser les autres.

Il y a une deuxième raison, plus stratégique. Si Léa embauche un jour une assistante, ou si elle confie son site à un freelance, tout ce qui est bien rangé dans .claude/ et versionné dans Git se transmet : la personne clone le dépôt et hérite instantanément des conventions, des skills et des garde-fous. Le dossier .claude/ n'est pas un détail technique — c'est le capital opérationnel de la marque, sous forme de fichiers.

L'anatomie complète du dossier .claude/

Voici la vue d'ensemble : deux fichiers mémoire à la racine du projet, et un dossier .claude/ qui sert de centre de contrôle. La logique transversale, tu la connais déjà des chapitres 2 et 8 : chaque pièce existe en version partagée (commitée dans Git, pour l'équipe) et en version locale (gitignorée, pour toi seul).

flowchart TD
  P["Racine du projet"] --> M1["CLAUDE.md : instructions d'équipe, commité"]
  P --> M2["CLAUDE.local.md : overrides perso, gitignoré"]
  P --> R[".claude/ : le centre de contrôle"]
  R --> S1["settings.json : permissions + config, commité"]
  R --> S2["settings.local.json : réglages perso, gitignoré"]
  R --> CMD["commands/ : commandes slash custom"]
  CMD --> C1["10x.md → /project:10x"]
  R --> RU["rules/ : instructions modulaires"]
  RU --> R1["code-style.md, api-conventions.md"]
  R --> SK["skills/ : workflows auto-invoqués"]
  SK --> K1["post/SKILL.md"]
  R --> AG["agents/ : personas de subagents"]
  AG --> A1["code-reviewer.md, security-auditor.md"]

• CLAUDE.md (racine) — les instructions du projet, commitées : tout le monde en hérite (chapitre 8).
• CLAUDE.local.md (racine) — tes overrides personnels, gitignorés : tes raccourcis, tes préférences, tes chemins locaux.
• .claude/settings.json — permissions et configuration partagées avec l’équipe (chapitre 2).
• .claude/settings.local.json — tes permissions locales, gitignorées.
• .claude/commands/ — tes commandes slash personnalisées : un fichier nom.md devient /project:nom.
• .claude/rules/ — des fichiers d’instructions modulaires (style de code, conventions d’API…) référencés depuis CLAUDE.md.
• .claude/skills/ — les workflows auto-invoqués avec leur SKILL.md (chapitre 3).
• .claude/agents/ — les personas de subagents spécialisés (chapitre 6).

Le duo CLAUDE.md / CLAUDE.local.md mérite une précision, car il résout un problème réel d'équipe. Le premier porte la loi commune : conventions, structure, garde-fous. Le second porte tes particularités : « mes captures d'écran sont dans ~/Bureau/captures », « réponds-moi en français », « j'utilise tel alias ». Sans cette séparation, chaque membre d'équipe polluerait la mémoire commune avec ses détails personnels — ou pire, écraserait ceux des autres à chaque commit.

Les rules : découper la loi en modules

Au chapitre 8, on t'a dit de garder CLAUDE.md court. Mais que faire quand les conventions s'accumulent — style d'écriture, conventions de nommage des fichiers, règles d'API ? La réponse : le dossier .claude/rules/. Chaque thème devient un fichier dédié (code-style.md, api-conventions.md, testing.md), et CLAUDE.md se contente de les référencer. Claude charge la règle pertinente quand le sujet s'y prête.

Pour Léa, ça donne par exemple un rules/redaction.md (les règles d'écriture détaillées qui débordaient de brand-voice.md) et un rules/publication.md (créneaux, formats d'images par plateforme, politique de hashtags). Le bénéfice est le même que pour n'importe quel code : des modules courts et focalisés sont plus faciles à maintenir qu'un fichier monolithique — et tu peux en ajouter sans gonfler le contexte de chaque session.

SKILL.md : contenu de référence ou contenu de tâche ?

Maintenant que tu as écrit plusieurs skills, prenons de la hauteur. Un fichier SKILL.md peut contenir n'importe quelles instructions, mais en pratique il en existe deux grands types — et les distinguer t'aidera à écrire des skills plus nets. Le contenu de référence ajoute des connaissances que Claude applique à ton travail en cours : contexte métier, historique de l'entreprise, nuances de ta base de données, guides de style. Le contenu de tâche donne des instructions pas-à-pas pour une action précise : générer du code, créer des slides, rédiger un document.

Un skill de référence ressemble à une fiche que Claude garde sous les yeux pendant qu'il travaille :

---
name: contexte-marque
description: Connaissances sur la marque de Léa (positionnement, gammes, clientèle). Utiliser pour toute rédaction ou décision produit.
---

# La marque
- Cosmétiques bio, fabrication française, certifiée Ecocert.
- Positionnement : accessible et pédagogue, jamais culpabilisant.

# Les gammes
- Hydratation (best-seller : crème karité), Solaire (nouveau), Essentiels.

# La clientèle
- Femmes 25-45 ans, sensibles à la composition, achètent d'abord en ligne.

# Nuances importantes
- Ne jamais promettre de résultat dermatologique (contrainte légale).
- « Naturel » est banni : trop vague, préférer « certifié bio ».

Un skill de tâche, lui, est une procédure : des étapes ordonnées, des critères de sortie, des formats imposés. Ton /post du chapitre 3 en est un. En voici un autre, plus court, pour bien voir le contraste :

---
name: newsletter
description: Rédige la newsletter hebdomadaire au format maison. Utiliser quand l'utilisateur demande la newsletter.
---

# Étapes
1. Lis le journal des posts de la semaine (logs/posts.md).
2. Sélectionne les 3 posts les plus engageants.
3. Rédige : une intro de 2 phrases, les 3 posts résumés, un CTA vers la boutique.
4. Applique brand-voice.md.
5. Écris le résultat dans newsletters/AAAA-MM-JJ.md et demande validation.

# Critères de sortie
- Moins de 300 mots. Un seul CTA. Aucun mot banni.

Beaucoup de bons skills mélangent les deux — une procédure qui s'appuie sur des connaissances — mais sache toujours lequel domine. Si tu n'arrives pas à écrire les « Étapes », c'est probablement un skill de référence qui s'ignore : sépare la connaissance (référence) de l'action (tâche), et fais référencer l'une par l'autre. C'est exactement ce qu'on a fait au chapitre 4 avec brand-voice.md.

Les « commandes secrètes » : la vérité derrière le mythe

Tu as peut-être croisé ces visuels viraux : « les codes secrets de Claude — /godmode, /10x, /devil… ». Mettons les choses au clair : ce ne sont pas des commandes natives. Tape /devil dans une installation vierge, il ne se passera rien. Mais l'idée derrière le mythe est excellente, et tu as maintenant tout le bagage pour la comprendre : ce sont des commandes slash personnalisées que chacun peut créer dans .claude/commands/ — des prompts réutilisables auxquels on donne un nom.

Le mécanisme est d'une simplicité désarmante : un fichier Markdown .claude/commands/10x.md devient la commande /project:10x. Le contenu du fichier est le prompt envoyé à Claude, et le mot-clé $ARGUMENTS est remplacé par ce que tu tapes après la commande. Pas de YAML obligatoire, pas de structure imposée : c'est le plus léger des mécanismes d'extension.

# Créer le dossier des commandes du projet
mkdir -p .claude/commands

# Chaque fichier devient une commande :
#   .claude/commands/10x.md      -->  /project:10x
#   .claude/commands/devil.md    -->  /project:devil

# Les commandes personnelles vivent dans ton dossier utilisateur :
#   ~/.claude/commands/brief.md  -->  /user:brief

Construis ta bibliothèque : les 9 commandes de Léa

Voici la bibliothèque que Léa s'est constituée, fichier par fichier. Ne les recopie pas aveuglément : lis chaque prompt, comprends ce qu'il contraint, et adapte-le à ta pratique. /10x — son préféré pour muscler les accroches Twitter avant publication :

---
description: Réécrit un texte pour le rendre 10x plus percutant
---

Réécris ce texte pour le rendre 10x plus percutant :
- coupe chaque mot qui ne porte pas de sens
- commence par l'idée la plus forte, pas par le contexte
- une idée par phrase, voix active
- garde mon ton (brand-voice.md), n'invente aucun fait
- propose 3 variantes, de la plus sobre à la plus audacieuse

Texte : $ARGUMENTS

/brief — la réponse la plus courte possible, zéro remplissage. Léa l'utilise quand elle veut un fait, pas un exposé :

Réponds à la question suivante de la façon la plus courte possible.
Pas d'introduction, pas de mise en garde, pas de résumé final.
Si la réponse tient en un mot ou un chiffre, donne un mot ou un chiffre.

Question : $ARGUMENTS

/explainlikeim5 — l'explication ultra simple. Précieux quand un prestataire lui envoie du jargon technique :

Explique le concept suivant comme à un enfant de 5 ans :
- une analogie de la vie quotidienne
- des phrases courtes, aucun jargon
- termine par « en une phrase : ... »
- puis ajoute le niveau au-dessus : la même explication pour un adulte curieux, en 3 phrases

Concept : $ARGUMENTS

/devil — l'avocat du diable version sérieuse : un « steelman », c'est-à-dire la meilleure défense possible de la position opposée, pas une caricature. Léa le lance systématiquement avant de publier un post engagé sur l'écologie — mieux vaut découvrir l'objection dans son terminal que dans les commentaires :

---
description: Steelman de la position opposée, pour tester un argument avant publication
---

Joue l'avocat du diable sur la position suivante.
Construis le STEELMAN de la position opposée : sa version la plus forte,
la plus honnête, défendue par quelqu'un d'intelligent et de bonne foi.
- 3 contre-arguments solides, classés du plus fort au plus faible
- pour chacun : comment je pourrais y répondre honnêtement
- termine par : ce que je devrais nuancer dans ma position initiale

Ma position : $ARGUMENTS

/critique — trouve les failles et propose des améliorations concrètes, sans complaisance :

Critique le travail suivant sans aucune complaisance :
- 5 failles précises, classées par gravité (bloquant / important / détail)
- pour chaque faille : une correction concrète, pas un conseil vague
- ce qui est bon et qu'il faut garder (2 points maximum)
- verdict final : publiable en l'état, oui ou non, et pourquoi

Travail à critiquer : $ARGUMENTS

/pitch — le pitch de 30 secondes, client ou investisseur. Léa s'en sert pour préparer ses rendez-vous boutiques et ses demandes de financement :

Transforme ce qui suit en pitch de 30 secondes (75 mots maximum) :
- structure : problème vécu, solution, preuve, appel à l'action
- aucun superlatif vide (leader, unique, révolutionnaire)
- une phrase d'accroche qui crée la curiosité dès la première seconde
- donne 2 versions : une pour un client, une pour un investisseur

Sujet : $ARGUMENTS

/compare — l'analyse côte à côte en tableau, pour décider vite entre deux options (deux outils de programmation de posts, deux fournisseurs d'emballages…) :

Compare les options suivantes côte à côte :
- tableau : critères en lignes, options en colonnes
- critères imposés : coût, temps de mise en place, risques, réversibilité
- ajoute les critères spécifiques au sujet
- sous le tableau : ta recommandation en 2 phrases, avec la condition
  qui la ferait basculer vers l'autre option

Options : $ARGUMENTS

/scout — l'éclaireur : risques et angles morts d'un plan, avant de s'engager :

---
description: Détecte les risques et angles morts d'un plan avant engagement
---

Analyse ce plan comme un éclaireur prudent :
- 5 risques concrets, avec pour chacun : probabilité (faible/moyenne/forte),
  impact, et signal d'alerte précoce à surveiller
- 3 angles morts : les questions que je ne me pose pas et que je devrais
- le scénario d'échec le plus probable, raconté en 3 phrases
- les 2 protections les moins chères à mettre en place dès maintenant

Plan : $ARGUMENTS

/teacher — le mode mentor : Claude n'exécute pas, il enseigne, questionne et débat. Léa l'utilise pour monter en compétence au lieu de juste déléguer :

Passe en mode mentor sur le sujet suivant.
Ne fais PAS le travail à ma place :
- explique le concept clé en partant de ce que je sais probablement déjà
- pose-moi une question à la fois pour vérifier ma compréhension
- quand je me trompe, ne donne pas la réponse : guide-moi vers elle
- termine la session par 3 points à retenir et un exercice à faire seule

Sujet : $ARGUMENTS

Commande slash ou skill : comment choisir ?

La question à se poser : « est-ce un coup de tampon ou un processus ? » Un coup de tampon — une transformation appliquée à un texte que tu fournis — fait une parfaite commande slash. Un processus — plusieurs étapes, des fichiers à lire et à écrire, des validations — mérite un skill. Et les deux se combinent : Léa lance /project:devil sur un brouillon produit par /post, puis /project:10x sur l'accroche retenue. La boîte à outils ne remplace pas l'usine ; elle l'équipe.

La routine de Léa, version outillée

Concrètement, voici à quoi ressemble désormais une publication engagée chez Léa : /post génère le brouillon dans sa voix ; /project:devil teste l'argument et révèle l'objection la plus forte ; elle nuance une phrase ; /project:10x propose trois accroches plus percutantes ; elle en choisit une ; le quality gate vérifie le tout ; publication. Quatre commandes, cinq minutes, et un post plus solide que ce qu'elle écrivait en une heure — parce que chaque maillon encode une expertise qu'elle n'a plus à mobiliser de tête.