▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=M6mYodf0dJM
• Original title :: mattpocock/skills: A complete AI Coding workflow, end-to-end

Matt Pocock gives the first proper tutorial for his skills repo (about 162k stars and 7.5 million downloads at recording). He installs the skills into a real project, runs the one-time setup skill, and then walks the main flow on a live task: grill-with-docs interview, then to-spec and to-tickets when the work needs several sessions, then implement with a built-in code review. Advanced and experimental skills are left out.

Installing the skills

Run the skills.sh installer from Vercel through NPX (needs Node.js) against the mattpocock/skills repo. It listed 38 skills in two groups: the official ones he considers public-facing, and others he is still experimenting with and may delete. He recommends selecting all the official ones. The installer supports many agents (Cursor, Codex, Claude Code and others); Claude-skills-style agents such as Claude Code need to be ticked explicitly. Scope is a choice: project scope is better for teams so everyone shares one skill set, global is fine for a solo developer. Symlink is the recommended install mode. He is unhappy with Vercel's CLI and may ship his own. The skills are mostly user-invoked with short descriptions, so all of them together cost only about 660 tokens of context.

Running the setup skill

The skills rely on repo configuration, which the setup skill creates. Questions it asks: which issue tracker holds specs and tickets (GitHub, local markdown, or anything else - tell the agent "set it up with Jira" or Linear or Beads and it configures itself, so no special support is needed); triage labels (defaults are fine); and domain docs layout (single context is right for 99% of repos, multi-context is for big monorepos with several bounded contexts). It adds links in CLAUDE.md to the issue tracker, triage label and domain docs files under docs/agents.

Ask Matt skill

A skill that acts as Matt himself: it knows the whole repo and tells you where to start. Asked "how do I get started with code changes", it describes the main flow from idea to ship and stresses working in one unbroken context window. The flow: grill-with-docs to sharpen the idea (it records what it learns in a context file and ADRs), prototype when a question needs a runnable answer (bridged by handoff), then either implement directly or to-spec and to-tickets for multi-session work.

Grill with docs

Kick it off with a vague idea; his example was stripping the internal tooling from his AI Hero CLI to make it public-facing only. The agent explores the code and asks questions one by one until you reach shared understanding, then lays out a plan (delete 10 command files and three tests, rewire shared modules). It took six questions here; real sessions are usually about 20. He ran it in auto mode rather than plan mode, with Opus 4.8 on medium effort, and says the skills work across harnesses, models and effort levels.

Smart zone and the fork in the road

He treats roughly 140k tokens as the end of the model's smart zone; beyond that attention degrades and hallucinations increase. If the remaining work fits comfortably in the budget (here about 100k for a simple removal), skip straight to implement. Only when work will not fit in one smart zone, split it over several sessions.

To-spec and to-tickets

To-spec compresses the whole discussion (about 46k tokens) into a spec in the issue tracker: problem statement, solution, user stories, implementation and testing decisions. The spec is the destination, used later to check the implementation against. To-tickets turns the spec into slices, each sized to one context window or smart zone. It proposed three; he asked for one. A real example shows a spec with 11 sub-issue tickets, each a short per-session brief since the acceptance criteria already live in the spec.

Implement and code review

Clear the context, reference the tickets and run implement. Done by hand across many tickets: implement one ticket per session, clear between them, squeeze in a second only if still outside the dumb zone. Implement runs type checks, build and verification, then loads the code review skill. Review has two axes: the work against the original spec (catches things dropped between spec and tickets), and the work against the repo's coding standards, falling back to classic Martin Fowler-style code smells if none are documented. Reviews run in sub-agents with clear context because an agent that just wrote code is bad at critiquing it. Both reviews passed and the work was committed to the current branch.

Wrap-up

This loop (align, spec and tickets for multi-session work, implement with review) is the main flow all of his work runs through; everything else is experiments to make it faster and easier. For same-day updates on new and changed skills he points to his newsletter, which he says is more current than the channel.