Matt Pocock's Modular Claude Code Skills Explained

There's a particular flavor of frustration that anyone who has tried to build something with an AI coding assistant knows intimately: you describe what you want, the AI builds something, and what comes back is... adjacent. Technically functional, spiritually wrong. Different typography, different layout logic, a checkout flow that makes different decisions than the ones you had in your head.

Matt Pocock — a developer educator known in the TypeScript community — has been working on a systematic answer to that problem. His collection of Claude Code skills has accumulated a substantial number of downloads across the skill leaderboard, and developer Eric from the Eric Tech YouTube channel recently spent 24 minutes breaking down exactly what makes them worth studying.

The core diagnosis Pocock starts with is simple: AI is a black box. You put a prompt in, something comes out, and the variance is enormous. His skills — /grill-me, /to-spec, /to-tickets, and several others — are designed to reduce that variance without over-constraining the model.

The Philosophy Before the Skills

What separates Pocock's approach from frameworks like GStack or other spec-driven development pipelines isn't just the individual skills — it's the architecture of how they relate to each other. Or rather, how they don't.

Most workflow frameworks chain their steps together. Step two depends on step one. If something goes sideways at step four, you're potentially re-running the whole pipeline. Eric describes it bluntly: "there's no way that I can just trigger step two and just rerun the whole process right, that whole process here is chained together and there's no way that you can break it."

Pocock's answer is modularity. Each skill is a standalone unit you can invoke in any order. Finished implementation but want to re-run the spec? Fine. Did the code review before the architecture cleanup? Also fine. The skills are reusable building blocks, not dominoes. This connects to a broader pattern in skill-as-infrastructure thinking — where the tooling increasingly gets designed for teams that need to revisit steps, not just pipelines that assume a clean first pass.

/grill-me: The Interview That Doesn't Let You Off the Hook

The /grill-me skill is Eric's entry point, and it's apparently the second-most downloaded skill on the leaderboard. Its job is context collection — but structured, relentless context collection.

Eric breaks it down into five rules: the AI questions you relentlessly until a shared understanding is reached; it moves through a decision tree one branch at a time (so it's not asking you about the checkout page and the dashboard and the onboarding flow all at once); it waits for your answer before asking the next question; it always offers a recommendation rather than leaving you with an open-ended blank; and it never acts until you confirm.

That last rule is understated but important. The skill is deliberately non-agentic at the intake stage. It's gathering, not doing. The model "just going to supply you with options and you decide the decisions and stack it on top."

What you end up with is a structured record of your actual intentions — which would otherwise evaporate the moment you close the conversation.

/to-spec and /to-tickets: Freezing the Understanding, Then Slicing It Right

/to-spec converts that grilling session into a written design plan. The distinguishing rule Pocock enforces here: no code blocks in the spec file. Ever.

The reasoning is pragmatic. If you embed code in the spec, the AI follows that code. But what if that code is outdated by the time implementation starts? You've now anchored the agent to a stale reference. Keeping the spec code-free forces the agent to look at the actual codebase and make decisions from the current state of things — not from a snapshot written before implementation began. This design principle — separating intent from implementation — tracks with what old engineering practices have argued for decades.

/to-tickets then breaks that spec into actionable units. And here's where Pocock diverges from conventional project management instincts: instead of organizing tickets by layer (database ticket, API ticket, UI ticket), he organizes by feature.

The practical difference is testability. If your tickets are layer-based, you can't test a full user flow until every layer is done. If your tickets are feature-based — ticket one is the complete login page, end to end — you can test the entire feature immediately. You get feedback faster, you can pivot sooner, and the application stays modular throughout.

Code Review With Fresh Eyes (and Martin Fowler)

The /code-review skill has a structural quirk worth noting: it runs in a fresh context window. Not the same session that wrote the code. The idea is that an AI reviewing its own work in the same context is essentially proofreading by rereading — it's likely to make the same assumptions it made the first time.

Fresh context means fresh eyes, at least in theory.

The review checklist Pocock uses draws on vocabulary from Martin Fowler's Refactoring — a foundational software engineering text. Rather than writing out step-by-step instructions for the AI on how to clean code, Pocock borrows Fowler's terminology directly. Terms like "shotgun surgery" (a change that needs to be made in multiple scattered places), "feature envy" (logic living in the wrong file), and "data clumps" (multiple data types that keep appearing together and should probably be grouped into a single type).

The insight here is elegant: these terms already carry dense, precise meaning that models understand. Using them is more efficient than trying to paraphrase them into fresh instructions — and the /writing-for-agents skill formalizes this into a philosophy: prune your skill prompts ruthlessly, and use vocabulary with embedded depth rather than writing out everything longhand. As Eric puts it, "every extra word that you put in the skill is going to be distractions that cause AI model here to hallucinate."

This connects directly to skill design principles that treat prompt bloat as a real failure mode, not just an aesthetic preference.

Deep Modules and the Deletion Test

One of the more structural ideas in Pocock's toolkit is what Eric calls "deep modules" — a design pattern that addresses how AI consumes code when trying to understand a program.

When an AI reads a payment-processing function, it doesn't just read that function — it follows every dependency, every sub-function that gets called, every reference. That chain of context-loading burns tokens fast. Pocock's approach: create a single, well-encapsulated entry point that presents the program's logic cleanly without forcing the AI to hop across dozens of files to reconstruct what's happening.

This isn't "stuff everything into one file" — each function still lives in its own file. It's about providing one clear door rather than many windows.

The deletion test is the cleanup complement to this: for any function a program depends on, try removing it. If everything still works, the function wasn't necessary. If tests fail, keep it. It's a blunt instrument, but the /improve-codebase-architecture skill automates it at scale — scanning git history, identifying hot files, running deletion logic, and producing an architecture review that flags redundant code, duplicate functions, and misplaced logic.

The Bigger Argument: How Much Guardrail Do Frontier Models Need?

Eric's verdict lands in genuinely interesting territory. His read: Pocock's modular, light-touch philosophy is the right approach for capable frontier models, because tightly scripted frameworks may actually be holding those models back.

"We shouldn't put too many guards on the skills," Eric argues. "So many instructions to skill that really holds back the model performance."

The reasoning tracks with something Anthropic has apparently done internally — reducing the proportion of system prompt instructions for newer models as those models demonstrate stronger built-in judgment. Models that have the rules internalized don't need them spelled out. Over-specifying may box them in.

The caveat Eric acknowledges matters: for lighter, less capable models, heavier scaffolding probably still makes sense. The modular approach assumes a model that can fill the gaps intelligently. For a model that can't, those gaps become failure points.

That's the real open question underneath all of this. Pocock's skills — short, vocabulary-dense, lightly prescriptive — are optimized for a model that can be trusted to exercise judgment. The markdown files that teach once model of skill design only works if the AI reading those files is sophisticated enough to interpret dense shorthand rather than needing it unpacked step by step.

As models improve, the answer to "how much guidance does the skill need to provide?" keeps shifting downward. The interesting design problem is building skills that stay useful as the target keeps moving.

---

Yuki Okonkwo is Buzzrag's AI & Machine Learning correspondent.