Matt Pocock's Skills Pack: A Grill, Spec, Ticket, Implement, Review Workflow

Vibe coding is great fun until the code has to face a real product. You describe a feature, the agent nods and produces a mountain of code, and a pull request shows up that looks very busy. Then the problems surface. The behavior isn't quite what the team had in mind, the explanation is full of jargon, an edge case breaks checkout, and the existing code has quietly become harder to change.

An agent writing bad code isn't the scary part, since people do that as well. The scary part is that an agent speeds up a misunderstanding. A fuzzy request turns into a large, convincing and expensive mistake.

Matt Pocock's skills repository is a practical response. Its README calls itself "Skills For Real Engineers": small instructions that can be invoked when a specific kind of help is needed. The idea isn't to hand the whole development process to a giant framework. It's to give an agent a handful of dependable moves for the moments where engineering judgment counts.

The agent earns its keep by putting the brakes on the dangerous stretches of a job first, and only then speeding up the typing.

What the pack contains

The repository is a set of composable skills for working with an agent inside an existing codebase. One skill questions an idea, another converts it into a spec, another splits the spec into tickets, and implementation and review each get their own focused skill.

That promise is smaller than "run the whole company through this methodology," and it's more useful. The repo keeps its own conventions, tracker, documentation and architecture, and the skills help the agent find its way around them.

A one-time setup per repository is needed. Install the pack with one of these two options, never both:

claude plugins install mattpocock-skills

or:

npx skills@latest add mattpocock/skills

Then run this once inside the repo:

/setup-matt-pocock-skills

During setup the agent learns the local layout, including the issue tracker, triage labels and documentation paths. It isn't a daily routine. It's context that would otherwise get rediscovered, guessed at or forgotten.

Why a prompt isn't enough, and a huge process isn't either

A prompt states a wish. It can't reliably carry all the decisions hidden inside one short product sentence.

"Add saved carts to the storefront" sounds clear until someone asks what a saved cart holds, who may see it, what happens when stock changes, whether prices get locked and where the feature belongs. A single prompt buries those questions under one command: build it.

The opposite reaction is a heavyweight process that claims to handle every project the same way. It swaps ambiguity for ceremony, even when the task is tiny or the repo already has a good routine. The process turns into the product.

This pack sits between the two. Focused skills target focused failure modes. An idea can be grilled, a durable spec can be written when one is warranted, and tickets can be shaped to fit the tracker in use. For a one-line typo, nearly all of that can be skipped. Compared with a framework that takes over the whole workflow, small skills are simpler to combine, read and swap out.

The failures it aims at

The README helps because it names specific failures and doesn't treat AI coding as one magical activity.

• Misalignment. The agent builds a plausible reading that isn't the intended one. grill-me interrogates the idea directly, and grill-with-docs brings the repository's documentation and domain context into the conversation.
• Wordy jargon. A reply may sound confident and still leave the product more confusing than before. The docs-oriented flow can record context in CONTEXT.md and in ADRs, and domain-modeling makes key concepts explicit so they don't dissolve into names like data, item or manager.
• Code that doesn't work. For test-driven implementation the workflow points to /tdd, and to diagnosing-bugs when a failing behavior needs investigation instead of another speculative patch.
• A ball of mud. When a feature fits nowhere, another abstraction isn't always the cure. to-spec, improve-codebase-architecture and codebase-design make the system's shape visible and help improve it on purpose.

A few routing and coordination skills round things out. ask-matt helps pick a path, wayfinder supports plans spanning several sessions, handoff preserves state, wait-what checks understanding and triage sorts out what should happen next.

The pipeline

The core flow chains five steps:

/grill-with-docs -> /to-spec -> /to-tickets -> /implement -> /code-review

Under the hood, /implement drives /tdd. Each step has one job, and its output gives the next step something concrete to work with.

1. Grill the idea

Begin with /grill-with-docs when a feature spans product and technical concerns. Describe what's wanted and ask the agent to challenge the assumptions using the repository's docs.

In the saved-cart example, the useful questions come before any code. Is a saved cart tied to an account? Can one customer keep several? Does restoring one recheck stock and price? Is it a snapshot or a pointer into the live catalog? Can it be shared? What does the user see when a product has been discontinued?

The goal isn't an endless interview. It's to surface the decisions that, if left open, would be made by the implementation by default.

When the idea is already well understood, the lighter grill-me is enough. If the agent starts using terms the team doesn't, ask for a CONTEXT.md, an ADR or a domain-modeling pass. Short shared vocabulary is worth more than a long reply.

2. Turn decisions into a spec

With answers in hand, run /to-spec. A spec states what the feature does, what it doesn't do, and how the existing system will recognize success.

Take a TypeScript storefront. Its spec could describe a saved cart as a named list that belongs to a logged-in customer. Only product IDs and quantities get stored, with no frozen prices or stock counts. On restore, availability is checked again, and lines that can't be fulfilled go through the error handling that already exists. Guests are asked to sign in.

That's far more valuable than "add saved carts." The team gets something concrete to review, and the agent gets boundaries. If public sharing isn't in the spec, nobody should read that as an invitation to invent it. A spec makes important decisions reviewable before they turn into code.

3. Turn the spec into tickets

Run /to-tickets once the spec is stable enough to divide. Tickets should describe slices that can be built and reviewed, and not a list of vague departments. One reasonable way to slice this feature:

1. Domain model and storage layer for carts that belong to logged-in customers.
2. Commands plus validation covering save, list, rename, delete and restore.
3. A restore step that checks stock and today's prices again.
4. Storefront screens, including loading, empty and error states.
5. Integration tests for access rules, missing products and a clean restore.

The ticket format should follow the repo's tracker and conventions, which is one reason the setup command matters: the skills can use the project's tracker, labels and docs paths. Tickets also work as a natural stopping point. Maybe the first release needs only save and restore. Cutting scope here beats cutting it after implementation.

4. Implement with tests in front

Now run /implement. It drives /tdd, so the agent starts from observable behavior, writes a failing test, makes the smallest change that passes and keeps the suite involved as it works through the tickets.

In the storefront case, that translates into three tests: a logged-in customer can save a cart, a different customer can't read it, and restoring a cart rejects any line whose product has disappeared. The code should stay within the repository's current domain and persistence boundaries. A second, parallel cart abstraction isn't needed merely because the prompt mentioned a "saved cart."

If a test fails, don't ask for random edits until the red turns green. Use diagnosing-bugs to investigate. Think of a failing test as evidence about the system and not as a hurdle on the way to a green checkmark.

Sometimes the work shows the spec was mistaken. Then the right move is to return to it, because nothing forces this workflow to run in a straight line. The aim is to keep decision, ticket, test and code telling the same story, not to protect whatever was written first.

5. Review the result

Finish with /code-review. It's more than a style check. Reviewers look for agreement between behavior and spec, tests that actually cover the cases that matter, respect for the architecture already in place, and a public surface kept as small as possible.

A solid review could uncover restore logic that belongs in a checkout service already in the codebase, a list endpoint missing its authorization check, or a UI that lets people buy a product that's no longer available. It might also find that the feature is correct while the module boundary got harder to follow. That's when improve-codebase-architecture or codebase-design can help as a follow-up, rather than as a ritual imposed on every change.

The final review protects the codebase from a feature that passed only its own narrow tests.

What sets it apart

The workflow separates kinds of thinking that agents tend to blur. Clarifying a product decision isn't designing a module, designing a module isn't writing a test, and a passing test doesn't prove the feature belongs in the current architecture.

Judgment stays in human hands. You can halt after the grilling, rewrite the spec, throw out a proposed ticket split, or let ask-matt suggest the right skill. wayfinder covers multi-session plans, handoff keeps context, wait-what checks a confusing request and triage picks the next piece of work.

That fits real engineering better than a prompt saying "be a senior developer." The agent gets repeatable behaviors without pretending that expertise is a personality trait.

When to skip it

For a one-line typo, a small copy change or a throwaway local experiment, the whole thing is overkill. Setup has a cost even if it's only paid once per repo, and deliberate pauses aren't free when the change is truly trivial.

Use common sense. Changes that touch business rules, module boundaries, stored data, permissions or a public API justify the pause, since it costs less than cleaning up after a confident misunderstanding. Everything else can take the shortcut.

Starting small works fine. Pick one install route, run /setup-matt-pocock-skills in a real repository, and try /grill-me on the next feature that seems clear but really isn't. When a change earns the full path, extend the run through /grill-with-docs and on to specs, tickets, /implement and /code-review.

The benefit isn't a higher line count per hour. Fewer wrong assumptions end up in the code to begin with. That's a far less glamorous promise than vibe coding, and it's the one that still holds up once the store is live and a different engineer inherits whatever the agent left behind.