Matt Pocock's 21 Skills: Packaging Software Engineering Fundamentals into Claude Code
> Repository: mattpocock/skills · Shell · MIT · +1,272 stars in a single day on 2026-09-02
Why Would a TypeScript Educator Write Agent Skills?
Matt Pocock is a well-known name in the TypeScript world. He is the author of Total TypeScript, a course with high penetration among serious TS developers. In 2026 he did something that seemed off-brand: he open-sourced his .agents directory — 21 Claude Code skills under the MIT license.
mattpocock/skills gained 1,272 stars on 2026-09-02, one of the fastest-growing projects on GitHub Trending that day. A Shell-language project growing that fast suggests it hit not on technical novelty, but on real pain points in engineering practice.
Four Failure Modes, Four Sets of Skills
Matt's README doesn't categorize the skills by feature, but by failure mode. It's a clever narrative structure — not "here are my tools," but "here are your problems."
Failure Mode 1: The Agent Didn't Do What I Wanted
> "The most common failure mode in software development is misalignment. You think the dev knows what you want. Then you see what they've built - and you realize it didn't understand you at all."
The solution is the grilling session. Before writing any code, the agent interrogates you: what do you actually want? What are the boundary conditions? How should edge cases behave?
Two skills map to this mode:
/grill-me: alignment for non-code scenarios/grill-with-docs: alignment for code scenarios, while building a domain model of the project- Before: "There's a problem when a lesson inside a section of a course is made 'real' (i.e. given a spot in the file system)"
- After: "There's a problem with the materialization cascade"
- Red: write a failing test first
- Green: make the test pass in the simplest way
- Refactor: improve structure while keeping tests green
/to-spec: turn the current conversation into a spec and publish it to your issue tracker/to-tickets: split plans into tracer-bullet tickets, each declaring its own blocking dependencies/improve-codebase-architecture: scan the codebase for modules that "could be deepened," generate an HTML report, then grill through the one you pick- Claude Code only: the skill format is Claude Code's SKILL.md, not directly compatible with other agent frameworks.
- Heavily opinionated: the 21 skills reflect Matt's personal best practices. Your project may need different practices — but you can fork and modify.
- No automated verification: skill effectiveness depends on the agent executing them correctly. There's no mechanism verifying "this skill was executed properly."
Failure Mode 2: The Agent Is Too Verbose
The root cause here isn't that the agent talks too much — it's the lack of a shared language. Eric Evans's ubiquitous language from Domain-Driven Design applies: developers and domain experts should use the same vocabulary. The same goes for the agent: if you call "a lesson in a course being assigned a spot in the file system" a "materialization cascade," the agent no longer needs 20 words to describe it each time.
During grilling, /grill-with-docs also builds a CONTEXT.md — a shared dictionary for the project. Matt says this may be the most powerful technique in the entire repo:
> "It's hard to explain how powerful this is. It might be the single coolest technique in this repo."
Effect example:
Failure Mode 3: The Code Doesn't Work
Aligned, but the code is still broken. The problem is the feedback loop. An agent writing code without feedback is flying blind.
The solution is TDD's red-green-refactor loop:
The /tdd skill bakes this loop into the agent's default behavior. /diagnosing-bugs is a staged debugging loop: build a feedback loop that reproduces the bug → minimize → hypothesize → instrument → fix → regression test.
Failure Mode 4: The Code Turns into a Big Ball of Mud
> "Agents can radically speed up coding, they also accelerate software entropy."
That lands precisely. Agents let you write code 10x faster — and let your code rot 10x faster. Because agents don't care about architecture: you ask for a feature, they add it, and they never proactively say "wait, an interface should be abstracted here first."
The solution is investing in design every day (Kent Beck's words). Several skills address this:
User-Invoked vs Model-Invoked: A Key Distinction
Matt's skills come in two classes:
User-invoked: triggered only when you type /grill-me. Their job is orchestration — organizing an alignment, a planning session, an architecture review.
Model-invoked: triggerable by either you or the agent. When a task matches, the agent invokes them automatically. They carry reusable discipline — TDD, code review, debugging workflows.
The rule: a user-invoked skill may call model-invoked skills, but never another user-invoked skill. This prevents runaway recursion between skills.
This classification encodes a deep insight: some decisions should be made by humans; some execution can be delegated to the agent. Planning and alignment stay human; execution and checking can be automated. Mixing the two means either the human gets dragged along by the agent, or the agent gets frozen by the human.
How This Differs from GSD/BMAD/Spec-Kit
The README contains a comparison worth quoting verbatim:
> "GSD, BMAD, Spec-Kit: They own the process. They take away your control. These skills give control back."
This is an important stance. Most agent frameworks are designed around the philosophy "bake the process into the system" — follow my workflow and I guarantee the outcome. Matt's philosophy is the opposite: skills are tools, not processes. You can use /grill-me for alignment or skip it; you can use /tdd or not. Skills never force you to do anything.
The practical implication: GSD-style frameworks suit teams unfamiliar with software engineering (the process protects them from mistakes), while Matt's skills suit experienced engineers (the tools accelerate them without replacing judgment).
Installation: Subscribe vs Fork
Two installation paths:
1. Claude Code plugin: installed as a managed read-only bundle; you automatically get Matt's updates. You "subscribe" rather than "fork."
2. skills.sh: copies the skill files into your .agents directory, free to modify.
Smart design. Most users don't need to modify skills — they need "Matt updated /tdd best practices, and I got it automatically." A minority need customization — they grab the source files via skills.sh and edit them.
Why 1,272 Stars/Day
The logic behind that number:
1. Matt Pocock's personal brand: Total TypeScript's audience overlaps heavily with Claude Code's — developers who take code quality seriously. 2. Real pain points: the four failure modes are ones every Claude Code user has hit. It's not "this tool is cool" — it's "I finally have a fix for this problem." 3. Low barrier: Shell scripts + Markdown, no runtime to install. One command to set up. 4. No conflict with existing tools: skills are an additive layer, not a replacement for Claude Code itself.
Limitations
One-Line Summary
Matt Pocock's 21 skills aren't a revolutionary new framework — they encode software engineering fundamentals (alignment, shared language, TDD, design investment) into skills that Claude Code can invoke. Their value lies not in technical novelty but in turning well-worn good practices into one-command-installable tools. 1,272 stars/day suggests a lot of people needed this.
GitHub: https://github.com/mattpocock/skills