The Main Workflow Behind Matt Pocock's Skills Repo, Walked Through Step by Step

I've been meaning to actually sit down with Matt Pocock's skills repo for a while. It's a genuinely popular project, 162,000 GitHub stars and 7.5 million downloads at last count, and I kept seeing the same questions come up: what order do you use these skills in, how do you install them, how do you set them up on a new project. So I finally walked through the whole flow myself, start to finish, on a real codebase.

Installing it

Setup runs through a single command: npx skills@latest add mattpocock/skills. It works the same whether you're pointing it at an existing codebase or an empty directory. The installer walks you through a few questions: which skills to install (there's a public, vetted set and a separate experimental one), which agent you're using (Claude Code, Cursor, Codex, and others are all supported), and whether to install per-project or globally.

For teams, project-level installation is the better call. Everyone ends up working from the same skill set, and any changes to it become something the team decides together rather than something that quietly diverges machine to machine. For solo work, global is fine. When it asks whether to copy the files or symlink them, symlink is the easier option and there's no real reason to pick the alternative.

One detail worth calling out: these skills are mostly invoked by name rather than auto-triggered by their descriptions. That keeps the base context footprint small, in my test the full set only added a few hundred tokens before I'd even used one.

Configuration before you start

After installing, you run a setup skill that wires a few things into the repo: where tickets and specs get stored (GitHub, Jira, Linear, or just local markdown, you tell it which and it configures itself accordingly), a set of triage labels for tracking ticket state, and whether the project needs a single shared context document or multiple ones for separate bounded contexts inside a larger monorepo. For most projects, a single context is enough.

The actual flow: idea to shipped code

The core workflow has a clear shape once you've run it once.

It starts with a skill that interviews you about what you want to build. You can be vague going in, the interview itself does the heavy lifting, asking follow-up questions, exploring the existing code, and building a shared understanding of the change before anything gets written down. In my test it took about six questions to reach a plan; the number scales with how big the change actually is.

From there you hit a genuine fork. If the work is small enough to finish in one sitting, you go straight to implementation. If it's bigger, you compress the entire interview into a written spec first, saved to whatever issue tracker you configured. That spec becomes the fixed destination for the rest of the work: what the end state actually looks like, independent of how many sessions it takes to get there.

The spec then gets broken into individual tickets, each one sized to fit inside a single working session. This is where a useful mental model comes in: think of a model's context window as having a "smart zone," roughly the first 140k tokens or so, before attention starts to degrade and output quality drops. Sizing each ticket to fit inside that zone, and clearing context between tickets, keeps every session working with a genuinely sharp model instead of an increasingly confused one.

Implementation itself isn't just "write the code." Every implementation pass also runs verification, type checks, build, and a full code review, automatically, in a separate agent context rather than the same one that wrote the code. That separation matters more than it sounds: a model reviewing its own freshly written code tends to rubber-stamp it, while a fresh context is more likely to catch real problems. The review checks two things: does the actual result match the original spec, and does it hold up against whatever coding standards the repo defines (falling back to well-known ones when the repo doesn't define its own).

Why the fresh-context review matters

This is worth dwelling on for a second, because it's the part I think generalizes best beyond this specific repo. Once an agent has written code, it's a bad judge of that same code. It already believes the decision was correct. Running review as a separate step, with its own clean context, is what actually catches the gaps, whether that's a missed edge case, a ticket that turned out to be underspecified, or a small deviation from the plan that crept in along the way.

The takeaway

What struck me most about walking through this end to end wasn't any single skill, it was how deliberately the whole thing is shaped around context management: keeping the interview stateful so you don't repeat yourself, compressing a long discussion into a spec you can return to, sizing tickets to a model's actual attention span instead of an arbitrary chunk of work, and reviewing code with fresh eyes instead of the ones that just wrote it. That's a workflow worth borrowing even if you never install this specific repo.