Blog Update: Why I Replaced superpowers with mattpocock/skills

Recently I switched from using obra/superpowers to @mattpocockuk’s skills. This post shares my thoughts.

https://t.co/IaMuvTZIaS

Why I Replaced superpowers with mattpocock/skills

Source: https://justinyan.me/post/6676

In the article How Superpowers Executes Long Tasks and Ensures Delivery Quality (https://justinyan.me/post/6657), I explained the principles behind the superpowers skill set, and I used it for a while.

The design of that skill set aims to enforce a strict workflow for the entire software engineering iteration process. Because it uses hooks, users don’t need to be senior software engineers; they can passively and “automatically” invoke the required skills at each stage, forcing the completion of a process from brainstorming to implementation using subagents + worktree.

This skill set works well and is suitable for people not very familiar with software engineering workflows. The plans it generates can even be handed off to cheaper coding agents:

After you've signed off on the design, your agent puts together an implementation plan that's clear enough for an enthusiastic junior engineer with poor taste, no judgement, no project context, and an aversion to testing to follow. It emphasizes true red/green TDD, YAGNI (You Aren't Gonna Need It), and DRY.

However, that’s also the downside of superpowers: it’s prescriptive and token-hungry.

Matt Pocock’s Skills

Last time I mentioned that @Clu (https://x.com/thexclu) recommended mattpocock/skills (https://github.com/mattpocock/skills) to me. I started using it too. For a while I was using both skill sets simultaneously.

At first, I was happy that superpowers could run independently for over an hour, but later I found it often overcomplicates simple problems. So the first thing I did was have my coding agent remove all of superpowers’ hooks. That way, unless I manually invoke it, the coding agent wouldn’t randomly start the superpowers flow.

I then combined mattpocock’s /grill-with-docs with superpowers. I found mattpocock’s Q&A more token-efficient than superpowers’ brainstorming, with no worse results. Admittedly, the latter’s visual companion offers demo effects that can help align visual and interaction design with the agent, but it’s just too expensive on tokens. After Fable 5 came back, I stopped using it entirely.

So if a complex visual interaction design needs early alignment with the agent, we can instead quickly prototype with /prototype to approximate it. This prototype is for testing new ideas and can be thrown away if unsuitable.

Matt Pocock’s skills recently reached v1.0.0, with some skill names changed and the addition of ask-matt. After first installation, you can invoke this skill to get guidance on typical use cases for the skill set.

The basic flow using mattpocock’s skills is similar to that of superpowers:

superpowers:
brainstorming => write-spec => write-plans => execute-plan

mattpocock skills:
grill-with-docs => to-prd => to-issues => implement

The above is the basic flow, but actual usage has some variations.

I use GitHub Issues as my issue tracker for personal projects (since they’re on GitHub), and both PRDs and issues are stored there. The benefit is that I can use an expensive, high-IQ model like Fable 5 to write the PRD, then hand it off to a reliable top-tier model like codex 5.5 to write the code. And because everything is recorded, I never forget what I did with the agent or where I left off.

With mattpocock’s skills, the decision of when to call which skill is back in my hands. After all, the repo describes them as Skills For Real Engineers.

Matt writes in the repo that these skills exist for the following reasons:

1. The Agent Didn’t Do What I Want → Actually the agent doesn’t know what we want. Using /grill-with-docs to converse with the agent helps it truly understand what we need.
2. The Agent Is Way Too Verbose → We and the agent don’t speak the same “language”. Through /grill-with-docs, the agent records technical terms and project context for future reference, enabling efficient communication.
3. The Code Doesn’t Work → We use /tdd with the debug skill /diagnosing-bugs.
4. We Built A Ball Of Mud → I feel coding agents are a bit like humans—they tend to polish existing code. Each stage of this skill set leans toward better design, and /to-prd ensures we identify which modules need modification before starting. But even with careful practices, long-term projects inevitably become messy, and /improve-codebase-architecture is ideal for refactoring. It not only produces detailed documentation but also gives an HTML visualization chart.

This skill set strictly separates user-invoked and model-invoked skills. The main flow skills are manually invoked, while bug-finding and code review skills can be auto-invoked.

Also, /handoff is very useful. For example, when switching between claude and codex, I use /handoff to transfer context.

So recently I’ve replaced superpowers with mattpocock’s skills. It saves tokens, saves time, delivers good results, and leaves records on GitHub Issues, saving my memory (which is overwhelmed by too many projects).

The AI world loves coining new terms—first harness, now loop engineer. But regardless of the buzzwords, it all comes down to capabilities of the underlying foundation models and how we constrain them in engineering. In the early days, with weaker engineering constraints and model capabilities, we emphasized “harness”—steering models in the right direction and preventing drift. As harness engineering matured and models grew more capable with better instruction-following, we shifted focus to stable long-task delivery, which is loop engineering.

Half a year into 2025, the pace of AI development has felt like several generations passing. The fully automated pipeline for short-form video (the “money-printing machine” model) is likely already operational, and low-cost copycat chains are emerging. But in serious product development, much remains to improve. For instance, many people say “taste” is a key part of human-in-the-loop, and polishing products still takes considerable time. However, with the release of Fable 5, I’m starting to see hope that even the product polishing phase can become more efficient. So what will the next generation of software look like? It’s a future to look forward to.