Claude Code mods : c'est quoi, comment créer le tien, et 13 mods à copier

Avant de commencer : la bonne version, le bon endroit

Dans le terminal, tape claude --version. Il te faut la 2.1.287 ou plus. Sinon, claude update.

Dans l'application Claude (onglet Code), tape /status : les mods fonctionnent à partir de la 2.1.286.

Les mods sont activés par défaut. Tape /plugin : la liste affiche les mods intégrés et, plus tard, les tiens, avec une ligne du type « 1 mod active ».

Terminal (y compris le terminal de ton éditeur, JetBrains). Tout fonctionne : les mods agissent et dessinent.

Application Claude, onglet Code. Tout fonctionne aussi, sauf les éléments réservés au terminal (les graphiques en points). Pas dans une session WSL.

Extension VS Code, panneau de chat. Les mods agissent mais ne dessinent pas : un tableau de bord n'apparaîtra pas.

Claude Code sur le web. Les mods agissent pour les plugins qui atteignent le cloud, sans rien dessiner.

Créer un mod en le décrivant

Claude écrit le mod dans ~/.claude/dev-mods/, dans un sous-dossier au nom de ta session. Pas de Node.js, pas de compilation : des fichiers JavaScript ou TypeScript que Claude Code charge tel quel.

Au premier fichier enregistré, Claude Code te demande si tu veux activer le rechargement à chaud pour la session : Enable for this session. À partir de là, chaque modification du mod s'applique tout de suite.

Le mod ne se charge qu'après ton accord, et seulement dans un dossier que tu as déclaré de confiance. Teste-le, demande des retouches, Claude ajuste.

Les mods de développement sont nettoyés avec le reste de tes sessions au bout d'un mois (le réglage cleanupPeriodDays). Quand il te plaît, copie le dossier à un endroit durable et charge-le avec claude --plugin-dir ./mon-mod.

Je veux un mod Claude Code. Avant d'écrire du code :
1. Reformule en trois lignes ce que le mod fait, quand
   il se déclenche et ce qu'il affiche.
2. Dis-moi quels événements et quelles fonctions de
   l'API des mods tu vas utiliser, et ce que le mod ne
   touchera jamais (fichiers, réseau, autres sessions).
3. Attends mon OK, puis écris le mod avec ses tests.
4. Montre-moi le code avant que je l'active, et dis-moi
   comment le désactiver.
Le mod : [décris-le ici en deux phrases]

Les trois mods de la vidéo

Une session planifie, l'autre construit, et elles se passent le travail. La messagerie entre sessions existe déjà sans mod : depuis la 2.1.224, tu peux demander à Claude d'envoyer un message à une autre de tes sessions sur la même machine (le message passe en local, jamais par les serveurs d'Anthropic, et ne contient ni ton historique ni tes fichiers). Le mod rend ça automatique : une commande, un résumé, et l'autre session le reçoit en plein travail.

Crée un mod « relais » entre mes sessions Claude Code.
Quand je tape /relais suivi du nom ou de l'identifiant
d'une autre session, puis d'un message, résume ce qu'on
a décidé dans cette session en dix lignes maximum et
envoie ce résumé à l'autre session, comme le ferait
l'outil SendMessage. Côté réception, affiche le message
au-dessus du prompt avec le nom de la session qui
l'envoie. Un message reçu ne vaut jamais accord :
Claude le lit, il n'exécute rien tout seul.

Un mod intercepte chaque requête avant qu'elle parte au modèle, et peut l'envoyer à un autre modèle. Les petites questions partent sur Haiku, le modèle le moins cher, les gros travaux restent sur Opus : tes limites arrêtent de fondre bêtement. Le mod affiche le modèle qui a répondu, parce que la documentation ne donne pas d'exemple officiel d'aiguillage : c'est toi qui fixes la règle, et Haiku répond moins bien. Commence sur des tâches sans enjeu.

Crée un mod « routeur ». À chaque requête envoyée au
modèle, si ma demande est une question courte (moins
de 40 mots, sans bloc de code, sans chemin de fichier,
sans demande de modification), envoie-la à haiku ;
sinon ne change rien. Les sous-agents ne sont pas
concernés. Affiche au-dessus du prompt le modèle qui a
répondu au dernier tour, pour que je vérifie.
/routeur off coupe l'aiguillage pour la session.

Un panneau à côté du chat : tes agents, ce qu'ils font, où ils en sont, et une jauge de tes limites. Tout est documenté : un mod peut ouvrir un panneau, lister les sous-agents de la session avec leur état, et lire l'usage (contexte en pourcentage, limites avec leur heure de remise à zéro). Dans le terminal, le panneau se place à droite si la fenêtre est large (144 colonnes au moins la première fois), sinon au-dessus du prompt. Dans l'application Claude, il s'ouvre à côté du chat.

Crée un mod « tableau de bord » : un panneau à côté du
chat, ouvert par /bord, avec trois blocs :
1. mes sous-agents, chacun avec son nom, son état (en
   attente, en cours, terminé, échoué) et depuis
   combien de temps ;
2. une jauge de mon contexte (pourcentage utilisé) ;
3. une jauge de mes limites d'utilisation (5 heures et
   semaine), avec l'heure de remise à zéro.
Rafraîchis après chaque tour et quand une limite bouge,
pas plus d'une fois par seconde.

Dix autres mods tout aussi puissants

Le mod retient les commandes destructrices et te montre ce qu'elles toucheraient avant de les laisser passer. C'est le principe de blast-radius, l'un des trois exemples publiés par Anthropic.

Crée un mod « rayon d'action ». Avant d'exécuter une
commande shell qui supprime en masse (rm -rf, del /s),
réécrit l'historique git (push --force, reset --hard)
ou exécute un script téléchargé (curl ... | sh),
mets-la en attente et montre-moi ce qu'elle toucherait :
fichiers concernés, branche, dépôt distant. Je valide
avec un bouton, ou je refuse. Ne bloque rien d'autre.

Aucun commit, push ou merge sans ton accord explicite, à chaque fois. Indispensable si tu laisses Claude travailler seul sur un dépôt partagé.

Crée un mod « verrou git » : aucun git commit, git push,
git merge ou git rebase ne part sans mon accord
explicite. Avant chaque commande de ce type, affiche la
commande complète et le résumé des fichiers concernés,
avec deux boutons : Autoriser une fois, Refuser.
Rien n'est mémorisé d'une fois sur l'autre.

Les clés, mots de passe et adresses qui traînent dans tes fichiers ne partent plus au modèle : le mod les remplace par des marqueurs avant l'envoi, et les remet dans ce que Claude exécute. Un mod peut réécrire les prompts et les appels d'outils, c'est exactement ce qu'il fait ici.

Crée un mod « filtre à secrets ». Avant qu'un prompt ou
un résultat d'outil parte au modèle, remplace les clés
d'API, mots de passe, jetons, adresses e-mail et
adresses IP par des marqueurs stables ([CLE_1],
[EMAIL_1]...) et garde la table de correspondance en
mémoire de session, jamais dans un fichier. Remets les
vraies valeurs dans ce que Claude écrit ou exécute.
Affiche au-dessus du prompt combien de secrets sont
masqués.

Pour filmer une démo sans flouter au montage : le mod masque à l'écran les clés, e-mails et noms de dossiers, sans rien changer à ce que Claude voit. C'est le cas d'usage qu'Anthropic a montré en présentant les mods.

Crée un mod « mode enregistrement », activé par /demo.
Tant qu'il est actif, masque à l'écran (pas dans ce qui
part au modèle) les clés d'API, jetons, e-mails,
numéros de téléphone, noms de dossiers utilisateurs et
tout ce que je liste dans ~/.claude/demo-masques.txt.
Affiche un bandeau « DEMO » au-dessus du prompt.
/demo off l'arrête.

Un mod reçoit un événement quand l'usage change, et connaît tes limites avec leur heure de remise à zéro. À 80 % il prévient, à 95 % il retient les appels d'outils jusqu'à ton accord : fini la limite atteinte au milieu d'une tâche.

Crée un mod « alerte budget ». Surveille mes limites
d'utilisation (5 heures et semaine). À 80 %, affiche un
avertissement au-dessus du prompt avec l'heure de
remise à zéro. À 95 %, mets en attente tout nouvel
appel d'outil et demande-moi, avec un bouton, si je
veux continuer quand même. Les seuils se changent avec
/budget 70 90.

Quand le contexte se remplit, le mod écrit une note de reprise dans ton projet, objectif, fait, reste, décisions, et te dit de repartir sur une session neuve. Tu perds moins qu'en laissant la compaction résumer à ta place.

Crée un mod « passage de relais ». Quand mon contexte
dépasse 70 %, écris dans le projet un fichier
docs/reprise.md avec : l'objectif de la session, ce qui
est fait, ce qui reste, les décisions prises et les
fichiers touchés. Puis affiche au-dessus du prompt :
« contexte à X %, reprise écrite, ouvre une nouvelle
session et donne-lui docs/reprise.md ». Mets le
fichier à jour à chaque tour tant que je reste.

Le pendant du routeur pour les sous-agents : quand l'un démarre, le mod choisit son modèle selon son rôle. L'exploration sur Haiku, la relecture sur Opus. Les appels passent sur ton abonnement comme d'habitude.

Crée un mod « un modèle par rôle ». Quand un sous-agent
démarre : exploration et recherche dans le code sur
haiku ; écriture de code sur sonnet ; relecture et
revue sur opus. Tout autre rôle garde le modèle prévu.
Note dans le journal de la session le modèle choisi
pour chaque sous-agent, et laisse-moi changer la règle
avec /roles.

Trois lignes toujours à jour dans un panneau : l'objectif, ce qui vient d'être fait, la suite. Le mod peut faire ses propres petites requêtes à un modèle (ici Haiku) pour rédiger le résumé, sans toucher à ta conversation.

Crée un mod « où j'en suis » : un panneau ouvert par
/point, mis à jour à la fin de chaque tour, avec trois
lignes : l'objectif de la session, ce que Claude vient
de faire, la prochaine étape. Pour rédiger ces trois
lignes, fais une petite requête à haiku à partir des
derniers échanges, sans envoyer les fichiers.

Le classique du vibe coding : un test rouge, et Claude « corrige » le test. Le mod compare le fichier avant et après chaque modification et bloque tout ce qui affaiblit une vérification.

Crée un mod « tests intouchables ». Quand Claude modifie
un fichier de test (*.test.*, *.spec.*, dossiers tests/
ou __tests__/), compare avant et après : si une
assertion disparaît, si un test passe en skip ou si
une condition attendue est assouplie, bloque la
modification et explique pourquoi. Je peux autoriser
au cas par cas avec un bouton.

Après un gros tour, tu parcours les modifications une par une, avec le pourquoi. C'est replay-theater, le deuxième exemple publié par Anthropic, que tu peux aussi installer tel quel (ci-dessous).

Crée un mod « rejoue ». Enregistre chaque modification
de fichier faite pendant un tour (fichier, lignes
avant, lignes après). /rejoue ouvre un panneau qui les
parcourt une par une, avec Précédent et Suivant, le
diff coloré et le pourquoi, tiré du message de Claude
à ce moment-là. Rien n'est écrit sur le disque.

Installer un mod existant

Les exemples d'Anthropic. Trois mods publiés tels quels, sans support, dans le dépôt claude-code-playground : token-weather (ton contexte en bulletin météo au-dessus du prompt), blast-radius (retient les commandes risquées) et replay-theater (/replay rejoue les modifications). Clone le dépôt, va dans claude-code/mods, puis claude --plugin-dir ./token-weather pour l'essayer une session.

L'annuaire de plugins, dans /plugin. Des dizaines de mods communautaires y sont listés (jauges d'usage, panneaux, garde-fous). Chaque fiche indique si Anthropic ou un partenaire a relu le code ; la plupart ne le sont pas. Lis la fiche et le dépôt avant d'installer.

Les annuaires tiers. Des sites comme claude-mods.com recensent les mods de la communauté. Ce sont des projets personnels : même règle, on lit le code, et on préfère le faire écrire par Claude quand c'est simple.