Superpowers Symfony passe aux subagents : le plugin qui délègue tout seul

J’avais écrit un article sur Superpowers Symfony quand c’était 49 skills bien rangés dans des dossiers. Un plugin Claude Code qui injecte du contexte Symfony expert, point.

J’ai rouvert le repo cette semaine. Il a changé de forme.

On est passé à 44 skills, 7 subagents spécialisés, 13 slash commands, le tout calé sur Symfony 7.4 LTS et 8.x. Et le vrai changement n’est pas le compteur de skills. C’est ce mot : subagents.

Parce qu’un skill, c’est du contexte que tu charges. Un subagent, c’est un truc qui décide et exécute à ta place. Ce n’est pas la même promesse, et ce n’est pas le même risque.

Ce qui a changé, concrètement

Avant, le modèle était simple : tu dis « charge le skill symfony:doctrine-relations », Claude lit le contexte, ses réponses deviennent bonnes pour Doctrine. Toi tu gardes la main sur chaque étape.

Maintenant, en plus des skills, le plugin embarque des agents dédiés qui s’auto-délèguent selon le contexte :

• doctrine-architect pour la couche persistance ;
• api-platform-builder pour les ressources API Platform v4 ;
• symfony-tdd-coach pour le cycle RED-GREEN-REFACTOR ;
• symfony-reviewer pour relire le diff ;
• et quelques autres.

Le principe : tu demandes un truc, et le plugin route la tâche vers l’agent qui va bien, sans que tu aies à le nommer. Sur le papier, c’est exactement ce qu’on veut. Dans la vraie vie, c’est là que ça se joue.

Le truc c’est que la délégation, c’est un couteau à double tranchant

Un subagent qui bosse « tout seul », ça veut dire deux choses en même temps.

La bonne : tu arrêtes de micro-manager. Tu ne charges plus le bon skill au bon moment à la main, l’orchestration le fait. Sur une tâche Symfony un peu large — genre monter une ressource API Platform avec ses DTO, ses filtres, son state provider et les tests qui vont avec — avoir un agent qui connaît la séquence, c’est un vrai gain de charge mentale.

La moins bonne : un subagent, ça fabrique son propre contexte, ça prend des décisions, et ça te rend un résultat. Si tu ne vois pas ce qu’il a décidé en chemin, tu récupères un diff que tu dois relire à l’aveugle. Et relire à l’aveugle du code Doctrine généré par un agent qui a « géré » les relations et les cascades, franchement, c’est parfois plus lent que de l’avoir écrit toi-même.

Bon. La question n’est donc pas « est-ce que les subagents sont mieux que les skills ». La question est : est-ce que je vois encore ce qui se passe ?

Ce qui vieillit vite vs ce qui vieillit lentement

Là où le plugin a raison à 100 %, c’est sur le versionnage.

Le contexte framework, ça pourrit. Un modèle généraliste va te ressortir de l’API Platform v3, du Doctrine ORM 2, des attributs qui ont bougé. Le plugin, lui, est explicitement calé sur Symfony 7.4 LTS / 8.x, API Platform v4, Doctrine ORM 3, avec un support legacy pour la 6.4 LTS. Ça, c’est de la valeur qui se périme — donc de la valeur qu’un mainteneur doit entretenir, et c’est précisément le travail que tu ne veux pas faire toi-même.

Les subagents, à l’inverse, c’est un pari sur l’orchestration. C’est plus fragile. Un agent doctrine-architect qui se trompe de fetch mode sur une grosse relation, tu le paies en requêtes N+1 en prod, pas en erreur de compilation. Le versionnage te protège d’un contexte périmé. L’auto-délégation, elle, te demande de faire plus confiance, pas moins.

Ce que je regarderais avant de l’activer partout

Je ne branche pas des subagents Symfony sur un vrai repo sans quelques garde-fous. Dans l’ordre :

1. La lisibilité de la délégation. Est-ce que je vois quel agent a pris quelle décision, ou est-ce que ça m’arrive comme un gros diff opaque ? Si c’est opaque, je réduis le périmètre.
2. Les zones sensibles restent manuelles. Migrations Doctrine, sécurité (voters, rate limiting), tout ce qui touche à la donnée en prod : je garde la main. Un subagent qui génère une migration, je la relis ligne par ligne, sans exception.
3. Le TDD comme filet. Le symfony-tdd-coach a du sens justement parce que le test est ta preuve. Un agent qui écrit d’abord le test qui échoue, puis le code, c’est vérifiable. Un agent qui « fait le feature » sans test, c’est un pari.
4. Le reviewer n’est pas un tampon. symfony-reviewer peut pré-mâcher la revue, mais il ne signe pas à ta place. La charge de review ne disparaît pas, elle se déplace.

L’install a changé aussi

Détail pratique mais qui compte : ça passe maintenant par le marketplace Claude Code.

/plugin marketplace add MakFly/superpowers-symfony
/plugin install superpowers-symfony@superpowers-symfony

Ou en scope projet via .claude/settings.json si tu veux le figer par repo — ce que je recommande en équipe, pour que tout le monde ait la même version des subagents et pas chacun la sienne.

Ma lecture

Le passage aux subagents, c’est la même bascule que je vois partout en ce moment : on arrête de vendre « un meilleur assistant » pour vendre « une équipe qui s’organise ». C’est cohérent avec ce que fait Claude Code de son côté avec les agent teams.

Est-ce que c’est mieux ? Ça dépend d’un seul truc : est-ce que la délégation reste lisible et coupable. Un subagent Symfony qui te montre son raisonnement et que tu peux arrêter, c’est un gain net. Un subagent qui « gère Doctrine pour toi » en boîte noire, c’est juste de la dette technique avec un joli nom.

Le projet est à 170++ stars, sous licence MIT, et il a le bon réflexe : versionner le contexte. Reste à voir si l’auto-délégation tient la route sur des repos réels, ou si on va tous finir par re-nommer nos agents à la main comme avant. Je pencherais pour un entre-deux : subagents pour l’échafaudage, humain pour tout ce qui laisse une trace en prod.

Sources

• GitHub — MakFly/superpowers-symfony
• Claude Code — Documentation plugins & marketplace