Matt Pocock's 21 Claude Code Skills: Packaging Software Engineering Fundamentals as Agent Skills
> Original repository: mattpocock/skills · Shell · MIT · +1272 stars in a single day on 2026-09-02
Why would a TypeScript educator write agent skills?
Matt Pocock carries real weight 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 looked slightly out of character: he open-sourced his .agents directory — 21 Claude Code skills under the MIT license.
mattpocock/skills gained 1,272 stars in a single day on 2026-09-02, one of the fastest-growing GitHub Trending projects that day. For a Shell-language project to grow that fast, it clearly hit not technical novelty but a genuine pain point in engineering practice.
Four failure modes, four groups of skills
Matt's README doesn't organize skills by feature — it organizes them by failure mode. It's a smart 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 a 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 correspond to this mode:
/grill-me: alignment for non-code scenarios/grill-with-docs: alignment for code scenarios, while building a domain model of your 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 the simplest way
- Refactor: improve structure while keeping tests green
/to-spec: turn the current conversation into a spec, published to your issue tracker/to-tickets: break a plan into tracer-bullet tickets, each declaring its blocking dependencies/improve-codebase-architecture: scan the codebase for modules "that could go deeper," generate an HTML report, then grilling-walk through the one you pick- Claude Code only: the skill format is Claude Code's SKILL.md, not directly compatible with other agent frameworks.
- Heavy reliance on personal judgment: these 21 skills are Matt's personal best practices. Your project may need different ones — but you can fork and modify.
- No automated verification: skill effectiveness depends on the agent executing correctly. There's no mechanism verifying "this skill was executed correctly."
Failure mode 2: The agent is too verbose
The root cause isn't chattiness — it's the lack of a shared language. Eric Evans' ubiquitous language from Domain-Driven Design applies: developers and domain experts should share one vocabulary. Agents are the same: if you call "a lesson in a course being materialized to the filesystem" a "materialization cascade," the agent no longer needs twenty words each time.
During the grilling process, /grill-with-docs builds a CONTEXT.md — a shared dictionary for the project. Matt calls this possibly the strongest technique in the whole 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
Alignment done, 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 cycle:
The /tdd skill hardens this cycle into the agent's default behavior. /diagnosing-bugs is a staged debugging loop: build a reproduction feedback loop → minimize → hypothesize → instrument → fix → regression test.
Failure mode 4: The codebase becomes a mud ball
> "Agents can radically speed up coding, they also accelerate software entropy."
This line is precise. Agents make you write code 10x faster — and make it rot 10x faster. Agents don't care about architecture: you ask for a feature, they add it, and they won't proactively say "wait, we should abstract an interface here first."
The solution is daily design investment (Kent Beck's phrase). Several skills apply:
User-invoked vs Model-invoked: a key distinction
Matt's skills fall into two categories:
User-invoked: triggered only when you type /grill-me. Their job is orchestration — organizing an alignment session, a plan, an architecture review.
Model-invoked: triggered by either you or the agent whenever the task matches. They carry reusable disciplines — TDD, code review, debugging procedures.
The rule: user-invoked skills may call model-invoked skills, but never another user-invoked skill. This prevents recursive skill-to-skill calls from spiraling out of control.
The classification encodes a deep insight: some decisions should be made by humans; some execution can be autonomous. Planning and alignment stay human; execution and checking go to the agent. Blur the two, and either the human gets dragged along by the agent, or the agent gets strangled by the human.
How it differs from GSD/BMAD/Spec-Kit
The README includes 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 "hard-code the process into the system" — follow my workflow and I guarantee results. Matt's philosophy is the opposite: skills are tools, not processes. You can use /grill-me to align, or skip it; you can use /tdd for tests, or not. Skills never force anything.
The practical implication: GSD-style frameworks suit teams unfamiliar with software engineering (process prevents their mistakes), while Matt's skills suit experienced engineers (tools accelerate them without replacing their judgment).
Installation: subscribe vs fork
Two installation paths:
1. Claude Code plugin: installed as a managed read-only bundle that auto-syncs whenever Matt updates. You "subscribe" rather than "fork."
2. skills.sh: copies the skill files into your .agents directory for free modification.
Smart design. Most users never need to modify a skill — they need "Matt updated /tdd's best practice and I got it automatically." A few need customization — they grab the source via skills.sh and edit.
Why 1,272 stars/day
The logic behind the number:
1. Matt Pocock's personal brand: Total TypeScript's audience and Claude Code's audience overlap heavily — developers who care about code quality. 2. Real pain points: the four failure modes are universal among Claude Code users. 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 setup. 4. Non-conflicting: skills are an additive layer on top of Claude Code, not a replacement.
Limitations
One-line takeaway
Matt Pocock's 21 skills aren't a revolutionary new framework — they package software engineering fundamentals (alignment, shared language, TDD, architecture investment) into skills Claude Code can invoke. The value isn't technical novelty; it's turning long-preached good practices into one-command-installable tools. 1,272 stars/day says a lot of people needed exactly that.
GitHub: https://github.com/mattpocock/skills