Superpowers vs Matt Pocock's skills: two opposite bets on who runs your agent
· Mick Brzeziński
- AI agents
- Claude Code
- build in public
Matt Pocock’s agent-skills library hit 1.0. Jesse Vincent’s Superpowers is on 6.0.3. Both are built on the exact same primitive — and they make the opposite bet about whether your coding agent should obey you or override you.
I read both repos end to end — not the announcements, the actual files: plugin
manifests, session hooks, SKILL.md frontmatter.
The same Lego brick
A “skill” is unglamorous: a folder with a SKILL.md file, a few lines of YAML
frontmatter (name, description), and markdown telling the agent how to do one
thing well. Register it in a .claude-plugin/plugin.json manifest and you have a
Claude Code plugin. That’s the whole primitive.
The libraries don’t compete on the brick. Pocock’s tdd and Superpowers’
test-driven-development preach the same gospel — failing test first,
red-green-refactor, no production code before it. Diff the advice and you’d struggle
to tell them apart.
The fork is one level up — in how the skills get invoked at all.
Superpowers: the agent that won’t let you skip a step
Superpowers ships a SessionStart hook. Before you type anything, it injects the
using-superpowers skill into the agent’s context, wrapped in
<EXTREMELY_IMPORTANT>. The payload is blunt:
If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill. […] This is not negotiable. This is not optional. You cannot rationalize your way out of this.
It even ships a Red Flags table — the exact thoughts an agent uses to talk itself out of the process (“this is just a simple question”, “let me explore the codebase first”), each labelled as rationalisation. The agent must check for a skill before any response, including clarifying questions.
This methodology owns the process. The whole workflow — brainstorm → spec → plan → subagent-driven implementation → TDD → code review → finish the branch — fires automatically, because the bootstrap forces a skill-check every turn. The contributor guide is the tell: a 94% PR rejection rate, and a refusal to “comply” with outside skill-writing guidance without eval evidence.
Pocock 1.0: small tools you stay in front of
Pocock’s library opens with a thesis statement: “Skills for real engineers — not vibe coding,” and then, pointedly:
Approaches like GSD, BMAD, and Spec-Kit try to help by owning the process. But while doing so, they take away your control and make bugs in the process hard to resolve.
There is no session hook; nothing gets injected at startup. The 1.0 release formalised one axis that runs through every skill: user-invoked vs model-invoked.
- User-invoked skills (
disable-model-invocation: true) fire only when a human types them, e.g./grill-me. Their job is to orchestrate. - Model-invoked skills can also fire automatically — but only when the skill’s
own
descriptionadvertises a trigger the model matches.
The difference is the default. Superpowers assumes a skill applies; Pocock fires one only when you invoke it, or when a skill explicitly opted into auto-firing.
What’s in each box
The defaults shape what each library contains. Both share a disciplined core — then they diverge in opposite directions. Superpowers spends its skills on autonomous execution: the machinery that lets it run for hours unattended. Pocock spends his on human alignment and product shaping: the machinery that keeps you deciding what to build. The skill lists are the philosophies.
The two libraries at a glance
| Superpowers (obra) | Matt Pocock skills | |
|---|---|---|
| Version (at writing) | 6.0.3 | 1.0.1 |
| Author | Jesse Vincent / Prime Radiant | Matt Pocock |
| Skills | 14, all general-purpose | ~17 shipped, plus drafts/deprecated in-repo |
| Session bootstrap | Yes — SessionStart hook injects using-superpowers | None |
| Default invocation | Auto: “1% chance → you MUST”, every turn | Explicit: you type it, or a description trigger matches |
| Dependencies | Zero, by design | Composable; some skills require others |
| Install | Plugin marketplaces + 11 per-harness integrations | npx skills add (skills.sh), pick your agents |
| Skill testing | Eval harness (drill drives real sessions, LLM-judged) | None in the repo (changesets release) |
| Centre of gravity | Autonomous execution | Human alignment + design |
| Best when | You want discipline enforced | You want sharp tools you drive |
The trade-off
Neither bet is wrong. They’re tuned for different failure modes.
Superpowers optimises for the agent that cuts corners. If your pain is a model that skips tests, declares victory early, and rationalises its way out of process, a system that injects “you have no choice” every turn is the medicine. The cost: it’ll also drag a one-line question through a full brainstorming workflow, because it can’t tell your trivial task from your load-bearing one.
Pocock optimises for the engineer who already has judgement and wants leverage, not a chaperone. Small, legible skills you compose by hand mean nothing fires that you didn’t ask for — and when something breaks, it breaks in your flow, where you can see and fix it. The cost: the discipline is opt-in: skip the skill and nothing stops you.
It’s the classic tension — framework vs library, autopilot vs power steering.
So what
The real decision isn’t “which repo.” It’s: do you want a system that enforces a process, or a toolkit you drive? The mistake is picking on vibes — pick the architecture that matches how much you want the machine to override the human.
Which would you trust more on your own codebase: the agent that won’t let you skip a step, or the one that does exactly — and only — what you tell it?