Why Installing More AI Skills Makes Your Model Dumber—and the One-Sentence Skill That Fixes It

Recently, many people have been talking about uninstalling Superpowers. This once most popular Claude Code workflow framework is now being abandoned by many: models are getting stronger and stronger, and overly restrictive frameworks are becoming a hindrance.

I've recently been using a set of skills open-sourced by Matt Pocock (author of Total TypeScript / AI Hero). The repository is called mattpocock/skills, and the idea is simple: small and refined, install only what you need.

After using them for a while, I found that what's really worth discussing about this set of skills is the design philosophy behind them; the features are secondary. It extends from how to align requirements, organize workflows, and combat code rot, all the way to how to write a good skill itself.

This article starts with the specific skills and finally lands on this design philosophy. You won't just learn about a set of tools; you'll also know how to write skills of the same quality yourself.

Let's start with /grill-me.

/grill-me

You may have already heard of /grill-me; it's the most famous skill in the entire repository.

The most common problem with AI Agents is misalignment: they start writing code without understanding what you want, producing something technically correct but completely not what you asked for.

/grill-me solves this. Before starting work, the Agent acts like a merciless tech lead, relentlessly asking question after question, traversing every branch of a decision tree until you truly reach a consensus.

It doesn't just ask without answering; each question comes with a recommended answer, and it won't bother you with questions it can answer by reading the code. However, it might ask exhaustively detailed questions on minor issues, and performance varies across different models.

Building on /grill-me, there's an enhanced version called /grill-with-docs, which produces a domain model, Architecture Decision Records (ADRs), and a CONTEXT.md during the interview, solidifying the alignment results into reusable documents. If the project already has a codebase, you can first use /domain-modeling to sort out domain concepts and boundaries; /grill-me is more suitable for starting from scratch or stress-testing existing ideas.

The content of these skills is actually very simple. /grill-me is just one sentence: Run a /grilling session. The real work is done by the /grilling behind it, and its core instruction is also very short, essentially meaning "Interview me relentlessly on all aspects of this matter until we reach a consensus". One or two sentences make a skill. As for why it's split into two, you'll understand when we get to the design philosophy.

Using /grill-me repeatedly, you'll slowly internalize the habit of "align first, then code". This habit is beneficial even without an Agent.

Composable Workflows

Many people still prefer a workflow with a complete process like Superpowers, but Superpowers is too heavy and too rigid. Matt's set of skills offers a lightweight alternative: a set of composable nodes, each independent, skippable or repeatable as needed, and you can intervene at any time.

/to-spec distills conversational consensus into a specification document, and /to-tickets then breaks the spec into tickets with dependency relationships. /implement executes them one by one, internally running the /tdd red-green-refactor loop. Finally, /code-review performs a dual-axis review, one axis looking at code quality, the other checking compliance with the spec. Throughout the entire workflow, the Agent enforces discipline, and the human makes judgments.

I previously wrote a separate article about the complete practice of this Spec workflow: Stop Letting AI Write Code Directly, Start Building Your Spec Workflow. Check it out if you're interested.

/wayfinder

You should have already seen this skill in the previous flowchart. It was added in version 1.1 of this skill set, and I think it's the most imaginative design in the entire toolkit.

When you face a requirement with a huge idea, vague goals, and a context window that simply can't hold it all, /grill-with-docs might not be able to handle it: too many questions will make it endless, and too long a context will lose key information.

This is where /wayfinder comes in. Matt himself said: "My new skill /wayfinder is letting me do stuff I've never considered trying."

Its core metaphor is the fog of war. If you've played League of Legends or Honor of Kings, you'll understand: at the start of the game, the entire map is fog, and as you walk to a place, that area lights up, until the whole map is visible.

/wayfinder creates a decision map on the issue tracker: a parent issue with a series of sub-tickets underneath, of types like Research, Prototype, Grilling, and Task, each marked with blocking relationships, indicating which must be solved first and which can be parallelized.

You solve these tickets one by one, the fog gradually lifts, and the path becomes clearer step by step. It also supports using sub-agents to digest research tickets in parallel.

I've recently been using it to build a speech-to-text app from scratch. Before starting, I only had a few scattered ideas and couldn't articulate what I wanted to make. As I chatted through the tickets one by one, many vague thoughts clarified themselves, and I'm still following this map to continue refining the functional interactions.

This is completely different from "write a big spec first, then execute". The traditional approach assumes you can make all the right decisions on day one, but for truly complex projects, this assumption is itself wrong. /wayfinder accepts uncertainty and replaces one-time planning with progressive discovery.

I think the most powerful thing about this skill is the attitude behind it: You don't need to figure everything out at the start. Just take a step first, and decide the next step when you get there.

If your requirements are relatively vague or large, I strongly recommend trying /wayfinder.

/improve-codebase-architecture

Agents write code fast, but they can also easily turn a project into a mud ball. The faster they write, the faster the architecture rots.

This skill is designed to hit the brakes on rot: periodically scan the codebase, find refactoring opportunities, and generate a single-file HTML report with cards, before/after comparison diagrams, and recommended strength annotations. The analysis prioritizes recently modified hot spots and doesn't do a full scan.

It has a strict set of shared vocabulary behind it, defined in a dedicated /codebase-design skill for use by multiple skills: module, interface, depth, seam, etc. Each word has a precise meaning, and arbitrary synonym substitution is not allowed.

The core concept is the deep module. A good module should be "deep": a small interface that unlocks a large amount of behavior. Conversely, a "shallow" module has an interface almost as complex as its implementation, and using it doesn't simplify anything for you. This concept comes from John Ousterhout's "A Philosophy of Software Design", and Matt directly encoded it into the Agent's judgment criteria.

How to judge if a module is deep enough? Matt uses a method called the Deletion Test: suppose you delete this module and spread its logic back into the callers, would the overall complexity skyrocket? If yes, it means it truly encapsulated complexity; if it barely changes, it means the complexity was never absorbed, and it's shallow.

After discovering candidate refactoring points, it won't directly generate a PR; it will first call /grilling to engage you in a round of in-depth discussion.

From Code Design to Skill Design

Matt uses deep modules in /improve-codebase-architecture to judge code design, but he didn't stop at code. He pushed the same thinking into a new domain: how should instructions written for AI be organized?

This is /writing-great-skills, the most underrated but most worth reading carefully in the entire repository. It's a skill for writing skills, not involving any specific engineering task, telling you only one thing: how to write predictable, maintainable AI skills.

If you look closely, you'll find it's talking about the same thing as /improve-codebase-architecture.

A good skill is a deep module. The /grill-me you type is an extremely small interface, encapsulating a large amount of behavior behind it like decision tree traversal, alignment checks, and completion criteria. If every internal step were exposed to the user, it would be shallow.

Matt proposes several concepts here, and I'll expand on the most valuable ones.

Context Load vs Cognitive Load

The first is Context Load vs Cognitive Load. This might be a new trade-off unique to the AI era.

Design a skill as model-invoked, and the Agent can judge for itself when to use it, at the cost of the description permanently occupying the context window. Design a skill as user-invoked, and the context is clean, but you have to remember it and call it manually.

The cost of permanently resident context is higher than imagined. An LLM isn't equally good across the entire context window. Matt's observation is that only about the first 120k tokens are the Smart Zone, where the model is truly sharp; beyond that, it starts dropping instructions and contradicting itself. Every extra skill you attach, its description takes up another chunk of the Smart Zone. This is the underlying reason why the more skills you install, the dumber the AI gets.

When there are too many user-invoked skills to remember, Matt's solution is a router skill: a skill also invoked by the user, listing the names of other skills and their applicable timing. You only need to remember this one name, and cognitive load no longer grows with the number of skills.

/grill-me follows the same logic: it's user-invoked, occupies zero context, and its only content is to call the model-invoked /grilling, with behavior defined in only one place.

Moving complexity from one place to another isn't skill; good design truly reduces it.

Leading Words

Next is Leading Words, which I particularly like.

The model has deeply understood certain words during pre-training. Instead of repeatedly writing "fast, deterministic, low-overhead loop", you can just use the word "tight". Instead of explaining "progressively exploring unknown territory" in three paragraphs, just use "fog of war".

Simply put, it's about finding concepts already in the model's mind and directly activating them. The fog of war in /wayfinder mentioned earlier is a practice of leading words: saving a lot of explanation and making the model's behavior more predictable.

Progressive Disclosure

There's also Progressive Disclosure. A good skill layers content by urgency: steps that must be executed immediately go in the main body of SKILL.md, reference information goes in the latter half, and large external references point to separate files, loaded only when needed.

This is in line with the core idea of deep modules: the implementer of a module should actively bear the complexity, allowing the user to face a simple interface. In the context of skills, the "user" is the model, and the "complexity" is the token count.

Pruning

Finally, there's Pruning. A skill written without maintenance will also rot. Matt categorizes four types of rot: Sediment (old content accumulated without cleanup), Sprawl (getting longer and longer, losing focus), No-Op (writing out things the model would do anyway), and Duplication (the same meaning appearing in multiple places).

The attitude is simple: delete aggressively. If you delete a section of instructions and the model's behavior doesn't change, it means that section was nonsense to begin with. You've noticed, this is the skill version of the Deletion Test.

After reading /writing-great-skills, you already understand why this set of skills works well. The next good skill can be one you write yourself.

Finally

If you want to try it, install with one command:

npx skills@latest add mattpocock/skills

First run /setup-matt-pocock-skills to configure your issue tracker and document locations. Start new projects with /grill-me, existing codebases can first run a /domain-modeling, and complex tasks start with /wayfinder. Use a real project you're currently working on and let it grill you once.

You'll know if it's worth keeping.