Matt Pocock’s AI Coding Skills: A Complete Workflow From Idea to Production-Ready Code

You ask an AI coding agent to build a team invitation feature. You expect it to clarify the requirements, inspect the existing application, design the implementation, write tests, and deliver code that fits your architecture.

Instead, it starts writing React components and API routes. Halfway through, it discovers that the application handles permissions differently from what it assumed. It changes the database model, introduces unnecessary abstractions, and produces a feature that looks finished but misses an important requirement.

You can keep prompting the agent to fix these problems. Or you can change the process that led to them.

That is the idea behind Matt Pocock’s skills repository. It provides reusable instructions for AI coding agents, helping developers apply engineering practices throughout a coding session.

The engineering workflow we will explore moves through six stages:

Each stage has a defined responsibility. Together, the skills provide a practical way to use AI coding agents without handing over your engineering judgment.

Matt Pocock’s skills is an open-source collection of instructions for coding agents such as Claude Code and Codex.

The repository follows an important design choice: skills are small and composable. Developers can invoke individual skills when needed and adapt their workflow instead of committing to one large, rigid development framework.

The skills also distinguish between two ways of working:

The six skills covered in this article form a useful development workflow. The accompanying /ask-matt skill helps you choose the appropriate path when the next step is unclear.

Source: grill-with-docs

Most feature requests leave unanswered questions.

Suppose you ask an agent to implement team invitations. Should invitations expire? Can an invited person already belong to another team? Who can send invitations? What happens when someone accepts an expired invitation?

A coding agent can make assumptions about every one of these decisions. The resulting implementation might be internally consistent while still being wrong for your product.

The grill-with-docs skill starts with a grilling session. It uses the /grilling process alongside domain modeling to sharpen the plan and build a shared understanding of the project.

The discussion helps establish terminology, uncover unresolved decisions, and document architectural choices. The repository describes this process as maintaining a project glossary and Architecture Decision Records (ADRs).

Why does that matter?

Imagine that your application has three concepts: an organization, a team, and a workspace. If the agent uses these terms interchangeably, it may create the wrong relationships or put authorization logic in the wrong place.

A shared vocabulary gives the agent a consistent way to reason about the existing system.

ADRs preserve decisions that might otherwise disappear when a conversation ends.

Start in your project directory and invoke:

Describe the feature you want to build. Let the agent investigate the codebase, ask questions, challenge assumptions, and document decisions as the discussion progresses.

For a substantial feature, this is where you should spend time. The decisions made here determine the quality of every subsequent stage.

The objective is to resolve uncertainty before it turns into code that needs to be rewritten.

Source: to-spec

Once the requirements are settled, you need a durable specification.

The to-spec skill takes the current conversation and the codebase understanding, then creates a spec and publishes it to your configured issue tracker.

The important distinction is that it synthesizes decisions already made. It is not intended to restart the interview or invent new product decisions.

Its specification covers:

One particularly useful detail is its focus on test seams. A test seam is an interface or boundary where behavior can be verified without depending too heavily on internal implementation details.

For example, an invitation workflow might expose a single service interface that tests can exercise. Its internal database queries could change later without forcing the tests to follow every implementation detail.

Use it after the discussion has produced enough agreement to write a specification.

The result becomes the reference for the implementation and later code review. It also reduces the chance that a developer and an AI agent remember different versions of the requirements.

You do not need a formal spec for every task. According to the repository’s /ask-matt guidance, a change that fits comfortably in one session can go straight to implementation once its decisions are settled.

The spec-and-ticket path is most useful when work needs to span multiple sessions.

Source: to-tickets

A specification can describe a feature correctly and still be too large for one coding session.

Consider implementing team invitations. The feature might require a database change, an invitation API, email delivery, a user interface, and authorization checks.

Giving an agent the entire specification in one request creates a large task with many dependencies and plenty of room for mistakes.

The to-tickets skill splits the work into tracer-bullet vertical slices.

Each ticket should deliver a narrow but complete behavior through the relevant layers, including the data model, API, UI, and tests where necessary. It should be independently demonstrable or verifiable and small enough for a fresh context window.

For example, a sequence might look like this:

This is an illustrative breakdown, not a prescribed ticket list. The actual order depends on your application and the decisions made during planning.

The skill also records blocking edges: the tickets that must be completed before another ticket can begin.

That dependency information prevents an agent from starting work that relies on unfinished functionality.

Before publishing tickets, the skill asks you to review the proposed breakdown. You can request smaller tickets, merge related work, or correct dependencies.

Review the proposed tickets before approving them. The skill can publish them to your configured tracker or create local ticket files, depending on your setup.

One useful exception: large mechanical refactors sometimes need an expand-and-contract migration rather than ordinary vertical slices. The skill accounts for those cases instead of forcing every change into the same ticket shape.

Source: implement

This is where the agent writes the code.

The difference is that implementation now starts with a clear specification or a well-defined ticket instead of a vague feature request.

The implement skill instructs the agent to use test-driven development (TDD) where possible, at previously agreed test seams. It also calls for regular type-checking, frequent execution of individual test files, and a full test-suite run at the end.

Once the work is complete, it invokes code review and commits the changes to the current branch.

Give it the relevant ticket or specification, following the workflow your repository has configured.

For a multi-ticket feature, each implementation session starts with a specific ticket. The agent can concentrate on one deliverable without carrying the entire project’s planning discussion into every new session.

For a small change, you can use the same skill directly after clarifying the requirements, without going through the full spec-and-ticket process.

AI-generated code can compile and still fail to meet the required behavior.

TDD helps make the expected behavior explicit. The agent writes a test for a behavior, sees it fail, implements the behavior, and then verifies that the test passes before moving forward.

This is especially useful for edge cases involving permissions, validation, or state transitions. The test results give the developer concrete evidence to inspect instead of relying on the agent’s description of what it built.

Of course, passing tests do not prove the feature is correct. They prove only what the tests actually cover.

Source: code-review

A feature can satisfy its requirements and still introduce poor design. It can also follow every project convention while implementing the wrong behavior.

The code-review skill treats these as separate review concerns.

The first review checks whether the changes follow the repository’s documented coding standards. It also examines common code smells, such as duplicated logic, unclear names, speculative abstractions, and modules that change for unrelated reasons.

These code smells are review heuristics, not automatic violations. Documented project standards take precedence over the general smell baseline.

The second review checks whether the implementation matches the originating specification.

It looks for missing or partially implemented requirements, behavior that was never requested, and implementations that appear to satisfy a requirement but do so incorrectly.

The skill runs these two reviews in parallel using separate subagents, then reports their findings under separate headings.

This separation matters. A beautifully structured implementation can still be functionally wrong. A correct implementation can also disregard the project’s architecture.

The implement workflow invokes code review when its work is complete. You can also use /code-review independently when reviewing a branch or pull request.

The review needs a fixed comparison point, such as a commit SHA, branch, or merge base. It uses that point to establish the changes being reviewed and attempts to locate the originating specification.

A useful AI review should tell you what is wrong, where it is wrong, and which requirement or standard the finding relates to.

Source: retro

Most development workflows end when the code has been reviewed and committed.

The retro skill looks at the coding session itself and suggests ways to improve future runs. Its output focuses on the agent's working environment rather than automatically changing the feature that was just built.

It examines areas such as:

The skill also distinguishes mechanical errors from judgment calls. If a coding standard can be enforced deterministically through a linter, pre-commit hook, or CI check, that is generally preferable to adding another prose instruction.

For example, if the agent repeatedly imports modules from disallowed locations, a lint rule can prevent the mistake from recurring. A paragraph in AGENTS.md may not be enough.

The skill reviews the session and presents improvement candidates in order of severity.

Evaluate those suggestions before changing your repository configuration. Not every inconvenience deserves a new rule, and too many instructions can make an agent’s working context harder to navigate.

The long-term benefit comes from turning recurring problems into better tooling, clearer documentation, or more useful standards.

The main workflow is easier to understand when you see the handoffs:

The sequence comes from the repository’s documented workflow. It does not mean every task needs all six stages.

A one-line bug fix may need a focused test and review. A multi-session feature benefits from the full sequence. A large, unclear initiative may need an additional planning skill before the specification can be written.

The purpose is to match the process to the work.

Use /ask-matt

It acts as a router across the repository’s skills and workflows. Its guidance distinguishes between a feature that can be clarified in one session, work that needs a spec and tickets, and a much larger initiative whose decisions are still unclear.

It also describes other entry points, including triage for incoming issues and disciplined diagnosis for difficult bugs.

This is useful because the repository contains more than a single linear workflow. You do not need to memorize every skill before using it.

The repository documents two main installation approaches. Choose one rather than installing both.

For Claude Code, install the managed plugin:

For Codex and other supported agents, use the skills installer:

The installer lets you select the skills and coding agents to configure. Include setup-matt-pocock-skills, then run it once in the project to configure the issue tracker, ticket labels, and documentation locations.

Installation options can change, so consult the official repository README for the latest instructions.

Once configured, try the workflow on a feature that is large enough to benefit from planning but small enough to review carefully.

Matt Pocock’s engineering skills give AI coding agents a repeatable development process. They encourage developers to settle decisions before implementation, preserve requirements in a specification, divide large changes into verifiable tickets, test behavior, review code against two independent criteria, and improve the environment when a session exposes recurring problems.

They will not eliminate incorrect assumptions or guarantee production-ready software. The developer still needs to decide what the product should do, evaluate architectural choices, examine test coverage, and judge review findings.

What changes is how consistently those responsibilities are carried out.

The most useful AI coding workflow is one that makes decisions explicit, keeps changes small enough to verify, and gives the developer clear evidence to review.

I hope you found it helpful and informative. If you have any questions or feedback, feel free to leave a comment below. Your support and engagement mean a lot to me.