The Real Lesson in Matt Pocock’s Skills Isn’t the Slash Commands — It’s the Pipeline
Matt Pocock ships a set of 25 agent skills you can drop into Claude Code, Cursor, Codex, or Copilot with one command. Most people install them, run /grill-me, get a nice experience, and move on. That’s a waste. The install is not the interesting part. The interesting part is that the skills are arranged into a pipeline, and the shape of that pipeline is an argument about how agentic coding should work.
You can steal the argument without installing anything. Here’s what it says — and where I think it’s wrong.
The spine
The core sequence, in order, runs from idea to shipped code:
- Grill — the agent interviews you about your plan and records the decisions you make under questioning.
- Spec — the agreed conversation becomes a written specification.
- Tickets — the spec is split into chunks small enough for an agent to build without losing the thread.
- Implement — each ticket gets built test-first.
- Review — the diff is reviewed against both your standards and the original spec.
Around that spine sit supporting groups: shaping skills for open questions (mapping a large effort as a set of decisions, building throwaway prototypes to answer a design question, doing cited research from primary sources), upkeep skills for the boring health of a repo (bug diagnosis from a failing repro, triage, architecture reports), and a reference layer the other skills cite — module design vocabulary, domain modeling, the grilling interview itself, and the rules of red-green-refactor.
Read the list again and notice what’s missing: there is no skill called write the code. Four of the five steps happen before an agent touches the repo.
Four ideas worth stealing
1. Extract the decisions before you generate anything
There are two separate interrogation skills in the set, and one of them exists purely so other skills can invoke the interview. That is the thesis of the whole system: the bottleneck in AI-assisted development is not typing speed, it’s that you hand the agent an under-specified idea and it fills the gaps with plausible guesses. Every gap the agent fills silently is a decision you didn’t make.
Getting interrogated is uncomfortable, which is exactly why it works. A good grilling surfaces the three things you were hand-waving over, and you make those calls in a chat window instead of discovering them in a code review two days later.
2. Written artifacts are the interface between steps — not chat scrollback
Each step’s output is the next step’s input: a decisions record feeds a spec, the spec feeds tickets, the tickets feed implementation, the spec comes back for review. There’s also a handoff skill whose entire job is writing up a long session so a different agent can continue it.
This is the single most portable idea here, and you should adopt it even if you never install a skill. Context windows are not durable memory. The moment your project’s state lives only in a conversation you can’t resume, you’ve built something that only works while you’re holding it. Files in the repo survive compaction, model switches, and next Tuesday.
3. Give the agent the vocabulary, not just the task
The reference layer is the least flashy and most underrated part. Deep modules — narrow interface, substantial implementation — and a written domain vocabulary are old ideas from Ousterhout and DDD. What’s new is who the audience is. You’re not writing those docs for the next human on the team anymore; you’re writing them so the generator has a house style to conform to.
An agent with no architectural vocabulary produces code that works and reads like it was written by five different people. That’s the actual failure mode of fast AI development: not bugs, but drift.
4. TDD is the control loop, not a virtue
Implementation is test-first, and bug diagnosis starts from a repro that fails. This is not moralizing about test coverage. When your code generator is a machine optimized to produce plausible-looking output, a failing test is the cheapest available oracle for whether the plausible thing is also the correct thing. Write the check before the thing being checked, or you end up writing tests that agree with whatever the agent already produced.
Now the part nobody says out loud
This pipeline is a bet, and the bet has a price.
The ceremony tax is real. Five steps between idea and code is a process designed for work where being wrong is expensive — a data model you’ll live with for three years, an API other people depend on, anything touching money or auth. For a solo dev changing a form validation rule, running the full spine costs more than the change. The honest framing is that this is a gradient, not a default. Match the ceremony to the cost of being wrong. If you run it on everything, you’ll quietly stop running it on anything.
Up-front specification versus iteration is an unsettled question. The pipeline assumes that deciding more before generating produces better outcomes. That’s plausible and often true. But cheap generation genuinely changes the calculus — sometimes the fastest way to answer a design question is to build the thing badly and look at it, which is why a prototype skill exists in the set at all. Spec-first and probe-first are both legitimate strategies, and the pipeline mostly picks one.
Twenty-five skills is a lot of surface area. There’s a routing skill whose only job is telling you which skill to use for your situation. That’s a well-designed feature and a symptom: the set has outgrown what one person keeps in working memory. Most engineers will get 80% of the value from three or four of these and should resist collecting the rest.
And it’s one person’s process. These encode how Matt Pocock engineers — a TypeScript-heavy, library-and-teaching-oriented practice. That’s a good practice to learn from. It isn’t a neutral standard, and the skills read with more authority than any individual’s workflow has earned.
How I’d actually adopt this
Don’t install 25 skills. Do this instead:
- Take one real feature — something with genuine ambiguity in it — and run it through the full spine once. Time it.
- Compare that against how you’d normally ship the same feature by just talking to your agent.
- Keep the steps that changed the outcome. Drop the ones that only changed the paperwork.
My prediction: the grilling step and the written-artifact discipline earn their keep immediately, the spec-to-tickets split earns it only on work large enough to span sessions, and the rest is situational. But that’s a prediction, not a result — and the whole point of this approach is knowing the difference.
The skills are MIT licensed and the source is public, so the highest-leverage move is to read the skill files themselves rather than just running them. They’re short. What you’re actually reading is a senior engineer’s process written down in a form precise enough for a machine to follow — which, it turns out, is a pretty good format for humans too.
