Matt Pocock's Skills: From grill-me to implement

Matt Pocock’s skills (mattpocock/skills, MIT) are a set of small Agent Skills built around one idea: agree on what to build before the agent writes code. grill-me interviews you until every decision is settled, then to-spec, to-tickets, implement (with tdd) and code-review turn that agreement into tested, reviewed commits. They run in Claude Code, Codex and Cursor.

You describe a feature in two sentences, the agent writes 300 lines, and only in the diff do you see that it understood something else. This page is for developers and tech leads who want that misunderstanding caught in a conversation, and who want a spec and tests to review instead of every line the agent wrote.

What you get from Pocock’s skill chain

• The install for each tool, including the companion skills that grill-me and grill-with-docs cannot run without.
• A full grill-me session transcript, so you know what a good interview looks like before you start one.
• The six-step workflow (idea, grill, spec, tickets, implement, review), with the artifact each step leaves for you to check.
• Four copy-paste prompts and a failure table with recovery steps, including the renamed skills that older articles still recommend.

Which skills are in the set, and what does each one do?

The skills split on one axis: who can start them. User-invoked skills (disable-model-invocation: true in their SKILL.md) run only when you type them; they orchestrate. Model-invoked skills can also be picked up by the agent when the task fits; they hold the reusable discipline. Several user-invoked skills are one-line delegates: grill-me contains only “Call the Skill tool with “grilling"", and grill-with-docs calls grilling and domain-modeling.

Skill	Started by	What it does	Reach for it when
grill-me → grilling	you	Interviews you in rounds, each question with a recommended answer, until no decision is left open	You cannot yet describe the change in two sentences, code or not
grill-with-docs → grilling + domain-modeling	you	The same interview, plus it writes settled terms to GLOSSARY.md and hard decisions to ADRs	You work in a codebase whose vocabulary the agent keeps getting wrong
to-spec	you	Turns the conversation into a spec on your issue tracker, after confirming the test seams with you. No new interview	Grilling is done and you want a durable record
to-tickets	you	Splits a spec into vertical-slice tickets with blocking edges, each sized for one fresh context window	The spec is approved
implement	you	Builds a spec or ticket, runs tdd at the agreed seams, then code-review, then commits to the current branch	A ticket is ready for the agent
tdd	agent or you	Red-green-refactor, one vertical slice at a time	Any change with a testable seam
code-review	agent or you	Reviews the diff since a fixed point on two axes, Standards and Spec, in two parallel subagents	Before you open or merge a PR
diagnosing-bugs (was diagnose)	agent or you	Builds a loop that goes red on the bug, then minimises, hypothesises, instruments, fixes and adds a regression test	A hard bug or a performance regression
improve-codebase-architecture	you	Surveys the codebase for “deepening opportunities”, shows them as an HTML report, then grills you on the one you pick	Every few days on a codebase agents edit heavily
triage	you	Moves issues and external PRs through triage labels and writes agent-ready briefs	Keeping a backlog the agent can pick from
prototype	agent or you	Builds throwaway code to answer one design question	You cannot judge a state model or UI on paper
handoff	you	Compacts the conversation into a handoff file in the OS temp directory	Before /clear, or to pass work to a fresh session
setup-matt-pocock-skills	you	Records your issue tracker, triage labels and docs layout for the other skills	Once per repository, before anything else

The repository keeps growing: on 2026-09-26 its README also lists ask-matt (a router over the other skills), implement-spec, wayfinder, research, retro, pr and others. This page covers the chain above; the discipline packs comparison sets the whole set against Superpowers, gstack and similar bundles.

Popularity, as of 2026-09-26: grill-me shows 1,225,243 all-time installs and grill-with-docs 1,046,834, second and third among development-practice skills. These counts come from the third-party LinklyAI/best-skills scrape of skills.sh (SECONDARY; skills.sh itself was not read directly), so re-read them on skills.sh before quoting them. The repository had about 269.8k GitHub stars on the same date. The README calls the two grilling skills “my most popular skills”.

Install Pocock’s skills in Claude Code, Codex and Cursor

The README offers two routes and warns you to pick one: the Claude Code plugin is a managed, read-only bundle that updates itself, while npx skills add copies editable files into your repository. Installing both leaves every skill listed twice.

Claude Code

The plugin mattpocock-skills is in Anthropic’s official marketplace, so there is nothing to add first. Run this in a terminal:

claude plugin install mattpocock-skills

Or, inside a session, /plugin install mattpocock-skills. Plugin skills are namespaced, so you type /mattpocock-skills:grill-me, /mattpocock-skills:to-spec and so on.

Check what the plugin costs you in every session:

claude plugin details mattpocock-skills

On 2026-09-26, version 1.2.3 with 25 skills projected about 1,609 always-on tokens (the skill names and descriptions). Skill bodies load only when a skill runs. The manifest on main now lists 27 skills, so re-run the command after an update, or compare /context before and after the install.

Codex

The README lists no native Codex plugin yet (a roadmap ADR, read 2026-09-26), so use the portable copy. Install each skill together with the skills it delegates to:

npx skills add mattpocock/skills \
  --skill grill-me grill-with-docs grilling domain-modeling \
  to-spec to-tickets implement tdd code-review setup-matt-pocock-skills \
  -a codex

Mention a skill with $ in the composer, for example $grill-me I want to add per-seat billing, or pick it from /skills.

Cursor

Use the same portable copy, targeted at Cursor:

npx skills add mattpocock/skills \
  --skill grill-me grill-with-docs grilling domain-modeling \
  to-spec to-tickets implement tdd code-review setup-matt-pocock-skills \
  -a cursor

Type /grill-me in Agent chat. If the skill does not appear in the menu, ask for it by name. Cursor’s skill loading was checked against vendor documentation only, not a local install.

Then run the setup skill once per repository, in any tool: /setup-matt-pocock-skills (/mattpocock-skills:setup-matt-pocock-skills with the plugin). It asks which issue tracker you use (GitHub, GitLab, local Markdown files, or a workflow you describe), and, if triage is installed, whether to keep the default triage labels (needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix) and where the glossary and ADRs live. It writes docs/agents/issue-tracker.md, docs/agents/domain.md and an ## Agent skills block in CLAUDE.md or AGENTS.md, and shows you the drafts before writing. to-spec, to-tickets and code-review read these files; without them they stop and tell you to run setup.

Every command above was checked on 2026-09-26 against claude plugin --help (Claude Code 2.1.286) and npx skills add --help (skills 1.7.0). Skills are third-party instructions: read how to vet a skill before you install it if your team has no policy yet.

What does a grill-me session look like?

The grilling skill maps your plan as a design tree. Each round it asks every question whose prerequisites are already settled (the “frontier”), numbers them, and gives a recommended answer for each. Your answers unblock the next round. Facts it can look up (files, schemas, tools) it sends a subagent to find instead of asking you; decisions it always puts to you. The session ends when the frontier is empty, and the skill does not act until you confirm you share an understanding.

Note

Older articles, and earlier versions of the skill, describe strictly one question at a time. The grilling/SKILL.md on main, read on 2026-09-26, asks the whole frontier per round. If your copy behaves differently, update it (npx skills update, or let the plugin update).

Here is a condensed session in Claude Code with the plugin. The skill’s own output marks questions and recommendations with icons; they are shown here as plain labels.

> /mattpocock-skills:grill-me I want to add per-seat billing to the team plan

I'm sending a subagent to read how subscriptions and entitlements are stored.
Questions that don't depend on that:

Q1 - Who pays for seats?
     Recommended: the team owner, one subscription with a seat quantity.
Q2 - What happens when a seat is removed mid-cycle?
     Recommended: no refund; the count drops at the next renewal.
     Proration credits add a second billing path you would have to test.
Q3 - Is there a minimum seat count?
     Recommended: one seat, the owner.

> Q1 yes. Q2 yes. Q3: minimum three seats; solo users stay on Pro.

The subagent reports one subscription row per user, no quantity column,
and entitlement cached in KV. Next round:

Q4 - Where does the seat count live?
     Recommended: a seats table, one row per member. To revoke access you
     need to know which members hold seats, not only how many.
Q5 - The owner downgrades below the number of members. Who loses access?
     Recommended: block the downgrade until the owner removes members.
     Choosing who loses access automatically creates support tickets.

> Q4 seats table. Q5 agreed.

[two more rounds: invitations, and when the KV cache is invalidated]

The frontier is empty. Decisions:
 1. Owner pays; one subscription with a seat quantity.
 2. Removal takes effect at renewal; no proration.
 ...
 9. KV entitlement is rewritten on every seat change, not on renewal only.
Nothing is left assumed. Confirm we share an understanding before I do anything else.

> Confirmed.

What to check in your own session: questions arrive numbered, each with a recommendation you can accept in a word; nothing the agent could look up is asked of you; no code is written; and the session ends with a numbered decision list and a request to confirm. That list is the first artifact you review, and it takes a minute to read.

Should you use grill-me or grill-with-docs?

Use grill-me when there is no codebase in play: a migration plan, a hiring decision, a talk outline. Use grill-with-docs when there is a codebase, because it adds the domain-modeling discipline to the same interview:

• It challenges your terms against the glossary: “Your glossary defines ‘cancellation’ as X, but you seem to mean Y. Which is it?”
• It proposes one canonical term for a fuzzy one (“account”: the Customer or the User?).
• It checks your statements against the code and surfaces contradictions.
• It writes each settled term to GLOSSARY.md the moment it is resolved (per-context GLOSSARY.md files under a root GLOSSARY-MAP.md in a monorepo).
• It offers an ADR in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. If any of the three is missing, it skips the ADR.

The payoff is shorter prompts and consistent names. The README’s example: “a lesson inside a section of a course is made ‘real’ (i.e. given a spot in the file system)” becomes “the materialization cascade”, and the code uses the same words. GLOSSARY.md holds definitions only, never implementation detail; Domain-Driven Design with AI assistance covers the discipline behind it, and architecture decisions agents can follow covers ADRs.

Workflow: from idea to reviewed commit with Pocock’s skills

This is the chain the README describes. Each step leaves an artifact that you check instead of reading the code. Run it on a feature branch or in a worktree, because implement commits to the current branch.

1. Grill. Run /grill-with-docs with the idea in one sentence. Answer each round until the frontier is empty, then confirm. Artifact: the numbered decision list, plus GLOSSARY.md and any ADRs.

2. Spec. In the same session, run /to-spec. It explores the repository, proposes the test seams (preferring existing ones, ideally one), checks them with you, and publishes a spec with user stories, implementation decisions, testing decisions and an out-of-scope list, labelled ready-for-agent. Artifact: one issue (or file) that you or a product owner approve.

3. Tickets. Run /to-tickets on the spec. It proposes vertical slices, each demoable on its own and each listing what blocks it, and asks whether the granularity and the blocking edges are right. Approve or adjust, then it publishes them: native issues with blocking links on GitHub or GitLab, or one file per ticket under .scratch/<feature-slug>/issues/ for a local tracker. Artifact: the ticket list.

4. Implement one ticket per fresh session. Start a new session and run /implement with one ticket. It uses tdd at the agreed seams, typechecks and runs single test files as it goes, runs the full suite at the end, runs code-review, and commits. Take the next unblocked ticket in the next fresh session; each ticket was sized to fit one context window.

5. Review. implement already ends with code-review; run it again on the whole branch before you open the PR: /code-review main. The Standards subagent checks your documented standards plus a baseline of Fowler code smells; the Spec subagent reports what is missing, what was not asked for, and what looks wrong, quoting the spec line for each finding.

6. Ship through your normal gates. Open the PR and let CI, your review bot and a human reviewer run as usual. The skills produce evidence for those gates; they do not replace them.

Copy-paste prompt: start a grilling session on a feature

/grill-with-docs We need to let one lesson belong to more than one course. Today a lesson has a single course_id. Look up anything you can find in the code yourself; ask me only for decisions. Challenge any term I use that is not in GLOSSARY.md, and propose an ADR only if the decision is hard to reverse.

Copy-paste prompt: turn the grilled plan into a spec with one test seam

/to-spec Use the decisions we just confirmed. Propose the single highest test seam you can find for this feature and check it with me before writing. Put anything we explicitly deferred under Out of Scope, and do not include file paths.

Copy-paste prompt: implement one ticket in a fresh session

/implement Ticket 02 in .scratch/multi-course-lessons/issues/. Work only on this ticket; if it needs something another ticket owns, stop and tell me. Write the failing test at the seam named in the spec first and show me it failing. Before you commit, paste the output of the typecheck and the full test suite, then run /code-review against main.

Copy-paste prompt: review the whole branch against the spec

/code-review main. The spec is the issue linked in the first commit message. In the Spec report, list every user story from the spec as implemented, partial or missing, with the test that covers it. Treat any behaviour not in the spec as scope creep, even if it looks useful.

In Claude Code with the plugin, prefix each command with mattpocock-skills: (for example /mattpocock-skills:to-spec). In Codex, replace the leading / with $.

How do you verify the result without reading every line?

The chain moves your attention from the diff to three short artifacts and two automated checks:

What you check	What it proves	Who signs off
The decision list at the end of grilling	The agent understood what you meant	You, before you confirm
The spec, especially the user stories, testing decisions and out-of-scope list	The right thing will be built, and how it will be tested	Tech lead or product owner, on the issue
The ticket breakdown and its blocking edges	Each slice is small enough to verify on its own	Whoever approves to-tickets
Red-then-green test output at the agreed seams, plus typecheck and full suite output	The behaviour exists and nothing else broke	CI, from the same commands
The two-axis code-review report	Every spec line is implemented, nothing extra was added, standards hold	The PR reviewer, who reads the report and the tests at the seam

Ask for the red run explicitly (the third prompt does): a test you never saw fail proves nothing. The spec line quoted in each review finding is your audit trail back to the decision list. For the test and review skills in depth, see skills that make agents test and debug properly and code review inside the agent.

When should you use the rest of the set?

With the portable copy (Codex or Cursor), add these skills first: npx skills add mattpocock/skills --skill diagnosing-bugs improve-codebase-architecture codebase-design triage prototype handoff -a codex (or -a cursor).

• diagnosing-bugs for a bug you cannot yet reproduce on demand. Its first phase is a feedback loop that goes red on this bug; do not let it skip to a fix. Example: “The invoice total is off by one cent for some EUR orders. Diagnose it.”
• improve-codebase-architecture every few days on a codebase agents change heavily. The README calls it “a survey, not a rescue”: it finds candidates, and you pick one to grill through. Example: /improve-codebase-architecture focus on src/lib/subscription.
• triage once setup-matt-pocock-skills has recorded your labels. It moves issues through those labels, grills when an issue is unclear, and writes briefs an agent can pick up.
• prototype when a design question needs something you can click. The code is meant to be thrown away; if a snippet encodes a decision precisely, to-spec may inline it and note that it came from a prototype.
• handoff before /clear or at the end of a long grilling session: /handoff finish the seat-billing tickets. The file goes to the OS temp directory, not your repository, so copy anything you want to keep. Skills for context and token discipline compares it with other ways to reset a session.

What breaks with Pocock’s skills, and how do you recover?

Symptom	Cause	Recovery
/grill-me replies but never interviews you	Only the delegate was installed; grilling is missing	Install the target too: npx skills add mattpocock/skills --skill grill-me grilling. grill-with-docs also needs domain-modeling; improve-codebase-architecture needs codebase-design and grilling
The installer shows a picker, or installs every skill in the repository	--skill=grill-me with an equals sign: skills 1.7.0 ignores that token, and with -y selects everything	Use --skill grill-me (space) or mattpocock/skills@grill-me. Remove extras with npx skills remove
“No matching skills” for to-prd, to-issues or diagnose	Renamed; the old folders return 404 on main, although skills.sh still shows their old install counts	Use to-spec, to-tickets and diagnosing-bugs
Every skill appears twice in Claude Code	Both the plugin and the npx skills copy are installed	Keep one. Remove the copy with npx skills remove, or uninstall the plugin
/code-review in Claude Code runs a different review	Claude Code bundles its own /code-review skill; a portable Pocock copy installed with -a claude-code competes for the bare name	Use the plugin and type /mattpocock-skills:code-review
to-spec or to-tickets stops and asks you to run setup	docs/agents/issue-tracker.md does not exist	Run /setup-matt-pocock-skills once, then repeat the command
The agent writes CONTEXT.md while the README talks about GLOSSARY.md	An older copy of the skills; CONTEXT.md was the earlier convention	Update the skills, then rename the file so both old and new sessions find one glossary
Grilling runs for many rounds and the session gets slow	Large feature, long context	Accept recommendations in bulk (“accept your recommendations for Q7 to Q10”), or run /handoff and continue in a fresh session with the decision list
implement commits to main	It commits to whatever branch is checked out	Start from a feature branch or worktree; if it already happened, move the commits with git branch feature-x && git reset --hard origin/main && git switch feature-x, but only after checking that git status is clean and nothing else is unpushed

Where to go next with Pocock’s skills

Discipline packs compared Pocock's chain as a framework, next to gstack, agent-skills, Ponytail and ECC, with their context costs.

Superpowers The heavier alternative: a design gate, plans and TDD that fire automatically from a session-start bootstrap.

Spec-driven development Keep the spec that to-spec writes authoritative as the code changes.

Build: plan.md, then implement Where plan mode fits after grilling: a gated plan once you and the agent agree on what to build.

Installing and managing skills The skills CLI in depth: scopes, updates, removal and the traps behind the table above.

The most-installed practice skills Where grill-me and the rest of the set rank, with install lines for each tool.