Superpowers Symfony goes subagents: the plugin that delegates on its own

I wrote a piece on Superpowers Symfony back when it was 49 skills neatly filed in folders. A Claude Code plugin that injects expert Symfony context, that’s it.

I reopened the repo this week. It changed shape.

We’re now at 44 skills, 7 specialized subagents, 13 slash commands, all pinned to Symfony 7.4 LTS and 8.x. And the real change isn’t the skill count. It’s that one word: subagents.

Because a skill is context you load. A subagent is a thing that decides and executes in your place. That’s not the same promise, and it’s not the same risk.

What actually changed

Before, the model was simple: you say “load the symfony:doctrine-relations skill”, Claude reads the context, its answers get good at Doctrine. You keep your hand on every step.

Now, on top of the skills, the plugin ships dedicated agents that auto-delegate based on context:

• doctrine-architect for the persistence layer;
• api-platform-builder for API Platform v4 resources;
• symfony-tdd-coach for the RED-GREEN-REFACTOR cycle;
• symfony-reviewer to read the diff;
• and a few others.

The idea: you ask for something, and the plugin routes the task to the right agent without you naming it. On paper, that’s exactly what we want. In real life, that’s where it gets decided.

Here’s the thing: delegation is a double-edged knife

A subagent that works “on its own” means two things at once.

The good one: you stop micro-managing. You no longer load the right skill at the right moment by hand, the orchestration does it. On a slightly wide Symfony task — say, standing up an API Platform resource with its DTOs, its filters, its state provider and the matching tests — having an agent that knows the sequence is a real mental-load win.

The less good one: a subagent builds its own context, makes decisions, and hands you a result. If you don’t see what it decided along the way, you get a diff you have to review blind. And reviewing Doctrine code blind, generated by an agent that “handled” the relations and the cascades, honestly, is sometimes slower than writing it yourself.

Fine. So the question isn’t “are subagents better than skills”. The question is: can I still see what’s going on?

What ages fast vs what ages slow

Where the plugin is 100% right is versioning.

Framework context rots. A generalist model will hand you API Platform v3, Doctrine ORM 2, attributes that have since moved. The plugin is explicitly pinned to Symfony 7.4 LTS / 8.x, API Platform v4, Doctrine ORM 3, with legacy support for 6.4 LTS. That’s value with a shelf life — so value a maintainer has to keep fresh, and that’s exactly the work you don’t want to do yourself.

Subagents, on the other hand, are a bet on orchestration. That’s more brittle. A doctrine-architect agent that picks the wrong fetch mode on a big relation, you pay for it in N+1 queries in production, not in a compile error. Versioning protects you from stale context. Auto-delegation asks you to trust more, not less.

What I’d check before turning it on everywhere

I don’t wire Symfony subagents onto a real repo without a few guardrails. In order:

1. Delegation legibility. Do I see which agent made which decision, or does it land on me as one opaque diff? If it’s opaque, I shrink the scope.
2. Sensitive zones stay manual. Doctrine migrations, security (voters, rate limiting), anything touching production data: I keep my hand on it. A subagent that generates a migration, I read it line by line, no exception.
3. TDD as a net. The symfony-tdd-coach makes sense precisely because the test is your proof. An agent that writes the failing test first, then the code, is verifiable. An agent that “does the feature” without a test is a gamble.
4. The reviewer isn’t a rubber stamp. symfony-reviewer can pre-chew the review, but it doesn’t sign off for you. The review burden doesn’t vanish, it moves.

The install changed too

Small but practical detail: it now goes through the Claude Code marketplace.

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

Or project-scoped via .claude/settings.json if you want to pin it per repo — which I recommend on a team, so everyone runs the same version of the subagents instead of each their own.

My read

The move to subagents is the same shift I see everywhere right now: we stop selling “a better assistant” and start selling “a team that organizes itself.” It lines up with what Claude Code is doing on its side with agent teams.

Is it better? It hinges on one thing: does delegation stay legible and stoppable. A Symfony subagent that shows its reasoning and that you can halt is a net win. A subagent that “handles Doctrine for you” as a black box is just technical debt with a nice name.

The project sits at 170++ stars, MIT-licensed, and it has the right instinct: version the context. What’s left to see is whether auto-delegation holds up on real repos, or whether we’ll all end up renaming our agents by hand like before. I’d bet on a middle ground: subagents for the scaffolding, humans for anything that leaves a trace in production.

Sources

• GitHub — MakFly/superpowers-symfony
• Claude Code — Plugins & marketplace documentation