Switching from Superpowers to mattpocock/skills: Less Token Waste, More Control

In my article "Why Superpowers Can Execute Long Tasks and Ensure Delivery Quality", I explained the principles behind the Superpowers skills and have been using them for a while.

These skills are designed to enforce a standardized workflow to regulate the entire software engineering iteration process. By using hooks, users don't need to be senior engineers—the system passively "automatically" invokes the required skill at each stage, forcibly walking them through the process from brainstorming to implementation using subagents and worktree.

These skills are excellent, especially for those less familiar with software engineering workflows. The plans generated can even be delegated 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.

But this is also Superpowers' downside: it's forced and token-intensive.

Matt Pocock's Skills

As I mentioned last time, @Clu recommended the mattpocock/skills to me. I started using it, and for a while I was running both skill sets simultaneously.

At first I was thrilled that Superpowers could run independently for over an hour, but later I found it often overcomplicated simple problems. So the first thing I did was ask my coding agent to delete all the hooks from Superpowers, ensuring it wouldn't kick in automatically unless I manually invoked it.

This allowed me to combine mattpocock's /grill-with-docs with Superpowers. I found that mattpocock's Q&A used fewer tokens than Superpowers' brainstorming, with no worse results. Admittedly, the latter's visual companion provided demo previews that helped align visual and interaction design with the agent, but it was too token-heavy. After Fable 5 came back, I stopped using it altogether.

So if complex visual interactions need early alignment with the agent, we can use /prototype to quickly build a simple prototype as a rough substitute. This prototype is meant for testing new ideas and can be thrown away if unsuitable.

Mattpocock's skills reached v1.0.0 two weeks ago, along with some renaming and the addition of ask-matt—call it after initial installation, and it will tell you how to use the skills for typical scenarios.

The basic workflow of these skills is similar to 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 in practice there are some variations.

My personal projects are on GitHub, so I use GitHub Issues as the issue tracker, storing both PRDs and issues there. The advantage is that I can use an expensive, high-intelligence 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 since everything is recorded, I won't forget what I did with the agent or where I left off.

Using mattpocock's skills puts the decision of when to invoke which skill back in my hands. After all, he calls it "Skills For Real Engineers".

Matt wrote in the repo that the skills exist because:

The Agent Didn't Do What I Want => Actually, the agent doesn't know what we want. Through /grill-with-docs, we engage in Q&A to help the agent truly understand our requirements.

The Agent Is Way Too Verbose => We and the agent don't speak the same "language". Through /grill-with-docs, the agent records terms and project-specific context for future reference, enabling efficient communication between us.

The Code Doesn't Work => We use /tdd, paired with the debug skill /diagnosing-bugs.

We Built A Ball Of Mud => I feel coding agents are a bit like humans—they like to polish existing code. Each phase of these skills tends toward better design; /to-prd also confirms which modules should be refactored before starting. But even with caution, projects can become messy over time. That's when /improve-codebase-architecture shines, producing detailed documentation and an HTML page with visual charts.

These skills strictly differentiate between user-invoked and model-invoked modes; core workflow skills are manually invoked, while bug-hunting and code review skills can be auto-triggered.

Also, /handoff is very handy—when switching between Claude and Codex, I use /handoff to transfer context, and so on.

So recently I've replaced Superpowers with mattpocock's skill set—it saves tokens and time while delivering good results, and it leaves logs in GitHub Issues to rescue my memory, which is overwhelmed by too many projects.

The AI world loves coining terms: first "harness", now "loop engineer". But whatever the buzzword, it all comes down to the enhancement of base model capabilities and how we constrain model behavior in engineering practice. When constraints and model capabilities were weaker, we emphasized "harness"—guiding the model along desired paths without deviation. As harness engineering advances and models become more capable with better instruction following, we shift focus to stable long-task delivery, moving toward "loop engineering".

Half of this year has passed, and AI has evolved so rapidly it feels like several generations have come and gone. The fully automated assembly-line cash-printing model for short-form dramas is basically operational, with low-cost copycat pipelines emerging everywhere. But in the domain of serious product development, there's still much to improve—"taste" is often cited as a critical part of human-in-the-loop, and product refinement remains time-consuming. With the release of Fable 5, however, I'm beginning to see a glimmer of efficiency gains in the polishing phase. What will the next generation of software look like? What an exciting future ahead.