Matt Pocock's 21 Claude Code Skills: Packaging Software Engineering Fundamentals for AI Agents
> Original repository: mattpocock/skills · Shell · MIT · +1,272 stars in a single day (2026-09-02)
Why a TypeScript Educator Writes Agent Skills
Matt Pocock is a well-known name in the TypeScript community as the author of Total TypeScript, a course with high penetration among TS developers. In 2026 he did something seemingly off-brand: he open-sourced his own .agents directory — 21 Claude Code skills under the MIT license.
mattpocock/skills gained 1,272 stars on 2026-09-02, making it one of the fastest-growing projects on GitHub Trending that day. A Shell-language project growing that fast suggests it hit not technical novelty, but a real pain point in engineering practice.
Four Failure Modes, Four Sets of Skills
Matt's README does not classify skills by function but by failure mode — a smart narrative structure: not "here are my tools," but "here is your problem."
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 boundaries? How should edge cases be handled?
Two skills address this mode:
/grill-me: alignment for non-code scenarios/grill-with-docs: alignment for code scenarios while building the project's domain model- 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: break a plan into tracer-bullet tickets, each declaring its blocking dependencies/improve-codebase-architecture: scan the codebase for modules that "could be deepened," generate an HTML report, then grilling-session your way through the one you pick- Claude Code specific: the SKILL.md format isn't directly compatible with other agent frameworks.
- Heavy reliance on personal judgment: the 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 is no mechanism verifying "this skill was applied correctly."
Failure Mode 2: The Agent Is Too Verbose
The root cause is not chattiness but the lack of a shared language. This is Eric Evans's ubiquitous language from Domain-Driven Design: developers and domain experts should use the same vocabulary. Agents are no different — 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.
/grill-with-docs builds a CONTEXT.md — a shared project dictionary — during the grilling process. Matt calls this possibly the most powerful technique in the 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 is 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 phased debugging loop: build a feedback loop that reproduces the bug → minimize → hypothesize → instrument → fix → regression test.
Failure Mode 4: The Code Becomes a Big Ball of Mud
> "Agents can radically speed up coding, they also accelerate software entropy."
Precisely put: agents make you write code 10x faster — and make your code rot 10x faster. Agents don't care about architecture; you ask for a feature, they add it, without suggesting "wait, we should abstract an interface 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 fall into two categories:
User-invoked: triggered only when you type, e.g., /grill-me. Their job is orchestration — organizing an alignment session, a plan, an architecture review.
Model-invoked: triggerable by you or the agent automatically when a task matches. 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 maps to a deeper insight: some decisions should be made by humans; some execution can be delegated to the agent. Planning and alignment stay human; execution and verification go to the agent. Blurring the line means either the human gets dragged along by the agent, or the agent gets stuck by the human.
How It 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 "baking 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.
In practice: GSD-style frameworks suit teams unfamiliar with software engineering (process protects them from mistakes); Matt's skills suit experienced engineers (tools accelerate them without replacing judgment).
Installation: Subscribe vs Fork
Two installation paths:
1. Claude Code plugin: installed as a managed read-only bundle that auto-syncs when Matt updates. You "subscribe" rather than "fork."
2. skills.sh: copies skill files into your .agents directory for free modification.
This is clever design. Most users don't need to modify skills — they want "when Matt updates /tdd best practices, I get them automatically." A minority need customization — they grab the source files via skills.sh and edit them.
Why 1,272 Stars/Day
The logic behind the number:
1. Matt Pocock's personal brand: Total TypeScript's audience overlaps heavily with Claude Code's audience — developers who take code quality seriously. 2. The pain is real: the four failure modes are ones every Claude Code user has hit. Not "this tool is cool," but "I finally have a fix for this problem." 3. Low barrier: Shell scripts + Markdown, no runtime to install, one-command setup. 4. No conflicts: skills are an overlay layer, not a replacement for Claude Code itself.
Limitations
One-Sentence Summary
Matt Pocock's 21 skills are not a revolutionary new framework — they package software engineering fundamentals (alignment, shared language, TDD, design investment) into skills Claude Code can invoke. The value lies not in technical novelty but in turning well-worn good practices into one-click-installable tools. 1,272 stars/day suggests many people needed exactly this.
GitHub: https://github.com/mattpocock/skills