As Models Get Stronger, Skills Should Get Thinner: Subtracting from AI Coding Workflows

A Complete Workflow Feels Safe — and It Is Genuinely Slow

When I first started using Superpowers, I genuinely found it convenient.

It clarifies requirements, discusses the design, produces an implementation plan, writes the code, runs tests, and performs code review. Many of the reminders I once had to give an AI were already built into one workflow.

That feels reassuring when you are new to coding agents. You do not have to keep deciding what instruction should come next, and the agent is less likely to start changing code before it understands the task.

After using it for a while, another problem became clear: the full workflow is genuinely slow. The delay does not come from generating text or code. It comes from stacking requirement confirmation, design, specifications, task breakdown, and multiple reviews. Those steps each serve a purpose on a large project. On a change that should take a few minutes, their cost can exceed the implementation itself.

Some changes are already well defined: adjust a condition, add error handling, change a SQL field, or fix a few lines of code. Under normal circumstances, an agent can find the relevant code, make the change, and run the necessary tests in a few minutes.

With a complete workflow, the same agent may reconfirm the requirements, discuss the design, produce a specification, break it into implementation tasks, execute and verify each one, and finish with several review passes. Each step is reasonable in isolation. Together, they are too heavy for a small task.

That led me to a question:

Should an AI coding workflow make every task pass through the same process, or should the agent choose a process that matches the task's size and risk?

Process Cost Should Match Task Risk

Superpowers describes itself as a complete software development methodology, covering requirements, design, planning, TDD, delegated implementation, review, and branch completion. For architectural changes, cross-service work, or long autonomous runs, that process can reveal a wrong direction early.

Examples include:

• Building a new feature
• Changing the system architecture
• Modifying several services
• Running a data migration
• Letting an agent work autonomously for an extended period

In those situations, clarifying the work first, planning it, and verifying it in stages can prevent the agent from discovering halfway through that the direction was wrong.

A small task needs quick comprehension, a precise change, and necessary verification. A clear task spanning several modules may justify a short plan. The complete workflow earns its cost when the requirements are ambiguous, the scope is broad, or the risk is high.

The Value of Matt Pocock's Skills Is Not Just Their Length

I later started reading Matt Pocock's public Skills.

Pocock describes them as small, easy to adapt, and composable. Questioning, debugging, TDD, and code review live in separate Skills instead of one workflow that owns the entire process.

When requirements are unclear, an interviewing Skill can clarify them. A difficult bug can call diagnosing-bugs; test-driven development can call tdd; and code inspection can call code-review.

The engineering disciplines are still present. They simply do not have to appear together on every task.

My practical extension of that design is to classify the task first, then add the disciplines it needs. A change that takes a few minutes can move directly to implementation and verification. Research, planning, TDD, and review can be added as complexity grows.

Smaller Skills Make Problems Easier to Locate

When one Skill handles requirements, design, implementation, tests, review, and delivery, a behavioral problem can be difficult to trace.

• If the debugging loop is wrong, change diagnosing-bugs.
• If the testing approach is wrong, change tdd.
• If code review is too verbose, adjust code-review.
• If the requirements remain unclear, start an interview or specification workflow.

Smaller capabilities make failures easier to locate. They also let the user decide how much process a task should receive.

Short Does Not Mean Careless

A Skill can remain concise because all of its information does not have to live in one place.

In Pocock's current taxonomy, a model-invoked Skill keeps a description the model can evaluate, adding to the context load on every turn. A user-invoked Skill sets disable-model-invocation: true and gives up automatic discovery.

The same document uses progressive disclosure: steps required on every run stay in the Skill, while rules needed by only some branches move into referenced files and load when the branch needs them.

Other agent products may implement loading differently, but the design question remains the same: which information needs to stay in front of the model at all times? Important information does not necessarily need to be always-on, and adding rules does not guarantee a more reliable agent.

Every instruction should justify why the model needs to see it now.

Re-Test Old Rules When the Model Changes

LLM capabilities keep changing. A new model may understand code, search a repository, plan a change, call tools, and verify results better than the previous generation.

Instructions that once had to live in AGENTS.md or a Skill may become behavior the model already performs. For example:

• Read the relevant code first.
• Understand the existing architecture before editing.
• Find the root cause instead of patching the symptom.
• Run tests after the change.
• Report which files changed.
• Search the repository when information is missing.

Those instructions may have helped an older model. If a newer model already follows them, keeping them may add no quality and may push a change that should take minutes into a full analysis, planning, and reporting workflow.

My working hypothesis is that model upgrades make some old rules obsolete. Skills still matter, but models may absorb some general capabilities. The only responsible way to remove a rule is to compare real tasks with and without it.

Prompts Accumulate Technical Debt Too

When an agent makes a mistake, adding another rule feels natural.

It forgot to run tests, so every task must run the full suite. It misunderstood a requirement, so every change must begin with an interview. It damaged the architecture, so every task must start with a design document. It missed a problem, so another review pass gets added.

Each rule has a reasonable history. The problem is that we tend to add and rarely delete.

Pocock calls these stale, additive layers sediment. Old instructions settle into repeated, outdated, and sometimes conflicting requirements. Prompts accumulate technical debt just like code, and they need refactoring too.

Use Removal Tests to Find No-Ops

Many instructions sound unquestionably correct:

• Think carefully.
• Follow best practices.
• Ensure code quality.
• Analyze the problem thoroughly.
• Confirm that nothing was missed.

When maintaining a Skill, I run a direct test: if I remove this sentence, does the model's behavior get worse?

Pocock calls an instruction that does not change the model's default behavior a no-op. If removing “think carefully” or “ensure code quality” does not change the result, the sentence only adds context and maintenance cost.

Useful rules are usually more specific:

• The exact test command to run after a change
• Modules the agent must not modify
• APIs that must remain compatible
• Edge cases the implementation must cover
• Evidence the agent must provide
• Conditions that must pass before the task is complete

“Do a good job” is an expectation. “Pass these three tests” is verifiable.

What Information Is Hard for a New Model to Replace?

Even as models get stronger, I see three categories of information that should remain.

Project Facts the Model Cannot Know

Examples include:

• The real test and deployment commands
• Internal business terminology
• Which document is authoritative
• The actual responsibility of each module
• Environmental constraints that are not visible in the code

A model cannot infer internal company rules from public information or source code. The team still has to state them explicitly.

Boundaries the Model Has No Authority to Change

Examples include:

• Do not modify the public API.
• Maintain backward compatibility.
• Do not add dependencies.
• Only modify the specified service.
• Do not use production data for local testing.

These are team decisions. A stronger model still has no authority to change them.

Completion Criteria That Can Be Verified

Examples include:

• Tests that must pass
• Scenarios that must be verified
• Evidence the agent must provide
• Existing behavior that must remain unchanged
• The result that counts as genuinely complete

These rules are often more effective than a long procedure. They do not prescribe every step, but they make the required result explicit.

A Guardrail for One Model Can Constrain the Next

Some Skill content patches a weakness in a specific model.

Suppose an older model struggled to find tests, so the Skill prescribed a detailed search sequence. A newer model may find a better test location on its own, while the old workflow still forces it through the fixed sequence. A former guardrail has become a constraint.

Whenever I change the primary model, I should recheck the existing prompts and Skills:

1. Run a few common tasks without additional rules and observe the model's default behavior.
2. Add the existing AGENTS.md and Skills.
3. Compare whether the result actually improves.
4. Identify rules that only repeat behavior the model already has.
5. Remove content that adds process without improving the result.
6. Move low-frequency information behind on-demand references.
7. Preserve project facts, engineering boundaries, and completion criteria.

It is the same exercise as revisiting workarounds after a software upgrade. If the underlying problem is gone, the patch should not live forever.

Excessive Planning May Not Be a Skill Problem

The same Skill can behave differently across models, agent products, and versions. Invocation, context loading, compaction, and tool permissions all influence the result.

A coding agent's behavior is usually shaped by several layers:

• The model
• The product's system instructions
• The repository's AGENTS.md
• Skill descriptions and content
• Workflows injected by a plugin or hook
• The tools available to the agent
• Context compaction
• The task information given to a subagent

When an agent produces an enormous plan for a small change, first identify which layer required it. The model may prefer planning, the system instructions may require a plan, AGENTS.md may demand a specification, a Skill may trigger too broadly, or a plugin may inject a complete workflow at the start of every session.

All of those failures look like “the agent plans too much,” but they require different fixes.

Follow One Behavioral Path Through the Source

When I read an agent's source code, I start with one path: from the task I enter to the moment the agent loads a Skill, selects a tool, and executes it. Then I check:

• Where does the agent look for Skills?
• Which content remains in context?
• Is a Skill invoked manually or selected by the model?
• Which Skill wins when names conflict?
• What rules survive context compaction?
• Does a subagent receive the full task or a summary?
• Do the tools required by the Skill actually exist in this environment?

Once I understand that path, I know which layer to change when the agent behaves incorrectly. Otherwise, I may keep rewriting a prompt when the real problem is that the Skill never loaded or the required tool has no permission.

Put Control in the Right Layer

Several layers shape an agent's behavior. Project facts can live in AGENTS.md, task-specific workflows in Skills, dangerous operations behind permissions, and results behind tests, lint, CI, and completion criteria.

For example:

• Store always-needed project facts in AGENTS.md.
• Package task-specific workflows as Skills.
• Use the Skill description to control invocation.
• Keep low-frequency detail in references.
• Restrict dangerous operations with permissions.
• Verify results with tests and lint.
• Use completion criteria to decide when a task can end.
• Use a hook for actions that must run every time.

If the concern is that an agent may forget to run tests, one exact verification command — or a CI check — is usually more reliable than three reminders. Permissions, module boundaries, and review gates can also prevent unwanted changes.

A prompt is only one layer.

From Prompt Engineering to Agent Engineering

A modern coding agent combines a model, context, tools, Skills, plugins, hooks, subagents, and external systems. Someone still has to decide which information is always present, which capabilities load on demand, which boundaries the system enforces, and which outcomes tools must verify.

I call that work Agent Engineering: treating the whole agent as a system that can be observed, tested, adjusted, and debugged.

How I Will Rework My Own Skills

I will use five questions to review my AGENTS.md and Skills:

• Does this task genuinely need the complete workflow?
• Does this information need to appear in context on every turn?
• Does this Skill solve one clear problem?
• Can tests, lint, or another tool verify its completion criteria?
• After a model change, does this old rule still improve the result?

Complete workflows and composable Skills serve different situations. Before each task, I now ask three more questions:

How much process does this task need?

How much instruction does this model still need?

Is this rule still worth keeping?

A good Skill should help an agent do the right amount of work at the right time.

Inspiration and Sources

1. Threads inspiration post
2. YouTube video
3. Matt Pocock — Skills For Real Engineers
4. Matt Pocock — writing-great-skills
5. Superpowers