Everything Claude Code : 7 pièges du pack complet

Everything Claude Code est un dépôt open source sous licence MIT qui rassemble une configuration Claude Code complète : sous-agents, commandes, règles, skills, hooks et serveurs MCP, installables en un seul plugin. Le piège tient dans son nom. Installé entier, l'ensemble coûte plus de contexte qu'il n'en fait gagner. Le travail utile, c'est le tri.

Par où commencer cette semaine

Si tu n'en gardes que trois la première semaine, prends ceux-là, dans cet ordre. Une commande de planification, appelée avant chaque fonctionnalité, parce qu'elle change tout ce que l'agent fait ensuite. Un seul fichier de règles, celui sur la sécurité, parce que c'est la catégorie d'erreur que tu ne veux pas découvrir en production. Un sous-agent de revue, lancé après coup, jamais pendant. Installe-les à la main, en copiant les trois fichiers dans ~/.claude/, plutôt qu'en activant le plugin entier.

Le reste attend. Tu ajoutes un composant le jour où une session t'a coûté du temps qu'il aurait évité. Note la date à côté de son nom quand tu l'actives : au bout d'un mois, la liste te dira d'elle-même lesquels supprimer. Les sept pièges qui suivent expliquent pourquoi ce tri vaut plus que le dépôt lui-même.

Ce que contient vraiment Everything Claude Code

Le dépôt est publié par affaan-m et se présente comme un plugin Claude Code. Début septembre 2026, il embarque neuf sous-agents (planification, architecture, revue de code, revue sécurité, correction d'erreurs de build, tests end-to-end, entre autres), une dizaine de commandes slash, six fichiers de règles, neuf skills, des hooks de session et un fichier d'exemples de serveurs MCP.

Il y a deux façons de l'installer. En plugin, tu lances /plugin marketplace add affaan-m/everything-claude-code, puis /plugin install everything-claude-code@everything-claude-code. À la main, tu copies dans ~/.claude/ les fichiers qui t'intéressent. La deuxième méthode a l'air plus pénible. C'est pourtant celle qui fait gagner du temps, pour les sept raisons qui suivent.

“

Le dépôt s'appelle Everything, mais sa meilleure ligne de documentation dit de ne pas tout activer.

”

Les pièges à l'installation

1. Tout activer le premier jour

Tu installes le plugin, la sortie de Claude Code change, et tu es incapable de dire ce qui a changé. La raison est simple : neuf sous-agents, dix commandes, six fichiers de règles et une série de hooks entrent en service en même temps. Quand le résultat s'améliore, tu ne sais pas quel composant l'a produit. Quand il se dégrade, tu ne sais pas lequel retirer. Fais l'inverse : installe le plugin, puis n'utilise qu'une commande pendant une semaine, la planification avant chaque fonctionnalité par exemple. Tu ajoutes la suivante quand la première est devenue un réflexe.

2. Allumer tous les serveurs MCP

Tes sessions se compactent plus tôt qu'avant, et le modèle perd le début de la tâche. C'est mécanique : chaque serveur MCP injecte la définition de ses outils dans le contexte avant même que tu écrives quoi que ce soit. Le dépôt le dit lui-même, une fenêtre de 200k peut tomber à 70k quand trop d'outils sont actifs. Il donne aussi un ordre de grandeur, début septembre 2026 : vingt à trente serveurs configurés, moins de dix activés par projet, moins de quatre-vingts outils actifs. Configure donc large et active étroit, projet par projet, avec le réglage disabledMcpServers. Un serveur mérite sa place quand tu t'en sers dans la session en cours : l'accès à ta base, l'accès à ton déploiement, ou une boîte mail pilotable par API pour agents.

3. Copier les règles sans les relire

L'agent se met à écrire des tests pour un prototype que tu jetteras vendredi, et tu passes ta session à négocier avec ta propre configuration. Les fichiers de règles sont des consignes inconditionnelles, rechargées à chaque session. Celui sur les tests exige 80 % de couverture : bonne règle pour un produit en production, perte de temps sur un jetable. Surtout, une règle que tu ne fais pas respecter t'entraîne à ignorer tes propres règles. Garde une règle seulement si tu la ferais appliquer sur une pull request un dimanche soir. Supprime les autres, tu les remettras au besoin.

4. Cloner un fork au lieu de la source

Tu suis un tutoriel et les commandes ne correspondent pas à ce que tu as installé. Un dépôt populaire est recopié vite : plusieurs miroirs circulent, et leur README pointe parfois vers le dépôt d'origine tout en servant un contenu plus ancien. Les correctifs récents, comme la réécriture des scripts en Node pour Windows, n'arrivent pas au même rythme selon la copie. Avant de copier des fichiers, vérifie que la commande d'installation du README désigne bien le dépôt que tu es en train de lire.

Les pièges à l'usage

5. Déléguer à un sous-agent ce que tu vas relire ligne à ligne

Tu confies une modification à un sous-agent et tu reçois un résumé propre qui ne dit pas ce qui a été touché. Un sous-agent travaille dans son propre contexte et ne te renvoie qu'une synthèse ; le détail intermédiaire, lui, ne revient jamais. C'est excellent pour balayer un dépôt entier et remonter trois fichiers, et mauvais pour un changement que tu relirais toi-même. Un résumé que personne ne vérifie, c'est exactement le seuil où un agent IA gratuit casse. Réserve le sous-agent à ce qui lit beaucoup et rapporte peu, et garde la session principale pour le code que tu vas relire.

6. Répéter la même consigne dans trois fichiers

« Ne commite jamais de secret » figure dans ton CLAUDE.md, dans un fichier de règles et dans une skill, et le modèle continue à faire autre chose. La répétition coûte du contexte et dilue la hiérarchie des consignes ; ce qui porte un vrai signal, c'est ce qui est unique et propre à ton dépôt. Donne un seul domicile à chaque consigne : CLAUDE.md pour ce qui n'est vrai que dans ce projet, les règles pour ce qui est vrai partout, les skills pour les procédures chargées à la demande. C'est la même discipline que pour un CRM emailing, où tout dépend de qui détient la désinscription : une information, un seul propriétaire.

7. Ne jamais mesurer si la config aide

Tu as l'impression que c'est mieux, sans pouvoir le prouver. Une configuration déplace des probabilités, elle ne rend rien déterministe, et sans tâche répétable tu ne distingues pas une bonne règle d'un placebo. Donc tu gardes tout par défaut, et tu retombes sur le piège numéro 1. Garde plutôt sous la main une tâche réelle et rejouable, un bug déjà corrigé ou un refactor déjà fait. Lance-la avant d'ajouter un composant, puis après. Tu gardes le composant si la deuxième exécution demande moins de corrections de ta part. Le dépôt fournit des skills d'évaluation pour formaliser la boucle ; une tâche témoin suffit pour commencer. Une configuration se juge comme un prompt réutilisé, sur la durée. La comparaison de quatre méthodes de prompts ChatGPT donne le même verdict : ce sont les formats imposés qui survivent à la réutilisation.

FAQ

Everything Claude Code est-il gratuit ? Oui, sous licence MIT : tu peux l'utiliser, le modifier et le redistribuer. Le coût réel est ailleurs, dans le contexte consommé par les composants que tu actives à chaque session.

Faut-il l'installer en plugin ou copier les fichiers à la main ? Le plugin est plus rapide et te donne tout d'un coup, ce qui est précisément le piège numéro 1. La copie manuelle t'oblige à ouvrir chaque fichier avant de le poser dans ~/.claude/. Si tu débutes avec Claude Code, copie à la main : lire ces fichiers représente la moitié de la valeur du dépôt.

Est-ce que ça fonctionne sous Windows ? Oui. Les hooks et les scripts ont été réécrits en Node pour couvrir Windows, macOS et Linux, et le plugin détecte ton gestionnaire de paquets. Vérifie tout de même la copie que tu installes.

Combien de serveurs MCP garder actifs ? Le dépôt donne un ordre de grandeur : moins de dix serveurs activés par projet, moins de quatre-vingts outils au total. Il existe un test plus simple : si tu n'as pas utilisé un serveur dans tes trois dernières sessions, désactive-le pour ce projet.

Est-ce que ça remplace mon CLAUDE.md ? Non. Le dépôt fournit des exemples de CLAUDE.md, pas le tien. Ce fichier contient ce qui n'est vrai que dans ton projet : commandes de build, conventions, pièges connus. Tout ce qui serait vrai dans n'importe quel dépôt appartient aux règles.