TL;DR: Matt Pocock's Skills repo has over 160,000 GitHub stars, and his core workflow fits into four commands: First, you let the agent interrogate you (grill-me), then you compress the answer into a Spec, slice it into tickets that each fit into a context window, and let it implement — but reviewed by a fresh subagent. The trick isn't intelligence, but process: The agent writes no code before you understand each other, and it doesn't evaluate its own work.
The Problem: The agent types faster than you think
Most AI coding projects don't fail because of model quality, but because design questions were never asked. Human and agent start in the chat window with a vague idea, the agent gets going, and twenty minutes later, a PR is created that nobody asked for — half-baked spaghetti code because no one thought through the design before the typing started.
Matt Pocock, known for his TypeScript courses, built a set of skills for exactly this: his personal .agents directory, made public at github.com/mattpocock/skills. It now has over 160,000 stars, millions of downloads — and recently, an official end-to-end tutorial to go with it.
The core mindset: Alignment before code. The agent is already smart. What's missing is a process that enforces the cognitive work that no one did beforehand.
Phase 1: grill-me — the automated, debate-loving rubber duck
Arguably the most popular skill in the repo consists of three sentences. It doesn't do anything spectacular: It asks the right question at the right time. Instead of going into planning mode, you let the agent grill you — one question at a time until both of you share the exact same understanding of the goal, constraints, and risks.
Before the AI era, this was called Rubber Ducking. The difference: The grilling process turns the rubber duck into a debate-loving duck that argues back, looks for gaps, and highlights assumptions you implicitly made.
The upgraded variant /grill-with-docs additionally maintains a CONTEXT.md with project vocabulary and uses Architectural Decision Records (ADRs) so non-obvious decisions are documented instead of just buried in the chat history.
Phase 2: to-spec — from discussion to artifact
After grilling comes the fork in the flow: If the work fits into one session, you go straight to implementation. If it requires multiple sessions, you compress the discussion with /to-spec into a Detailed Spec — outlining the goal, user stories, implementation, and testing decisions, written in the issue tracker, not in a chat message.
The spec is the anchor to which everything can be traced back later: every ticket, every review comment, every commit. Without this artifact, "done" is just a feeling.
Phase 3: to-tickets — one ticket per context window
/to-tickets slices the spec into pieces that each fit into one context window. Pocock's example from the tutorial: One spec turned into eleven sub-issues.
Why so strict? LLMs have a reliable "Smart Zone". The fuller the context, the more the agent forgets about conventions, edge cases, and previous instructions. A ticket that stays below this limit (roughly under ~140K tokens used context) is built more reliably than a mega-ticket that lives for three sessions in the bloated memory of a single conversation.
Important when slicing: The tickets should be vertical slices — a continuous functional cross-section instead of "first the DB, then the UI, then the tests". This way, every ticket is testable on its own.
Phase 4: implement — and above all: Review with fresh context
The /implement skill works on a ticket: Type checks, build, TDD at the previously agreed seams — and finally, /code-review, executed in subagents.
This is where most setups take the easy way out: The main agent reviews its own code — in the same exhausted context in which it wrote it. The result ranges from lenient to blind. A clean context reviews more honestly because it doesn't carry along any justification logic.
Pocock's code review therefore runs along two axes as parallel subagents that don't contaminate each other:
| Axis | Question | Reference |
|---|---|---|
| Standards | Does the diff adhere to coding standards and avoid classic code smells? | codingstandards.md in the repo + smell baseline |
| Spec | Does the code actually implement the original ticket/spec? | Original issue/spec |
In Pocock's own setup, the implementation subagents run in Sandcastle, his orchestrator for sandboxed coding agents. For everyday use, however, the flow works just as well with normal subagents — the principle is the clean slate, not the specific tool.
Setup in two commands
npx skills@latest add mattpocock/skills
/setup-matt-pocock-skills
The setup skill configures the issue tracker, triage labels, and document layout once per repo. After that, the flow runs in a fixed order: grill → (spec → tickets) → implement. For those who just want the essence: grill-me works completely on its own too — the three-sentence version costs zero infrastructure and is the single skill with the highest ROI.
The Flow at a Glance
| Phase | Command | Artifact | Duration |
|---|---|---|---|
| Alignment | /grill-me or /grill-with-docs | Shared understanding, CONTEXT.md | 10–30 Min |
| Compressing | /to-spec | Spec in the tracker | Once |
| Slicing | /to-tickets | Tickets of one context window each | Once |
| Building | /implement + /code-review | PR with fresh review | Per ticket |
❌ Not like this — ✅ like this
- ❌ Prompt in, code out, open PR — ✅ let it grill you first, answer questions, then Spec
- ❌ "Build the whole feature" in one chat — ✅ one ticket per context window
- ❌ Main agent reviews its own code in full context — ✅ fresh subagent, two separate axes
- ❌ Decisions only in the chat history — ✅ Spec and ADRs in the tracker, version by version
When the flow is overkill
To be fair: For a two-line fix or a throwaway prototype, the full four-phase train is too long. The flow pays off once a feature has to survive multiple sessions, other people (or agents) will continue working on it later, or you yourself won't remember tomorrow why you chose variant B. That is exactly what the repo is made for — "Skills for Real Engineers," not for prompt tinkering. For work that is bigger than an agent session can even hold, the repo incidentally also features /wayfinder — a map system of decision tickets on the tracker.
FAQ
Where do I start if the whole flow is too much for me?
With /grill-me alone. The skill consists of three sentences, needs no configuration, and immediately changes how you plan: The agent asks you one question after another until you have the exact same picture of the goal. The rest of the flow (spec, tickets, review) builds on this but can be retrofitted individually. If you take only one thing away from this article, you should let the agent grill you before starting the next feature instead of just firing off prompts right away.
Do I need Sandcastle or Pocock's exact toolchain?
No. Sandcastle is Pocock's own tool for orchestrating sandboxed coding agents, but the flow works with any agent setup that supports subagents or at least fresh sessions — Claude Code, Codex, OpenClaw, whatever. The transferable core is the rule "Implementation and review run in separate, fresh contexts," not the specific tool. Even the review part can be implemented primitively: open a new chat, paste the diff, and ask about the two axes.
How big should a ticket be at most?
As a rule of thumb: Including the codebase context and discussion, it must fit into a single context window while staying in the reliable zone of the model — roughly under 140K tokens used context, depending on the model even significantly less. A good sign is that you can finish the ticket in one session with passing tests. If a ticket sounds like "Phase 1 of 3," it's sliced too big — better to split it up again.
What is the difference between grill-me and grill-with-docs?
/grill-me is the fast variant: The agent asks questions, you talk until understanding is shared — done. /grill-with-docs conducts the same interrogation but maintains persistent artifacts: a CONTEXT.md as a glossary of your domain and Architectural Decision Records for non-obvious decisions. For one-off work, grill-me is enough; in a team repo with a history, the docs variant pays off by week two.
Why should a stranger review my code instead of the agent who wrote it?
Because the writing agent is biased and blind: Its context is full of the compromises and errors that led to the code, and models tend to judge their own performance favorably. A fresh subagent only sees the diff, standards, and spec — and reports smells more honestly, precisely because it isn't defending its own work. The two-axis approach (standards parallel to spec adherence) additionally prevents review comments from one channel from contaminating the other.
Does this only work with Claude Code or with other agents too?
The format (skills as SKILL.md files in the agent directory) is deliberately designed to be cross-tool and works in Claude Code, Codex, and other harnesses that load folder-based skills. The installer (npx skills add mattpocock/skills) places the files accordingly; /setup-matt-pocock-skills adapts the tracker and layout to your repo. The underlying model quality doesn't matter to the flow — after all, it specifically structures the process around the model.
Sources
- Matt Pocock: Skills Repo — https://github.com/mattpocock/skills
- Matt Pocock: End-to-End Workflow Tutorial (X) — https://x.com/mattpocockuk/status/2075218406266036236
- Matt Pocock: Workflow Tutorial (YouTube) — https://www.youtube.com/watch?v=M6mYodf0dJM
- Matt Pocock: Skills Changelog v1.1 (/wayfinder, /to-spec, /to-tickets, Code Review Axes) — https://www.aihero.dev/skills/skills-changelog-v1-1-wayfinder-to-spec-to-tickets-grilling-improvements
- Matt Pocock: AI Coding Workshop with Sandcastle (YouTube) — https://www.youtube.com/watch?v=-QFHIoCo-Ko
- Alex Rusin: "Matt Pocock Skills: The Main Flow Explained" — https://blog.alexrusin.com/matt-pocock-skills-main-flow
- Aditya Kumar Puri: "Matt Pocock's Claude Code Skills made me rewrite how I work with AI agents" — https://adityakumarpuri.medium.com/matt-pococks-5-claude-code-skills-made-me-rewrite-how-i-work-with-ai-agents-d71853c3056c
- Danny Shmueli: Subagents + Pocock Skills in Hermes — https://dannyshmueli.com/2026/04/29/Matt-Pocock-Skills-Hermes-Subagents-Feature-Work/