Matt Pocock's AI Coding Skills: Grill, Spec, Ticket, Ship

Direct Answer

Matt Pocock's skills improve AI coding by moving judgment to the cheapest stage of the workflow. Instead of letting an agent jump from a vague request to finished code, the skills create a chain of reviewable artifacts: clarified decisions, shared vocabulary, a specification, executable tickets, tested implementation, and an independent code review.

The most important skill is not a longer prompt. It is the handoff between stages. Each artifact lowers ambiguity for the next agent or context window. That makes the workflow easier to inspect, parallelize, pause, resume, and correct before mistakes become expensive code.

Watch the Interview and Credit the Creators

This article is based on Andrew Warner's interview with Matt Pocock and the current mattpocock/skills repository. The repository has changed since the recording, so current command names and installation guidance below follow the official source rather than freezing the demo at one commit.

The Core Idea: Pre-Alignment Is Cheaper Than Rework

Coding agents default to high fidelity. Give one a feature idea and it often creates the route, components, state, database changes, tests, and styling immediately. That feels productive because there is something visible to inspect. It also makes every misunderstood requirement expensive to reverse.

Matt's alternative is to begin at low fidelity. Resolve the design in text. Move to diagrams or a throwaway prototype only when they answer a specific question. Commit to production implementation after the scope, users, failure modes, constraints, and definition of done are clear enough to review.

Andrew gives a useful example: a tool that finds unusually successful YouTube videos needs a changing baseline for each channel. Building the interface before defining how the baseline is collected and updated can produce a convincing product around the wrong data model. Five minutes of questioning can surface that requirement before a month of assumptions accumulates around it.

The Full Skill Chain

This is a menu of composable tools, not a ceremony every task must complete. The workflow should be proportional to the uncertainty and blast radius. A copy change does not need a project graph. A multi-month feature should not live only in one chat transcript.

Grill Me: Resolve the Design Tree Before Building

grill-me turns the agent into an interviewer. It asks focused questions, recommends options where useful, records the answer, and continues until the unresolved branches of the design are closed. For a security review, those branches might include the adversary, protected assets, trust boundaries, deployment model, out-of-scope systems, acceptable evidence, and expected deliverable.

The interview is valuable because the agent cannot infer priorities that exist only in the user's head. It may understand OAuth, databases, and threat modeling, but it does not know whether this review is preparing an internal beta, a regulated launch, or a public security claim. The same code can require different depth under each goal.

A good grilling session follows four rules:

1. Ask only questions that change the design, scope, risk, or evidence.
2. Recommend a default and explain the tradeoff rather than presenting an endless menu.
3. Keep an explicit list of unresolved decisions.
4. End with a compact agreement that another context can understand.

The current repository separates the user-invoked grill-me entry point from the model-invoked grilling discipline. That is a useful skill-design pattern: the command stays small, while a reusable primitive holds the interview behavior shared by several workflows.

Grill With Docs: Build Shared Vocabulary as You Decide

grill-with-docs extends the interview into durable domain context. It can update a glossary, a CONTEXT.md file, and architecture decision records while the user and agent resolve the design.

Shared vocabulary is a compression system. If everyone knows one project-specific term, prompts, filenames, types, functions, issues, and reviews can use that term instead of repeating a paragraph. The gain compounds across sessions because future agents can decode the same language from the repository.

Only record language that is stable and useful. Do not turn every conversation into permanent doctrine. Put changing facts in their source system, temporary implementation notes in the ticket, durable domain terms in the context file, and consequential architectural choices in a decision record.

To Spec and To Tickets: Make Work Portable

To Spec captures the agreement

to-spec synthesizes what has already been discussed into an implementation contract. It should describe behavior, scope, affected modules, constraints, interfaces, failure cases, test strategy, migration needs, and acceptance evidence. It is not another interview. If important decisions remain open, return to alignment instead of hiding uncertainty in a polished document.

To Tickets creates tracer-bullet slices

to-tickets breaks a spec into independently reviewable vertical slices and declares the blocking edges between them. A ticket should produce visible progress through the system, not merely complete one technical layer. "Add the database" is weaker than "persist a draft, retrieve it through the API, and prove the save-and-reopen flow."

Tickets are the bridge across context limits. One agent can plan the feature, several agents can implement non-conflicting slices, and another can review the final integration without depending on the original chat. The issue tracker becomes the state layer.

Implement and Code Review: Close the Loop With Evidence

The current implement skill builds from a spec or ticket set, invokes test-driven development at agreed seams, and closes with code-review. This is stronger than asking one long-running agent to code and declare itself finished.

The repository's review model separates two questions:

• Standards review: does the diff follow repository rules, engineering standards, and common code-smell checks?
• Spec review: does the implementation faithfully deliver the originating requirement?

Running those as distinct review perspectives reduces the chance that a stylistically clean change passes while solving the wrong problem. The review should inspect the diff from a fixed point, run the repository's checks, and lead with actionable findings. Passing tests are evidence, not proof that the product behavior is correct.

Why Specs and Tickets Matter More With Multiple Agents

The interview demonstrates how large projects can span several Claude Code tabs, fresh context windows, or agents orchestrated by systems such as Sandcastle. The useful pattern is not simply "run more agents." It is to make every worker consume a stable contract and return an inspectable result.

Parallelism is appropriate when tickets own different files or clean interfaces and have explicit dependencies. It is harmful when several agents edit the same subsystem, rely on unstated shared assumptions, or discover architecture independently. More workers increase merge and coordination cost unless the work graph is ready.

1. Freeze the accepted spec before fan-out.
2. Create tickets with dependency edges and ownership boundaries.
3. Give each agent a fresh context plus the same repository rules.
4. Require tests and a structured completion receipt from each slice.
5. Integrate serially where shared state or migrations make order important.
6. Run a final review against the original spec, not only individual tickets.

Clearing context between tickets can reduce accumulated confusion. It works only when the durable artifacts contain what the next context actually needs.

Writing for Agents: Use Pointers and Progressive Disclosure

writing-for-agents treats skills, AGENTS.md, CLAUDE.md, and linked repository documents as executable context. The goal is not beautiful prose. It is predictable retrieval and behavior.

Keep the entry document short. State the trigger, invariant, and route to deeper material. Put detailed examples, vendor-specific instructions, and large reference tables behind explicit pointers. This avoids loading every rule into every task while keeping the information discoverable when relevant.

No-Ops and Skill Pruning

Agent instructions accumulate. Someone adds a warning after one failure, another person restates it elsewhere, and soon the skill contains duplicated or contradictory guidance. Matt calls attention to no-ops: instructions that sound important but do not change the model's decision or output.

Test every line with four questions:

1. What behavior changes if this line is removed?
2. Is the meaning already expressed in a stronger place?
3. Can the instruction be checked in the output or execution trace?
4. Does it belong in this skill, the repository rules, or a linked reference?

Replace "be careful" with the action that demonstrates care. Replace "write high-quality tests" with the required test seam, failure-first behavior, and command. Keep each meaning in one authoritative place and point to it from the others.

Teach: A Stateful Learning Workspace

The teach skill applies the same artifact-first logic to education. It uses the current directory as a persistent learning workspace, researches primary material, structures lessons, records what the learner understands, and adapts future sessions around that state.

A useful teacher should not merely generate an explanation. It should diagnose the learner's current model, choose an exercise, collect an answer, identify the misconception, and update the next lesson. Primary sources matter because the teaching agent must first learn the subject accurately. Persistent notes matter because the learner should not need to re-explain their background every session.

Choose an Installation Model Deliberately

Claude Code: managed plugin

claude plugins install mattpocock-skills

The plugin installs the full set as a managed, read-only package and receives upstream updates. Choose it when you want Matt's maintained version and are comfortable reviewing changes as a dependency.

Codex and other compatible agents: editable files

npx skills@latest add mattpocock/skills

The installer lets you select skills and copies them into files you own. Include setup-matt-pocock-skills, then run it once per repository to configure the issue tracker, triage labels, and documentation location. Choose this model when you need to edit, pin, audit, or adapt the process.

A Seven-Day Rollout for One Real Feature

1. Day 1: install one way, run setup, and choose a feature with genuine ambiguity but bounded risk.
2. Day 2: run Grill Me. Record unresolved decisions and stop before implementation.
3. Day 3: use Grill With Docs if the feature exposes missing terminology or durable architectural choices.
4. Day 4: produce the spec. Have a human check scope, behavior, exclusions, migration, and evidence.
5. Day 5: create tickets only if the work exceeds one context or benefits from parallel slices.
6. Day 6: implement one tracer bullet with tests. Measure correction time and context needed.
7. Day 7: run the two-axis code review, fix findings, and prune instructions that did not change behavior.

Compare the result with a recent feature of similar size. Track planning minutes, implementation time, review findings, rework, escaped defects, context restarts, and human correction time. The workflow earns its place when a small amount of early alignment removes more expensive downstream work.

Video Chapters

Verdict

Matt Pocock's repository is popular because the skills encode familiar engineering disciplines in forms coding agents can actually invoke. The durable advantage is not one clever markdown file. It is the movement from conversation to artifacts: questions become decisions, decisions become a spec, the spec becomes executable slices, and implementation returns evidence for review.

Use skills to preserve human judgment, not to hide it behind automation. Align before building. Keep vocabulary durable. Make tickets portable. Separate implementation from review. Prune instructions that do nothing. When the workflow is explicit enough to survive a fresh context, it becomes useful to humans and agents at the same time.

Sources and Credits

• Andrew Warner interviews Matt Pocock: Matt Pocock Built the Skills Repo Every AI Coder Is Using
• Matt Pocock: Skills for Real Engineers
• Grill Me skill
• Grill With Docs skill
• To Spec skill
• To Tickets skill
• Implement skill
• Code Review skill
• Writing for Agents skill
• Teach skill