AIDive

Pack vidéo

Superpowers pour Claude Code : tableau de verdict, sources, checklist et pour aller loin

9 min de lecture

TL;DR

  • Superpowers est un process, pas une boîte à outils : quatorze skills en markdown qui conditionnent chaque feature à une session de brainstorming, un plan écrit et une chaîne de subagents neufs, tous relus.
  • Installez-le si vos sessions Claude Code construisent des features qui prennent des heures. Passez votre chemin si vous faites surtout des scripts jetables et des correctifs de deux lignes : le contrôle d'entrée tourne à chaque tâche et ne se désactive jamais.
  • L'argument tokens est réel, mais il vient d'une seule section d'un seul skill : Model Selection. L'orchestrateur attribue le modèle le moins cher capable de tenir le rôle, donc le modèle coûteux ne touche qu'à l'architecture et à la revue finale de la branche.
  • Le dépôt est en bonne santé : 280,597 stars, 25,138 forks, 681 commits sur main, release v6.3.0 le 2026-08-12, créé le 2025-10-09.
  • La plainte à l'origine de la vidéo, des stats d'usage à 1 à 3 pour cent, n'est pas un bug : cela veut dire que les skills ne se déclenchent jamais sur votre travail, donc vous payez le gate sans rien recevoir en retour.
  • La voie du milieu tient en une phrase dans votre prompt : dites à l'agent de sauter le process sur les petits correctifs, et laissez brainstorming seul tourner quelques jours avant d'adopter le reste.

Ce que disent les sources

Les chiffres du dépôt ont été relevés le 2026-09-02 : 280,597 stars, 25,138 forks et 681 commits sur la branche main, avec le dernier commit sur main daté du 2026-08-12 (v6.3.0) et un push plus tardif le 2026-08-31 sur une branche autre que main s1. L'onglet Issues affichait 125 issues ouvertes ce jour-là ; le chiffre de 350 donné par l'API inclut les 225 pull requests ouvertes, donc citez l'onglet, pas l'API, quand vous comparez à d'autres plugins s6. Le projet a été créé le 2025-10-09 et livre quatorze skills s2. Le post de lancement de l'auteur résume le pari en une ligne : les agents de code ne manquent pas de capacité, ils manquent de discipline, et cette discipline peut être distribuée sous forme de simples fichiers markdown que chacun peut lire, forker et modifier s5. Le plugin est listé sur la marketplace officielle, donc l'installation tient en une commande et les mises à jour suivent la marketplace s4.

Le point d'entrée est un skill que le hook de démarrage de session charge avant tout le reste. Il dit à l'agent que, au moindre doute sur l'applicabilité d'un skill, il doit le charger et vérifier, avant de répondre ou d'écrire du code. Cette règle est la source à la fois du bénéfice et du coût fixe s14.

Brainstorming s'ouvre sur un HARD-GATE : pas de code, pas de scaffolding, pas de skill d'implémentation tant que vous n'avez pas validé une intention explicite. Il range ensuite la demande dans l'un de trois chemins : spike, quand le résultat est une réponse plutôt que du code ; bounded, pour un petit changement dans un flux que le dépôt a déjà ; architectural, pour tout ce qui restructure le projet. L'agent annonce la classification pour que vous puissiez la contredire, et le cliquet ne va que dans un sens : une complexité cachée découverte en cours de route fait monter le chemin, jamais descendre s9.

Le skill d'écriture de plan demande un plan rédigé pour un développeur compétent qui ne connaît rien de votre codebase et, selon les mots du fichier, a un goût douteux. Le travail est découpé en tâches dont chaque étape prend de deux à cinq minutes : écrire le test qui échoue, le lancer pour le voir échouer, écrire le code minimal, relancer les tests, commit. Chaque tâche liste les fichiers exacts à créer ou modifier, jusqu'aux numéros de ligne, et le plan s'ouvre sur un en-tête obligatoire s10.

L'exécution relève du skill subagent-driven development : un subagent neuf par tâche, une revue après chaque tâche, une revue de toute la branche à la fin. La session principale arrête de coder et dispatche. Chaque subagent reçoit uniquement le contexte de sa tâche, jamais l'historique de votre session, ce qui garde votre propre fenêtre libre pour la coordination. Une fois que le subagent a implémenté, testé, commité et fait son auto-revue, l'orchestrateur lance une revue en deux temps, conformité à la spec d'abord, qualité du code ensuite, avec une place de relecteur réservée pour chaque tâche. Le fichier plafonne la boucle à cinq tours maximum par tâche s11. L'isolation du travail est déléguée à un skill de worktree, donc un plan ne tourne jamais sur votre checkout courant s13.

La section Model Selection commence par une règle : utilisez le modèle le moins capable qui peut tenir le rôle. Une tâche mécanique bien spécifiée touchant un ou deux fichiers va à un petit modèle ; quand le plan contient déjà le code à écrire, l'implémentation se réduit à de la transcription plus des tests, donc le palier le moins cher suffit. La coordination multi-fichiers et le debug vont à un modèle standard. L'architecture et la revue finale de la branche demandent le modèle le plus capable disponible. Deux détails comptent en pratique : nommez toujours le modèle explicitement au dispatch, et laissez l'orchestrateur évaluer la difficulté de chaque tâche avant de choisir s12. C'est le mécanisme qui rend le modèle coûteux abordable sur le plan Pro à vingt dollars : il ne travaille que sur les décisions qui le méritent.

Le gain en documentation est un effet de bord du process. Les specs et les plans ne sont pas des messages de chat qui disparaissent ; ce sont des fichiers markdown sauvegardés dans le dépôt et commités avec le travail, donc un relecteur lit plus tard pourquoi un changement a été fait, pas seulement ce qui a changé s3.

Le coût, lui, est celui que le dépôt ne met pas en avant. Le thread à l'origine de la vidéo rapporte des stats d'usage à 1 à 3 pour cent et demande quel est l'inconvénient au-delà de ne pas l'utiliser s7. La réponse dans les fichiers : brainstorming adapte sa cérémonie à la tâche mais ne saute jamais la validation humaine s9. Sur un correctif de deux lignes, vous répondez quand même à des questions de cadrage, approuvez un design de deux phrases et attendez le cycle complet. Les briefs de dispatch, les deux revues par tâche et le registre de suivi sont des tokens que vous payez à chaque fois, et cela se voit sur les plus petites tâches. Des stats d'usage basses signifient que les skills ne correspondent pas à votre travail, et c'est le vrai signal à lire.

Verdict selon l'usage

Votre usage de Claude Code Installer ? Pourquoi
Des features qui prennent des heures, plusieurs fichiers, une branche Oui Le cadrage évite de construire la mauvaise chose, les tâches courtes tiennent l'agent loin de la saturation du contexte, la sélection de modèle étire le quota, la doc sort du process
Mixte : des features certains jours, des correctifs la plupart du temps Oui, avec une règle de saut Gardez le gate pour les features, dites à l'agent dans le prompt de sauter le process sur les petits correctifs
Scripts jetables, typos de config, correctifs de deux lignes Non Le coût fixe du gate s'applique à des tâches qui n'en ont pas besoin
Curieux mais pas prêt à adopter toute la méthode Brainstorming seulement Il porte l'essentiel du gain ; les autres skills se raccrochent naturellement ensuite

À faire lundi

  • Installez depuis la marketplace officielle et ouvrez le cache du plugin : lisez une fois les quatorze fichiers SKILL.md, ils sont courts et c'est tout le produit.
  • Passez une vraie feature dans le gate de bout en bout : brainstorming, plan, dispatch des subagents, revue de branche. Jugez le process là-dessus, pas sur un correctif.
  • Vérifiez vos stats d'usage après une semaine. Sous quelques pour cent, les skills ne correspondent pas à votre travail : soit vos tâches sont trop petites, soit vous devez formuler vos demandes comme des features.
  • Ajoutez une règle de saut aux instructions de votre projet : sur les correctifs d'un seul fichier de quelques lignes, aller directement au changement, sans brainstorming.
  • Copiez l'échelle de Model Selection dans vos propres prompts de subagents même si vous abandonnez le plugin : nommez le modèle explicitement à chaque dispatch.
  • Commitez les specs et les plans que le plugin écrit au lieu de les supprimer ; ce sont votre trace de conception.
  • Comptez les issues ouvertes sur l'onglet Issues, pas à partir du chiffre de l'API, avant de comparer le projet à un autre plugin.

Pour aller plus loin

  • Lisez le post de lancement pour l'intention de design avant les fichiers de skills : il explique pourquoi la discipline est distribuée en markdown et non en code s5.
  • La section philosophy du README est la version courte de la méthode et l'endroit où vérifier si elle colle à votre façon de travailler s3.
  • La section skills library liste les quatorze skills avec une ligne d'objectif chacun ; c'est plus rapide que de parcourir le répertoire s16.
  • Les cinq tours maximum par tâche du skill subagent sont un arrêt dur à copier dans toute orchestration que vous écrivez à la main s11.
  • Un thread demande si ce type de plugin survit à des modèles plus forts ; ce qui survit, c'est le gate de cadrage et les plans commités, ce que les modèles absorbent, c'est la mécanique s19.
  • Un témoignage de limite d'usage hebdomadaire brûlée par la cérémonie d'orchestration est le contre-exemple à lire avant de l'adopter sur du petit travail s20.
  • La comparaison avec un autre jeu d'instructions montre le compromis : moins de skills mais plus stricts, contre un large catalogue de règles s18.
  • La liste des issues ouvertes est la lecture la plus rapide de ce qui casse aujourd'hui chez les autres utilisateurs s6.

Sources

FAQ

Superpowers économise-t-il des tokens ou en brûle-t-il ?

Les deux. Sur les features, la sélection de modèle envoie les tâches mécaniques vers de petits modèles et garde le modèle coûteux pour l'architecture et la revue de branche, donc le quota s'étire. Sur les petits correctifs, les briefs, les deux revues par tâche et le registre sont de l'overhead pur.

Que signifient des stats d'usage à 1 à 3 pour cent ?

Les skills ne se déclenchent que lorsqu'une situation leur correspond. Un chiffre bas veut dire que vos tâches ne sont pas des features au sens du plugin, donc vous payez le contrôle d'entrée sans jamais atteindre la partie qui rembourse.

Puis-je n'en garder qu'une partie ?

Oui. Brainstorming seul porte l'essentiel du gain, et l'échelle de Model Selection fonctionne dans n'importe quel prompt de subagent écrit à la main. Dites à l'agent de sauter le process sur les tout petits correctifs et vous gardez la main.