Matt Pocock Skills Walkthrough: From Feature Request to Review

A practical Matt Pocock skills workflow is: discover the repository, settle the feature decisions, write a spec, implement one testable slice, and review the diff against that spec. Choose each procedure explicitly; a small feature does not need every skill in the collection.

This walkthrough uses a CSV export in an existing issue tracker. It is an illustrative worked example, not a feature we implemented or a report of passing tests. Prompts, decisions and artifacts below are proposed inputs and expected outputs.

For the collection overview, read Matt Pocock skills for Claude Code. The procedures here were checked against mattpocock/skills at commit 4ae2317, inspected November 6, 2026. Earlier guides describe earlier snapshots; names and behavior can change.

Start with one concrete feature request

Suppose the application already has a signed-in issue list with status filters and pagination. The request is:

Add an Export CSV action to the issue list. Export the issues matching the current filters. Keep the existing authorization rules. Follow the repository's existing download and testing patterns. Before coding, identify the relevant modules and unresolved behavior.

Give the agent the repository instructions, current branch context and relevant product notes. Have it inspect the issue-list route, authorization boundary, filter parser, existing download implementation and nearby tests. Ask for paths and a short explanation of each finding.

This discovery has a specific purpose: establish whether “current filters” already has a canonical representation. Duplicating filter logic in an export endpoint would create two definitions of the same product behavior.

The expected output is a small repository map plus open decisions. It should distinguish observed facts from proposed changes. If the agent cannot locate an authorization check, that is a question to investigate before creating a download route.

Use grill-with-docs to settle decisions

At this snapshot, grill-with-docs delegates to grilling and domain-modeling. The interview works through decisions in rounds; domain modeling captures resolved terminology and offers ADRs for consequential tradeoffs.

A useful input is:

Use grill-with-docs on this CSV export. Investigate repository facts yourself. Ask me the product decisions that remain. Clarify pagination, column order, empty results, permissions, large exports and spreadsheet safety before proposing implementation.

For this worked example, assume the human chooses:

Decision	Example acceptance contract
Which rows?	All matching issues the caller may view, beyond the current page
Which columns?	ID, title and status, in that order
Empty results	A valid file containing the header row
Encoding	UTF-8; escaping follows the project's established CSV convention
Large exports	Use an explicit server-side row limit and return an explained error when exceeded
Spreadsheet handling	Agree on treatment of formula-like text with the product and security owner

These are example choices, not claims that the skill supplies a secure CSV implementation. The row limit needs a concrete value justified by the application's constraints before coding begins. Spreadsheet handling needs an explicit policy rather than an assumption that quoting alone makes a cell safe.

Expected artifacts include resolved terms such as “filtered export” and, only if warranted, an ADR about synchronous versus asynchronous export. Do not manufacture an ADR for every minor choice. The upstream domain-modeling procedure reserves them for decisions that are hard to reverse, surprising without context and based on a real tradeoff.

Turn the conversation into a spec

Use to-spec after decisions are settled. It synthesizes the current conversation rather than starting another requirements interview.

Use to-spec to capture the agreed export behavior. Prefer the existing filtered-list boundary for tests. Identify what that boundary catches and misses, and confirm the testing seams with me before publishing the spec.

The procedure expects configured tracker instructions and triage vocabulary. Establish the destination first: a local tracker or an authorized issue tracker. Its template covers the problem, solution, user stories, implementation decisions, testing decisions and exclusions. It asks for confirmation of test seams and avoids brittle file paths in implementation decisions.

For this example, the spec should explicitly exclude saved exports, background jobs and new filter controls. Acceptance criteria should include permission failure, cross-user isolation, filter parity, pagination, empty results and escaping. A vague “CSV downloads correctly” criterion cannot distinguish a correct export from one that leaks records.

Choose bounded implementation or a ticket graph

For a feature that fits one focused change, use implement with the approved spec. It calls tdd where possible, runs typechecking and focused tests regularly, runs the full suite at the end and invokes code review. It also instructs the agent to commit on the current branch, so state any branch and commit constraints before invoking it.

If the feature needs separate deliverables, to-tickets creates vertical slices with blocking relationships. For example, the first slice could deliver an authorized filtered download with a minimal UI action. A second could improve the error experience and cover the agreed export limit. Each slice should be independently verifiable; “build the backend” and “build the frontend” leave partial behavior between them.

Use implement-spec only when its orchestration fits the task. It expects spec-linked tickets and coordinates fresh implementer subagents in separate worktrees, merging their work onto an integration branch. That is a different operational commitment from implementing one bounded change.

For a comparison of those process choices, see Superpowers vs Matt Pocock skills.

Apply tdd one behavior at a time

Matt's tdd procedure tests public behavior at pre-agreed seams. It rejects writing every test first and implementing everything afterward. At this snapshot, refactoring belongs to review rather than the red-green implementation cycle.

For the CSV example, start with one independently specified fixture: two visible matching issues, one nonmatching issue and one matching issue belonging to another user. The expected download contains exactly the first two records in the agreed format.

Observe that test fail for the intended missing behavior, implement the smallest slice, and rerun it. Then address the next behavior. A serializer-only test can check quoting; it cannot prove the endpoint applies authorization or exports beyond one page.

Expected evidence is the actual failing result, passing result and command output. No prompt can stand in for those observations.

Review and verify the result

The code-review skill separates documented repository standards from spec compliance. Supply a fixed comparison base and the originating spec. Its two review axes run in separate subagents.

A human should then inspect the real diff, download a fixture export, compare the records with the filtered list, and exercise the empty and denied cases. Open a representative file in the spreadsheet application the team supports. Record any unverified environment or format behavior in the handoff.

The final artifact is a reviewable change with requirements, relevant tests, verification output and remaining limitations. For work where preserving existing behavior is the main risk, use the skills guide for existing codebases.

FAQ

Do I need every Matt Pocock skill for a feature?

No. A bounded change may need discovery, a short clarified spec, implement and review. Add ticket orchestration when the work actually has separate dependent deliverables.

Does to-spec resolve unclear requirements?

It synthesizes the conversation. Resolve product ambiguity first; it separately asks you to confirm the proposed test seams.

Is this a tested CSV implementation?

No. It is a worked example showing procedure choices, expected artifacts and acceptance criteria. Your repository, implementation and actual verification determine whether the result is ready.