mattpocock/skills review: a real engineer's .agents, 216k stars, built to remix

This is the third repo I opened in a run of trending Claude Code skill repos. The first two were superpowers and karpathy skills. This one is mattpocock/skills, over 216,000 stars. Its description is blunt and a little funny: "Skills for Real Engineers. Straight from my .agents directory."

That line is the whole thing. This one was not designed as a product for others from the start. It is the directory Matt actually works out of, opened up for others to copy. Matt Pocock is a well-known TypeScript educator, so the skills here carry the smell of someone who has written code for a long time, not theory.

This post goes in order: what it is and why the stars, then the skills that genuinely stand out, then a look at how the three repos I reviewed are each a different pole and which to reach for, and finally how to install it and how I use it myself.

Part 1What mattpocock skills is, and why the stars

This one differs from the other two in that it does not try to be a product. It is a real working folder, opened up. Inside are around 35 skills, grouped into categories. The interesting part is that it separates what is ready for others from what is still a personal experiment. The engineering and productivity categories are the polished ones; categories like in-progress or personal are the unfinished stuff kept local. That layout tells anyone reaching in which skills to trust.

Why 216,000 stars? Because it answers a very direct curiosity: people want to see how a strong engineer actually configures their AI, not generic advice but the thing used in daily work. And Matt made it easy to take, with both an automatic installer and a symlink method that keeps you in sync with the repo.

What skills are in the repo

If you came looking for exactly what skills live in mattpocock/skills, here are the polished groups, read straight from the SKILL.md files in the repo. Two categories; the private in-progress category is not shipped for use, so the whole repo counts to around 35, of which the v1.2.3 plugin ships 25.

Engineering (18) ask-matt, grill-with-docs, triage, improve-codebase-architecture, setup-matt-pocock-skills, to-spec, to-tickets, wayfinder, implement, prototype, diagnosing-bugs, research, tdd, domain-modeling, codebase-design, code-review, resolving-merge-conflicts, wizard

Productivity (7) grill-me, grilling, handoff, teach, writing-for-agents, to-questionnaire, wait-what

The four I walk through below are diagnosing-bugs, tdd, grilling, and codebase-design, the ones that most smell of real work.

Why the number in the README is not the number your model can reach

Because there are three numbers, not one, and each layer drops some. 35 files on disk, 25 declared by the plugin, 11 the model can invoke on its own. These come from a machine with v1.2.3 actually installed, not from reading the README.

The first layer drops 10: plugin.json does not declare the misc and in-progress buckets. They are still in the repo to read, they just do not ship with the plugin.

The second layer is the interesting one. The other 14 carry disable-model-invocation: true in their frontmatter, which means you can invoke them, the model cannot reach for them itself: to-spec, to-tickets, wayfinder, triage, handoff, implement and 8 more.

Sort them into the two piles and the line is sharp. The ones the model may reach for are the ones that supply a way of thinking: tdd, code-review, diagnosing-bugs, codebase-design. The ones held back are the ones that change something real or run long: slicing work into tickets, planning a whole project, handing off to the next session.

That is not a defect, it is a decision, and it is the part we took for our own set straight away. When you write a new skill, "what does it do" is not the only question. "May the model reach for this by itself" is the other one. Anything that only supplies judgement can be left open. Anything that changes real state should wait for a human to press it.

The side benefit is a shorter list to carry every turn, 11 lines instead of 25, which in practice also makes picking the wrong one harder.

Part 2The skills that genuinely stand out

Reading the real files, several carry the clear smell of lived work. Four worth calling out.

1. diagnosing-bugs before hypothesizing about a cause, build a clear pass/fail signal first. Once you have a signal that reliably catches the bug, the rest is just narrowing it down. It gets the order right: tighten the feedback loop first, hypothesize second.
2. tdd it does not just say write tests first, it names the common mistakes too, like tests coupled too tightly to the implementation, and it stresses writing in vertical slices per feature, agreeing on the seam before you start.
3. grilling when the AI is drawing information out of you, ask one question at a time and wait, rather than firing a batch at once, because a big block of questions makes people answer sloppily.
4. codebase-design it enforces precise vocabulary for module, depth, and seam, with an easy-to-remember rule: ask whether deleting this module would concentrate complexity or just move it elsewhere. If it just moves, the module is shallow and not earning its place.

What they share is that they come from real pain, not tidy rules. Each skill exists because a problem showed up often enough to be worth writing a response to. Reading them feels like looking over the notebook of someone who has been through a lot of work.

Part 3Three poles: superpowers, karpathy, mattpocock, which to pick

Having reviewed all three, the picture is clear: each answers a different need, they are not competing head-on.

• superpowers a skill set with enforcement gates, for when you let the AI run long on its own and need tight rails.
• karpathy skills 4 abstract principles in one file, for when you want the shortest set of principles to start from.
• mattpocock skills a real practitioner's directory, for when you want tools in pieces to remix, picking only what fits your work.

Sorted by style of use: superpowers is for those who want a ready-made system with rails, karpathy is for those who want the leanest mental model, and mattpocock is for those who like to assemble their own, taking one piece at a time. The three do not clash. You could take karpathy's 4 principles as a base, add standout skills from mattpocock, and borrow superpowers' trick of naming the excuse to make the rules actually hold.

Part 4Should you install it, and how to use it

Should you try mattpocock skills?

It is worth a try, especially if you want to see well-written skills from someone doing real work. As of v1.2.3 there are two ways in, and they differ on ownership. Installing the plugin is subscribing; copying the files is owning them. The first, claude plugins install mattpocock-skills, gives you the whole set read-only and pulls new releases as Matt ships them. The second, npx skills@latest add mattpocock/skills, copies the files straight into your repo so you pick which ones to take and edit them freely, at the cost of running npx skills update yourself; then run /setup-matt-pocock-skills once per repo. The README warns against installing both, or you end up with every skill twice. If you mean to remix, take the second road.

The idea you can use right now

Even without installing the repo, its most distilled lesson is this: a good skill comes from real pain, not from sitting down to invent something that might be nice to have. When you find yourself telling the AI the same thing the same way every time, that is the signal to pack it into a skill. Matt's way is not to wait for it to be perfect: write it rough, use it, refine it, and only promote it to something shareable once it settles.

For my part, I compared these against the skills I already use and borrowed the shape of a few, rather than installing the whole set, since many are tied to TypeScript work that does not match mine every day. How I pick and blend them into my own stack is a detail I am leaving out of this post, but the lesson above you can use right away.

The one rule to remember

If you remember one thing from this post, let it be this: the best AI tools for you are usually the ones you assemble yourself. Someone else's repo is valuable as an example and a starting point, not as something to swallow whole. Take what fits your work, drop what does not, and it becomes your own set.

This post is one layer in the 7-layer architecture of a production AI agent.