The 38 skills Matt Pocock uses every day for real engineering

Positioning: skills for real engineers, not vibe coding

This is the set Matt Pocock (author of Total TypeScript) uses daily for real engineering, and the repo states it bluntly: "My agent skills that I use every day to do real engineering - not vibe coding." 266,356 stars / 22,488 forks, MIT, primary language Shell — because it is essentially a Markdown instruction set with a little glue, not a codebase.

Its stance on existing methodologies is the most useful thing here. The author names GSD, BMAD and Spec-Kit: those frameworks help by owning the process, and the price is that you lose control and a bug inside the process becomes hard to diagnose. His alternative is three words — small, easy to adapt, composable — with an explicit note that they work with any model and that you should hack them into your own.

What the 38 SKILL.md files actually contain

Group	Count	Representative skills
engineering	18	code-review, codebase-design, diagnosing-bugs, domain-modeling, implement, prototype, research, resolving-merge-conflicts, tdd, to-spec, to-tickets, triage, wayfinder, wizard, grill-with-docs, improve-codebase-architecture
productivity	7	grill-me, grilling, handoff, teach, to-questionnaire, wait-what, writing-for-agents
misc	4	git-guardrails-claude-code, setup-pre-commit, migrate-to-shoehorn, scaffold-exercises
in-progress	9	pr, retro, implement-spec, loop-me, claude-handoff, writing-beats and others — incubating in public, do not expect stability

Note the names grill-me / grilling / wait-what: these are skills that make the agent interrogate you. The author's judgement is that most bad code comes from requirements nobody pushed on, so interrogation is a first-class capability rather than a preamble inside implement.

CONTEXT.md: the underrated piece

The repo root carries a CONTEXT.md that defines the project's own domain language — what "Issue tracker" means here, what a "Decision ticket" looks like, what the "Triage" role owns. Skills read it, so project conventions never have to be restated inside each skill. It is the cleanest separation of project context from general capability we have seen, and far cheaper on tokens than repeating background in every prompt.

Two install paths, two philosophies (do not use both)

# A. Claude Code plugin: managed read-only bundle, auto-updates on release — subscribe
claude plugins install mattpocock-skills

# B. skills.sh: copies editable files into your project — you fork and own them
npx skills@latest add mattpocock/skills

The README says explicitly that installing both gives you every skill twice. If you pick B, include setup-matt-pocock-skills, otherwise cross-references between the copied skills break.

Our take

If your team already runs a heavy process like Superpowers, the value here is spare parts: code-review, diagnosing-bugs and resolving-merge-conflicts each stand alone without buying the methodology. That is what "composable" means in practice, and it is the real difference from Superpowers — that one sells you a whole process, this one sells components.

Conversely, if what you want is discipline out of the box, take Superpowers. This set expects you to decide when to invoke which skill; the discipline has to come from you.