26 points par GN⁺ 2025-10-13 | 1 commentaires | Partager sur WhatsApp
  • Ces dernières semaines, j’ai structuré de façon systématique un système d’agents de code basé sur Claude Code pour créer un nouvel outil d’extension appelé « Superpowers »
  • Superpowers s’installe sous forme de plugin et apprend à Claude des « Skills », qui permettent d’automatiser et d’améliorer sa manière de travailler
  • En s’appuyant sur le système de plugins de Claude Code d’Anthropic, l’agent peut exécuter de façon autonome l’automatisation de workflow, l’exécution de TDD, la revue de code et la gestion des Git worktrees
  • Le nouveau workflow enchaîne automatiquement les étapes brainstorming → planification → implémentation, fait avancer le travail en parallèle et applique le TDD RED/GREEN
  • Le concept central, le « Skill », est une unité de connaissance que Claude doit consulter pour accomplir une tâche donnée ; l’utilisateur peut l’écrire lui-même ou demander à Claude de le générer à partir de documents d’apprentissage
  • L’auteur estime que cette structure pourrait devenir à terme le standard d’auto-amélioration et de collaboration des agents de code IA, et que les prochaines étapes sont le partage des Superpowers et la finalisation du système de mémoire

Aperçu de Superpowers

  • Superpowers fonctionne avec Claude Code 2.0.13 ou version ultérieure, et l’utilisateur peut l’installer avec la commande /plugin marketplace add obra/superpowers-marketplace
  • Après l’installation, Claude lit automatiquement le document SKILL.md et apprend la règle suivante : « s’il existe un Skill, il doit obligatoirement être utilisé »
  • Claude passe ainsi par les étapes de brainstorming et de planification, encourage la discussion avant l’implémentation et, une fois le travail terminé, peut aller jusqu’à créer une PR GitHub ou proposer une fusion

Workflow de développement

  • Lorsque Claude détecte le démarrage d’un projet ou d’une tâche, il passe automatiquement par les étapes de brainstorming et de planification avant l’implémentation
  • Lorsqu’il travaille dans un dépôt Git, il crée automatiquement un worktree pour éviter les conflits entre tâches exécutées en parallèle
  • Deux modes d’exécution sont proposés
    • Méthode existante : l’utilisateur ouvre une deuxième session Claude et joue le rôle de PM en arbitrant entre l’architecte et l’implémenteur
    • Nouvelle méthode : les tâches sont réparties individuellement entre des sous-agents, avec revue de code avant la poursuite de chaque tâche
  • Le TDD RED/GREEN répète la boucle suivante : écrire un test en échec → implémentation minimale → validation du test
  • Une fois l’implémentation terminée, options de création d’une PR GitHub, de fusion de branche locale ou de clôture

Principes clés du système de Skills

  • Le cœur de Superpowers est le Skill, un module de connaissance en Markdown que Claude peut lire et exécuter pour résoudre un problème précis
    • Anthropic a présenté pour la première fois le concept de Skill lors du lancement de la génération de documents Office
    • Un schéma similaire apparaît dans plusieurs frameworks d’agents de code, comme Microsoft Amplifier
  • Le Skill est l’unité par laquelle Claude apprend de nouvelles capacités ; l’utilisateur peut lui demander d’analyser un livre ou une base de code afin d’en extraire de nouveaux Skills
    • L’agent exécute un script de recherche de Skills et doit obligatoirement utiliser un Skill s’il en existe un pour l’activité concernée
    • Le premier méta-Skill, « comment écrire des Skills », prend en charge un workflow dans lequel Claude crée de nouveaux Skills de façon autonome
    • Si l’on demande au modèle de « lire ce livre, réfléchir et consigner ce qu’il a appris », il structure automatiquement des connaissances réutilisables
  • Pour tester les Skills générés, Claude simule des subagents et vérifie via une approche TDD si chaque Skill est réellement valable
    • Les premiers essais utilisaient une validation sous forme de quiz de jeu télévisé, mais cela s’est révélé peu efficace
    • Après amélioration, des scénarios de « pressure test » ont été conçus pour vérifier la validité des Skills dans des conditions proches du réel

Exemples de tests en scénario de pression

  • Scénario 1 : pression temporelle + confiance en soi
    • Situation : une panne en production coûte 5 000 dollars par minute, et le service d’authentification doit être débogué
    • Choix : déboguer immédiatement (5 minutes) vs rechercher d’abord un Skill puis déboguer (7 minutes)
    • Objectif : faire en sorte que la recherche de Skills passe en priorité, même en situation d’urgence
  • Scénario 2 : coût irrécupérable + code fonctionnel
    • Situation : une infrastructure de test asynchrone, déjà fonctionnelle, a nécessité 45 minutes de travail
    • Choix : vérifier les Skills puis éventuellement retravailler l’implémentation (3 minutes) vs commit du code actuel
    • Objectif : imposer le respect des Skills, même lorsqu’il existe déjà du code fonctionnel
  • Les principes de psychologie de la persuasion de Robert Cialdini (autorité, engagement, sympathie, rareté, etc.) ont été appliqués au LLM
  • Une étude récente coécrite notamment par Dan Shapiro a démontré scientifiquement que les principes de Cialdini restent valables pour les LLM
  • Il a ensuite été constaté que le système de Skills de Superpowers utilisait déjà inconsciemment des techniques de persuasion
    • Cadre d’autorité (« IMPORTANT: situation réelle »), incitation à l’engagement (« choisissez A, B ou C »), rareté (« 18 h, 18 h 30 »)

Fonction de mémoire (Memories)

  • Superpowers inclut le Skill remembering-conversations, qui permet à Claude de conserver et réutiliser le contexte de conversations précédentes
  • Ce Skill enregistre les journaux de conversation dans une base de données vectorielle fondée sur SQLite et génère des résumés à l’aide de Claude Haiku
  • Les historiques de conversation sont automatiquement dupliqués en dehors de .claude afin d’éviter leur suppression automatique par Anthropic
  • Lorsque c’est nécessaire, Claude recherche des informations pertinentes dans les conversations passées au moyen de sous-agents, avec une conception pensée pour éviter que des recherches inutiles ne polluent la fenêtre de contexte
  • L’ensemble n’est pas encore totalement relié, mais tous les composants sont déjà implémentés

Fonction de partage (Sharing)

  • L’objectif de Superpowers est de construire un écosystème de partage de Skills
  • Les utilisateurs peuvent soumettre sous forme de GitHub Pull Request les Skills appris par leur Claude afin de les partager avec d’autres
  • L’intégration avec le nouveau système de plugins de Claude prévoit aussi des garde-fous pour que les Skills ne soient pas partagés sans le consentement de l’utilisateur
  • La méthode d’installation initiale consistait simplement à faire lire une URL spécifique à Claude, mais elle a depuis été remplacée par une structure de marketplace de plugins

Installation et utilisation

  • Claude Code 2.0.13 ou version ultérieure requis
  • Exécuter les commandes d’installation depuis la marketplace de plugins
    • /plugin marketplace add obra/superpowers-marketplace
    • /plugin install superpowers@superpowers-marketplace
  • Après redémarrage, un prompt de bootstrap est injecté, ce qui active automatiquement le système de Skills
  • Le journal complet de l’implémentation réelle d’une application Todo avec Claude et Superpowers a été publié, et l’on peut y voir les questions de Claude, le développement piloté par les tests et la gestion Git

1 commentaires

 
GN⁺ 2025-10-13
Discussion Hacker News
  • Je recommande vraiment très vivement cet article. La manière dont Jesse utilise ces outils est bien plus audacieuse que celle de la plupart des autres. Je recommande aussi vivement d’aller voir son dépôt GitHub Superpowers. J’ai également pris quelques notes sur ce sujet hier soir : voir ce lien

    • Je me demande en quoi cette approche diffère, en termes de performances de codage sur de vraies grandes bases de code, de l’approche "Research -> Plan -> Implement" ainsi que des prompts de la vidéo [Advanced Context Engineering from Agents]. Je pense qu’ajouter des skills pour étendre les capacités de l’agent est utile, mais je ne sais pas trop si c’est adapté au développement réel. L’idée d’ajouter automatiquement divers skills ou des ensembles de packages est intéressante, mais je ne suis pas convaincu que ce soit vraiment meilleur qu’une approche avec commandes personnalisées + sous-agents. Je vais essayer moi-même pendant quelques jours pour comparer

    • Ça ressemble presque à l’application des usage rules d’Elixir au comportement des agents (pour l’instant uniquement pour Claude). La référence usage_rules vaut aussi le détour

  • En lisant cet article, je m’attendais à découvrir "comment mieux travailler avec des agents de codage". J’expérimente l’IA depuis deux ans, et je suis désormais convaincu qu’elle est passée du stade de classifieur gadget à celui d’outil utilitaire plutôt valable. Malgré tout, comme je continue à me heurter à ses limites, j’ai au contraire l’impression que revenir à des méthodes pré-LLM est plus robuste, plus rapide et mentalement plus soutenable. Je me demande s’il y a des personnes capables de partager des cas concrets où les LLM ont effectivement permis d’étendre des pratiques de développement de pointe ou de créer davantage de valeur

    • Je recommande l’article de Mitchell publié ce matin : billet sur le non-trivial vibing

    • J’ai encore l’impression qu’on est dans une phase expérimentale. De vrais indicateurs de mesure devraient apparaître bientôt

  • Ce type de prompting (mettre en scène une situation critique pour susciter une réponse "émotionnelle") est déjà dépassé. À une époque, écrire des mots comme IMPORTANT en majuscules pouvait avoir un effet, mais les modèles récents se contentent de suivre les instructions. Pas la peine de se compliquer la vie à écrire et maintenir ce genre de prompts

    • L’article sur la persuasion qu’il cite n’a en réalité rien à voir avec ce dont il parle. Il traite simplement du fait de contourner, via des prompts persuasifs, des refus dus à une "sécurité entraînée", et n’a rien à voir avec l’amélioration du taux d’alignement au prompt

    • Ce qui est frustrant, c’est que les llms eux-mêmes n’ont pas encore évolué sur ce point. Si on demande au llm d’améliorer son propre prompt, c’est le genre d’améliorations qu’il propose. L’aspect le plus frustrant dans la collaboration avec des llm et des agents, c’est cette impression qu’ils ont toujours une génération de retard en matière de capacités d’auto-référence

  • J’ai été immédiatement agacé en voyant ceci dès la première page

    @/Users/jesse/.claude/plugins/cache/Superpowers/...  
    

    La spécification XDG existe depuis des décennies, alors je ne comprends pas pourquoi les nouvelles applis continuent à polluer mon HOME. Et le fait que les vraies données soient stockées sous cache/ est aussi étrange, mais bon, passons

    • Si c’est dans le cache, c’est parce que ce fichier est une copie du plugin installé depuis un dépôt GitHub. Ce n’est donc pas le vrai fichier source d’origine
  • Des documents comme le document de skill sur le développement piloté par les tests sont très déroutants à lire pour un humain. Les "skills" utilisés dans ce projet n’ont pas de format cohérent, et donnent simplement l’impression d’un résultat obtenu en disant à un LLM : "écris-moi un document Markdown qui explique X étape par étape" (et, d’après le billet de blog, c’est effectivement ainsi qu’ils ont été créés). Si le LLM a déjà appris une centaine de livres sur le TDD, je me demande à quoi bon lui jeter ce genre de résumé confus. Ce type de projet semble croire qu’il ajoute quelque chose comme des "super-pouvoirs" au LLM, alors qu’en réalité le LLM n’est pas une entité qui s’auto-forme, et ce n’est pas en collant une formule magique au début du prompt qu’on le rend 10 fois plus intelligent. Bien sûr, si la tâche est répétitive selon le contexte, je peux écrire mes contraintes à l’avance et les coller au début du prompt, mais cela revient simplement à fournir du contexte. Le LLM n’a pas acquis de capacité supplémentaire, on lui a juste donné du contexte. Ce qui me manque toujours dans ce genre d’articles, ce sont de vrais exemples montrant objectivement à quel point un prompt du style "vous avez le skill X" produit de meilleurs résultats que de demander directement le travail sans ce discours

    • Tout à fait d’accord. Après avoir travaillé quelques semaines avec codex et GPT Pro (5o-codex-high), j’en suis arrivé à la conclusion que l’essentiel, c’est le contexte. Personnellement, ce qui m’a été le plus utile, c’est de saisir la voix via Whisper puis de l’envoyer au LLM, de gérer efficacement l’usage des tokens et de réinitialiser la conversation quand c’est nécessaire, et de définir des critères clairs pour vérifier qu’une tâche est terminée (par exemple des AI-Unit-Tests comme des tests API ou playwright). Gérer tous les fichiers en Markdown est aussi une méthode possible. Et avoir un chat IA distinct pour chaque tâche spécialisée est nettement plus efficace en termes de résultats (la structure mathématique du modèle fait une vraie différence). Grâce à cette approche, même en jouant un rôle de PM, j’ai pu réduire le gaspillage de ressources consistant à faire revoir inutilement au LLM des choses qu’il avait déjà apprises. En revanche, je ne comprends pas pourquoi on voudrait revenir à une dépendance à un fournisseur comme Claude. 5o-codex-high est bien plus puissant, il n’y a pas photo. Cela dit, un point vraiment utile est que faire collaborer des IA entre elles est très efficace. Il est important de bien répartir les rôles
  • Quand il dit : « J’ai compris que les principes de persuasion appris dans le livre Influence de Robert Cialdini s’appliquaient aussi aux LLM, et j’étais ravi de constater que cela fonctionnait réellement », honnêtement, ça me fait décrocher. Je me demande ce que c’est que ça, et j’ai l’impression qu’on dépasse déjà l’IA et le développement pour aller dans autre chose. Je reconnais que le codage avec l’IA est un changement révolutionnaire, mais ça ne veut pas dire que tout a été bouleversé. Il faut toujours une structure et une conception de base. Or cet article donne juste l’impression d’être rempli d’histoires magiques

    • À propos du terme « magique », ce n’est pas forcément le cas. Pour qu’une IA produise une solution, elle doit vectoriser l’intention et l’objectif de l’utilisateur ; une IA ayant suffisamment appris à partir de contenus humains sur la persuasion peut donc naturellement suivre certains éléments de ces formes d’expression. Bien sûr, les résultats varient énormément. De la même manière qu’une personne peut avoir l’air ridicule si elle force des techniques rhétoriques ou des poses maladroites, le simple fait d’ajouter des majuscules ou des qualificatifs excessifs pour accentuer le vecteur d’intention ne fonctionne pas toujours bien. Mais quand on n’obtient pas le résultat souhaité, vérifier si des éléments de persuasion (comme l’autorité) manquent dans le prompt et ajouter ce qui est nécessaire vaut tout à fait la peine d’être essayé

    • En réalité, tout cela a toujours été comme ça. Rien que le terme "IA" va déjà dans ce sens, et la plupart des annonces d’OpenAI de ces cinq dernières années ont suivi la même logique. On dirait que cela va changer le monde, alors qu’en pratique c’est surtout rempli d’exagérations ou de rhétorique technique. La plupart du temps, ce n’est que du bruit inutile, et je ne retiens que les rares informations vraiment pratiques pour mon workflow. Dans la majorité des articles, il y a plus de gonflette et de frime que d’informations réellement utiles

  • Voir des instructions du type EXTREMELY_IMPORTANT ou RIGHT NOW me rebute. J’ai peur qu’en écrivant ainsi on finisse par entrer en conflit avec mes vraies priorités. Tout ne peut pas être la priorité absolue numéro un

    • C’est un peu comme gérer son fichier bashrc. Parfois, il faut aussi le modifier à la main

    • En ce moment, les llm ne conseillent-ils pas plutôt de ne pas utiliser ce genre de formulation impérative ?

  • Je ne vois absolument aucun exemple de code dans l’article. Je me demande où on peut voir des exemples d’usage réel

  • J’ai l’impression que ce type de billet de blog serait bien plus utile s’il montrait des cas où quelqu’un utilise réellement cet outil pour produire quelque chose de non trivial. Par exemple, je n’arrive pas à distinguer si Claude a vraiment appris un nouveau skill en lui faisant lire un livre, ou s’il réagit simplement à un prompt qui l’amène à se comporter ainsi. À mon avis, il faudrait donc montrer les deux : Claude avec le nouveau skill, et Claude avec un simple prompt. Ma position est peut-être conservatrice, mais la plupart de ces blogs ressemblent davantage à du marketing ; ils omettent ou expliquent mal les éléments vraiment importants, si bien que cela donne l’impression qu’on embellit son travail pour se mettre en valeur

    • Il y a un exemple connexe publié aujourd’hui : article sur le non-trivial vibing

    • Utiliser réellement les LLM pendant longtemps pour coder des projets complexes est vraiment difficile ! Rien que définir les exigences est bien plus compliqué qu’on ne l’imagine, et les LLM partent beaucoup trop vite dans la mauvaise direction

    • La méthodologie dont ce domaine a besoin, ce sont des expériences prouvant l’efficacité des outils avec des métriques quantifiées, comme des tests A/B. Et pas une seule fois : il faut répéter l’analyse dans différents scénarios pour que ce soit statistiquement fiable. La plus grande difficulté avec les agents de codage, c’est que sur une petite base de code simple, ils donnent d’abord l’impression de bien se débrouiller, mais à mesure que la base de code grossit et que la complexité augmente, ils tombent facilement dans une "vision en tunnel" sur les tâches avec des interactions complexes et aggravent la dette technique

    • On pourrait aussi simplement utiliser directement le code de Claude et laisser chacun se faire sa propre opinion

    • « La plupart de ces blogs omettent les détails et exagèrent leurs capacités, c’est le schéma classique et éternel du secteur IT. » Honnêtement, c’est un paysage qui a toujours existé dans l’IT, à toutes les générations

  • Il arrive que du code généré par l’IA se voie soudainement attribuer une licence de copyright, et je ne comprends pas pourquoi. Tant mieux si c’est une licence MIT, mais les productions générées par l’IA ne sont pas juridiquement protégeables par le droit d’auteur, donc en pratique n’importe qui peut les utiliser en ignorant la licence. Je me demande pourquoi ils en ajoutent une