From Superpowers to Skills: What Changed with GPT-5.6

Coding agents used to rush past the work they needed to understand. I wanted a process that made their assumptions visible before they changed much code, and that need shaped how I first used agent workflows.

Moving to GPT-5.6 changed the trade-off for me. I still want strong engineering habits, but I no longer want a full methodology to be the default for every task.

Why I tried Superpowers, then Matt Pocock’s Skills

Superpowers gave me that process. It set a clear route: clarify the work, agree a design, write a plan, implement with TDD, review it, then finish the branch.

At the time, I needed those rails because they created places to stop an agent, inspect its choices, and ask what it had missed before the work spread through the codebase.

After I moved to GPT-5.6, the same route began to feel expensive. On small changes, the model often retraced steps it could handle with local judgment, while extra planning and handoffs rarely improved the result.

That is why I moved to Matt Pocock’s Skills. I could start with the skill that matched the uncertainty and add process only when the work called for it.

Superpowers gives the agent a prescribed route. Matt Pocock’s Skills lets me choose one.

A skill, a workflow, and a loop

A skill gives an agent a way to handle one kind of work, such as diagnosing a bug or reviewing a diff. A workflow puts several skills in order for a known task.

Those are nested levels of control. I use “loop engineering” for the layer around the task: it decides where work comes from, what counts as success, what the system remembers, and what follows a failed attempt.

Skills help with an action. Workflows organise a task. Loops deal with the work around it.

TDD has a small loop: implement, run the test, inspect the result, and try again. Superpowers applies the same idea at a larger scale around planning, implementation, and review.

An issue tracker that selects work, waits for review feedback, and returns later needs the outer layer. It must decide what happens after each attempt, not merely how an agent performs one task.

When I spend more on workflow than it saves

That distinction explains why a workflow can cost more than it saves. Each stage asks the model to reread the task, rebuild context, and summarise it for the next agent or review.

That helps with real risk, but a narrow fix may only need an inspection, a change, and a relevant check. Handoffs make the cost visible: a planner briefs an implementer, who briefs a reviewer, who sends a finding to a fixing agent.

I add a handoff only when its judgment can change the outcome enough to justify rebuilding the context. My default is the smallest credible workflow.

For a local, low-risk change, that is inspect, change, and run the relevant check. I add diagnosis for uncertainty, and planning or independent review when the cost of being wrong is meaningfully higher.

The loop asks what happens next

A development workflow ends when the task is finished or a branch is ready for review. A maintenance system still needs rules for the moment after that, which is where the loop begins.

I use evidence and recorded state to choose the next move.

I set loop rules to finish, retry, split the work, stop, or escalate. To make those decisions, the loop needs a source of work, persistent state, evidence beyond the agent’s confidence, and a retry limit.

For example, a maintenance loop can select one small, agent-ready issue and run the smallest workflow that fits. Test or browser evidence can then support a draft pull request.

If the check fails twice, the loop should record what was tried and ask for help. It should not quietly retry forever or move on as though nothing happened.

The workflow executes the task; the loop rules decide whether it earned another attempt, needs a person, or gives way to the next piece of work.

What I want from agent workflows now

I still want skills that preserve good habits: TDD, source checking, and security boundaries. GPT-5.6 has not removed the need for those habits; it has made a lighter default more practical for me.

I want the model to choose the smallest credible workflow while the surrounding loop keeps evidence, state, and the next decision visible. Skills help the agent act well; loops make sure the system knows what to do next.