Matt Pocock Skills — The Main Flow

Matt Pocock’s official end-to-end tutorial for his skills repo (162k stars, 7.5M downloads as of July 2026) — the first time he documented the sequence the skills are meant to run in. This note captures the workflow; Matt Pocock Skills Overview covers what the framework is; the video itself is linked below.

Video: https://www.youtube.com/watch?v=M6mYodf0dJM (17:17, published 2026-07-16)

The main flow at a glance

Matt-Pocock-Skills-Main-Flow.svg

Everything outside this flow is what he considers experimental.

The organizing principle: the smart zone

Pocock treats ~140k tokens as the end of the context window’s “smart zone” — past it, attention degrades and hallucinations increase, so he budgets sessions against ~100k of working room rather than the advertised window. Every structural element of the flow exists to serve this:

  • Grilling front-loads alignment while context is cheap and fresh.
  • The spec is the destination — problem statement, user stories, implementation and testing decisions. It compresses a 46k-token discussion into a document a future session can load cheaply.
  • Tickets are the route — each deliberately sized to one context-window session. His real example: one spec, 11 sub-tickets, 11 sessions. Ticket count is negotiable (“do it in one slice instead” worked fine in the demo).
  • Clear between tickets. Don’t say “do every ticket”; implement one, check whether you’re still in the smart zone, maybe squeeze in one more, but the default is clear-and-reload.

This is the same discipline behind spec-driven multi-session work generally: the spec and tickets are durable state that survives context resets, so the tracker (not the conversation) is the source of truth.

Why the code review runs in sub-agents

The /implement skill finishes with typecheck, build, verification, then a two-axis review:

  1. Against the spec — catches acceptance criteria that got lost or under-specified across tickets. This is the payoff for writing the spec at all: a final diff-vs-intent check.
  2. Against the repo’s coding standards — falls back to classic Martin Fowler-style code-smell review when no standards docs exist.

Both run in fresh-context sub-agents, on the argument that an agent reviewing code it just wrote rubber-stamps it — a clean context window reviews honestly. Same rationale as any maker/checker split.

Setup notes

  • npx skills@latest add mattpocock/skills — requires Node.js; runs Vercel’s skills.sh installer. Two catalog groups: official (blessed, public-facing) and “other” (experimental, may be deleted).
  • Works with any harness — Claude Code, Cursor, Codex. Scope: project-level for teams (shared skill set, shared decisions), global for solo devs. Install mode: choose symlink; don’t overthink it.
  • /setup-matt-pocock-skills configures the repo: issue tracker (GitHub, local markdown, Jira, Linear — no plugin needed, just tell the agent which one and it wires itself from local config), triage labels (defaults are fine), and domain docs (CONTEXT.md + ADRs; single-context unless you’re in a large monorepo with multiple bounded contexts).
  • The skills are mostly user-invoked with short precise descriptions — all 38 cost only ~660 tokens of standing context. This is a deliberate design contrast with skill repos that auto-trigger and bloat context.
  • /ask-matt is “Matt as a skill” — ask it “how do I get started, what flow should I use” and it walks you through the repo itself.

What carries beyond this repo

Three ideas here are worth taking even if you never install a single one of his skills:

  • Budget against the smart zone, not the advertised window. A context limit is a hard stop; the point where answers get worse arrives well before it. Planning sessions against a working figure you have actually observed — Pocock uses roughly 100k of room inside a ~140k smart zone — is a different discipline from planning against the number on the box. See Context-Rot-and-Governing-Context for why the degradation is gradual rather than a cliff.
  • Spec and tickets are destination and route, and the distinction is load-bearing. The spec says what “done” means; the tickets say how you get there in single-session pieces. Conflating them produces either a spec too vague to check against or tickets that cannot be worked without re-reading the whole discussion. This vocabulary is reusable for any multi-session work handed between people or agents, which is most work that outlives one sitting.
  • A reviewer that shares the writer’s context is not a reviewer. Running the review in a fresh context is the same maker/checker separation that any change-control process enforces, applied at the level of the model’s working memory. An agent asked to review what it just wrote will defend it.

Clear between tickets is the operational half of the first point: implement one, judge whether you are still in the smart zone, and reload rather than pushing on. The durable state lives in the spec and the tracker, so a reset costs nothing but the reload.