Superpowers vs Matt Pocock Skills: Who Controls the Workflow?

Choose Superpowers if you want your coding agent to follow a connected methodology by default. Choose Matt Pocock’s skills if you want more direct control over which procedure runs and when. Both address requirements, tests and review. The useful distinction is who orchestrates those practices.

This comparison is based on upstream documentation checked November 6, 2026. It is a source review, not a head-to-head execution benchmark. The repositories change quickly: our earlier Superpowers guide and Matt Pocock skills guide describe earlier snapshots. Use the pinned sources below for this comparison.

The decision at a glance

Decision	Superpowers	Matt Pocock skills
Default approach	Connected methodology with automatic skill triggering	Composable procedures with explicit orchestration entry points
Requirements	Brainstorming before building; approved design feeds planning	Grilling, domain modeling and conversation-to-spec procedures
Implementation	Plan execution inline or through fresh implementer subagents	Implement a spec or ticket graph; invoke reusable disciplines
Testing	Red-green-refactor integrated into implementation	Reusable TDD skill, driven at agreed seams
Durable context	Design and implementation artifacts	Glossary, ADRs, specs and tracker tickets
Your main responsibility	Review the design and ensure the process fits the task	Select the flow and maintain its project configuration

These are differences in emphasis, not exclusive capabilities. Matt’s collection now includes whole-spec implementation and task graphs. Superpowers describes its own skills as composable. Calling one “a framework” and the other “only prompts” hides the actual choice. See the Superpowers README and Matt Pocock README.

Automatic discipline versus explicit entry points

Superpowers starts by making the agent check for applicable skills. Its documented sequence moves from brainstorming to isolation, planning, implementation, review and integration. This is useful when your repeated correction is “you started coding before we agreed what to build.”

You still need to read the design. An automatic handoff cannot tell whether your product constraint was misunderstood. The process makes that misunderstanding more visible; it does not settle the decision for you.

Matt’s current reference distinguishes user-invoked orchestration from model-invoked reusable disciplines. For example, grill-with-docs, to-spec, to-tickets and implement are entry points you choose. Skills such as tdd, domain-modeling and codebase-design can be reached automatically when the work fits. The README also provides ask-matt as a router. This is more precise than saying every Matt skill requires a manual command. Source: invocation reference.

Choose that arrangement when you already have a ticketing and review process and want better procedures inside it. You trade a single default lifecycle for more responsibility to select the right next action.

Documentation: implementation memory or domain memory?

Superpowers emphasizes an approved design and an executable implementation plan. These answer two different questions: what was agreed, and how will the work be performed? A reviewer can compare the diff against those artifacts rather than reconstructing intent from chat.

Matt’s grill-with-docs emphasizes shared terminology and architecture decisions. The README describes updating GLOSSARY.md and ADRs while working through the design. That matters when developers and agents repeatedly use different names for the same business concept. Its specs and tickets can then carry that language into implementation. Source: domain-model workflow.

For a payment system, “invoice,” “payment attempt” and “subscription” are distinct entities. A plan with accurate filenames still fails if it confuses those concepts. Conversely, a glossary cannot replace concrete acceptance criteria. Choose the artifact your current process is missing; either collection may need local additions.

Testing and review are shared ground

Both collections prescribe test-first implementation and code review. In the inspected Matt Pocock TDD procedure, refactoring belongs to review rather than the red-green implementation loop. Superpowers makes these part of its connected workflow. Matt’s implement description drives TDD at agreed seams and closes with code review; implement-spec works a ticket graph with implementer subagents. Sources: Superpowers workflow, Matt implementation reference.

This does not establish that one produces fewer bugs. Test quality depends on whether the tests cover the behavior that matters. A passing suite that mocks away an authorization check is weak evidence under either procedure.

Superpowers also offers an inline execution path alongside subagent-driven development. Do not assume every task must use the most elaborate route. Before evaluating either collection, decide what must be verified and which reviewer can judge it. Model, repository, tool access and task size will affect your results.

Worked example: adding an export permission

The following is an illustrative evaluation scenario, not a report of a test we ran.

Suppose a dashboard needs CSV exports restricted to account administrators. Your acceptance criteria are: administrators can export, other roles cannot, and the server rejects direct unauthorized requests.

With Superpowers, evaluate whether brainstorming surfaces the server-side boundary before implementation. Inspect the approved design, then the plan. During implementation, require evidence that an unauthorized request fails before the fix and remains covered afterward. Review the resulting diff against the agreed roles.

With Matt’s skills, begin with grill-with-docs if “administrator” or account ownership is ambiguous. Capture the decision, turn the discussion into a spec, and use the implementation procedure that fits your ticket setup. Check that the domain terms survive into the tests and server checks.

The success criterion is the same: a correctly enforced boundary with reviewable evidence. Record unnecessary questions, missed requirements and review corrections separately. Finishing first is not useful if a hidden authorization path remains open.

Setup and switching costs

Both READMEs offer host-specific installation routes. Matt’s setup procedure also asks about the issue tracker, triage labels and documentation locations. Follow the current instructions for your agent rather than copying a command from an older article. Both repositories warn, directly or through their setup choices, that installation method matters. Matt explicitly says to choose a plugin or editable files per agent to avoid duplicate skills. Source: installation and setup.

When switching, preserve approved requirements, tests and architecture decisions. You do not need to rename every historical document. Start a fresh session with one selected workflow and tell the agent where existing context lives.

Avoid loading two competing brainstorming, TDD and review procedures without deciding which takes precedence. Similar names can conceal different stop rules. Review the actual installed files and any project instructions before judging unexpected behavior.

FAQ

Is Superpowers better than Matt Pocock’s skills?

There is no universal winner established by this review. Superpowers fits a desire for automatic lifecycle discipline. Matt’s skills fit developers who want explicit orchestration and adaptable engineering building blocks.

Are Matt Pocock’s skills only for small tasks?

No. The current collection includes implement-spec for a whole spec and wayfinder for work larger than one session. Small, composable procedures can support large projects. Source: skill reference.

Can I combine them?

Yes in principle, but define ownership of overlapping stages first. Start with one collection’s workflow, then add a procedure that fills an identified gap. Do not assume two installed TDD skills reinforce each other.

Which should I evaluate first?

Choose the one that addresses your most frequent correction. If the agent skips design, start with Superpowers. If your existing process works but terminology or a particular engineering step fails, examine Matt’s relevant procedure. For other options, use our Superpowers alternatives comparison; for project-scale coordination, read GSD vs Superpowers.

Sources and review scope

Checked November 6, 2026: Superpowers pinned README and Matt Pocock pinned README. Recommendations are editorial interpretations of those documented workflows. No timing, token-cost or defect benchmark was performed. Review again after source releases or on December 6, 2026.