Matt Pocock's Skills: The AI Coding Skills That Actually Make You a Better Engineer 🧙♂️
Matt Pocock’s Skills: The AI Coding Skills That Actually Make You a Better Engineer 🧙♂️
So, you’ve been using Claude Code (or Cursor, or Codex) to write code, and you’re starting to realize that vibe coding (you know, just typing “make it work” and hoping for the best) is a great way to build a technical debt time bomb 💣.
Enter Matt Pocock’s Skills - a collection of 16 battle-tested Claude Code skills that actually help you write real production code instead of generating a beautiful pile of 💩.
In this article, we’ll dive into:
- Who the hell is Matt Pocock anyway? 🤔
- Why you need these skills (unless you enjoy debugging AI-generated spaghetti code)
- The 16 skills and what they actually do
- How to install and use them like a pro
- Why this is better than those bloated “frameworks” like BMAD or Spec-Kit
Let’s get started, shall we? 🚀
🧙♂️ Who the Hell is Matt Pocock?
If you’ve been writing TypeScript in the past few years and haven’t heard of Matt Pocock, you’ve probably been writing TypeScript wrong. Sorry not sorry. 😎
Matt is:
- The creator of Total TypeScript (the best TypeScript course on the planet 🌍)
- A TypeScript wizard who makes type errors cry like babies
- The guy who open-sourced his entire
.claude/directory and watched it explode to 74,000+ stars on GitHub 💥
He’s not some random AI influencer selling you “10x engineer” bullshit. He’s a real engineer who uses AI tools every day to build real shit that actually works.
And now, he’s sharing his secret sauce with the world. You’re welcome. 🙏
🤔 What Are These “Skills” Anyway?
Okay, so here’s the deal:
You know how when you use Claude Code (or Cursor, or Codex), it’s great at writing code, but sometimes it:
- Writes code that doesn’t do what you want (because you didn’t explain it well enough)
- Writes code that breaks in production (because you didn’t think about edge cases)
- Writes code that’s impossible to maintain (because you didn’t think about architecture)
- Writes code that makes you question your career choices (because it’s a mess)
That’s where Skills come in.
The Core Philosophy 💡
Matt’s approach is simple:
“These are skills for REAL engineers doing REAL engineering - not vibe coding.”
He’s not giving you a framework that tries to take over your entire workflow (looking at you, BMAD and Spec-Kit 👀). Instead, he’s giving you 16 independent tools that you can mix and match like LEGO bricks 🧱.
Each skill is:
- ✅ Small (you can read and understand it in 5 minutes)
- ✅ Editable (you can modify it to fit your workflow)
- ✅ Composable (you can use them together or separately)
- ✅ Battle-tested (Matt uses them every day in production)
It’s like having a senior engineer looking over your shoulder and saying, “Dude, don’t do that. Do this instead.” 😎
🎯 The 4 Failure Modes (Why Your AI Code Sucks)
Matt did some soul-searching and realized that all AI coding failures can be traced back to 4 root causes.
It’s like the 4 Horsemen of the AI-pocalypse 💀, except instead of Conquest, War, Famine, and Death, we have:
| Failure Mode | What It Means (In Plain English) | The Skill That Fixes It |
|---|---|---|
| Misaligned Requirements | You don’t know what you want, and neither does the AI 🤷♂️ | /grill-me, /grill-with-docs |
| Poor Communication | You and the AI are speaking different languages 🗣️🤖 | CONTEXT.md (shared language file) |
| Code Doesn’t Work | The AI writes code that breaks, and you don’t know why 💥 | /tdd, /diagnose |
| Code Rot | The AI writes code that works today but turns into a nightmare tomorrow 💩 | /to-prd, /zoom-out, /improve-codebase-architecture |
Let’s break each of these down, shall we? 😏
1. Misaligned Requirements ( aka “I Don’t Know What I Want”) 🤷♂️
You know that feeling when you ask the AI to “build a login system,” and it gives you a half-baked OAuth implementation that doesn’t handle edge cases, doesn’t have tests, and uses deprecated libraries?
Yeah, that’s because you didn’t know what you wanted, and neither did the AI.
The Fix: /grill-me and /grill-with-docs
These skills interrogate you (hence the name “grill” 🔥) to clarify your requirements before writing a single line of code. It’s like having a product manager who actually knows how to code.
The best part? After the interrogation session, it generates a CONTEXT.md file that documents all the decisions you just made. So next time you (or the AI) come back to this project, you won’t be like, “Wait, why did we do it this way?” 🤦♂️
2. Poor Communication ( aka “You Guys Aren’t Even Speaking the Same Language”) 🗣️
Imagine you’re working with a junior developer who doesn’t know your codebase. You say, “Add a handler for the webhook,” and they’re like, “Uh, what’s a webhook?”
That’s basically what happens when you use AI without establishing a shared language.
The Fix: CONTEXT.md
This is the crown jewel of Matt’s entire system. It’s a file that lives in your project root and contains:
- Terminology (what does “user” mean in your domain?)
- Definitions (what’s the difference between a “session” and a “connection”?)
- Boundaries (what’s in scope and what’s not?)
- Invariants (what must ALWAYS be true?)
It’s like a dictionary for your codebase. And the best part? The AI reads it at the start of every conversation, so it doesn’t keep asking you dumb questions like, “What’s a webhook?” 🤦♂️
3. Code Doesn’t Work ( aka “Why Is This Shit Broken?”) 💥
You know that feeling when the AI writes code that looks right but doesn’t actually work, and you spend 3 hours debugging only to realize it was a stupid typo?
Yeah, that sucks.
The Fix: /tdd and /diagnose
/tddforces you (and the AI) to follow Test-Driven Development:- Write a failing test (Red 🔴)
- Write just enough code to make it pass (Green 🟢)
- Refactor (Refactor 🔵)
It’s like having a disciplinarian standing over your shoulder and saying, “Thou shalt not write code without tests.” 😤
/diagnoseis a systematic debugging workflow:- Reproduce the bug 🐛
- Form a hypothesis 🤔
- Add instrumentation (console.log everywhere, basically) 📝
- Fix the bug 🔧
- Add a regression test so it doesn’t come back 🚫
It’s like having a senior engineer help you debug without losing your shit.
4. Code Rot ( aka “This Code Is a Fucking Dumpster Fire”) 💩
You know that feeling when you come back to code you wrote 3 months ago (or the AI wrote yesterday), and it’s a massive ball of mud that nobody understands?
Yeah, that’s technical debt. And AI makes it worse because it can generate code faster than you can generate technical debt.
The Fix: /to-prd, /zoom-out, and /improve-codebase-architecture
/to-prdmakes you write a Product Requirements Document before coding. Not because PMs love paperwork, but because thinking before coding saves you from building the wrong thing./zoom-outforces the AI to explain code in context. Instead of, “Here’s a function that does X,” it says, “Here’s a function that does X, and it’s part of the Y system, which depends on Z.”It’s like having a map instead of a bunch of random dots on a page. 🗺️
/improve-codebase-architectureis like code review on steroids. It looks at your entire codebase and says, “Dude, this is a mess. Let’s fix it.”
🛠️ The 16 Skills (The Full Rundown)
Alright, let’s look at all 16 skills and what they actually do. I’ve grouped them into categories so your brain doesn’t explode 💥.
🔧 Engineering Skills (9 skills - the bread and butter)
These are the skills you’ll use every day when writing code.
1. /diagnose - The Debugger From Hell 🔥
What it does: Systematically debugs issues using a proven workflow:
- Reproduce the bug 🐛
- Form a hypothesis 🤔
- Add instrumentation (console.log everything) 📝
- Fix the bug 🔧
- Add a regression test 🚫
When to use it: When your code is broken and you don’t know why (which is, let’s be honest, every Tuesday).
Why it’s awesome: It stops you from randomly trying shit and hoping something works. It’s systematic, like a real engineer would do. 😎
2. /grill-with-docs - The Interrogation (With Documentation) 🔥🔥
What it does: Interrogates you about your requirements before writing code, and then generates a CONTEXT.md file that documents everything.
When to use it: When starting a new feature and you’re not 100% clear on what you want.
Why it’s awesome: It prevents the “I don’t know what I wanted, and neither does the AI” problem. Plus, you get free documentation! 📝
3. /triage - The Issue Manager 📋
What it does: Manages the lifecycle of GitHub issues using a state machine. Issues move from todo → in-progress → review → done.
When to use it: When you have 47 open issues and no idea which one to tackle first.
Why it’s awesome: It forces you to prioritize instead of just working on whatever shiny thing catches your attention. Like a real PM would do (if they actually used the product). 😏
4. /improve-codebase-architecture - The Codebase Therapist 🛋️
What it does: Looks at your codebase and says, “Dude, this is a mess. Let’s fix it.” It identifies architectural problems and helps you refactor.
When to use it: When your codebase has become a dumpster fire and you’re afraid to touch anything.
Why it’s awesome: It’s like having a senior architect review your code and give you actionable advice. Without the $200/hour consulting fee. 💰
5. /setup-matt-pocock-skills - The Setup Wizard 🧙♂️
What it does: Sets up the prerequisites for using these skills. It asks you about your issue tracker, label vocabulary, and documentation paths.
When to use it: Immediately after installing. This is the mandatory prerequisite for everything else.
Why it’s awesome: It’s like setting up a new phone - annoying but necessary. And once it’s done, everything else just works™. 📱
6. /tdd - The Disciplinarian 🔴🟢🔵
What it does: Forces you to follow Test-Driven Development:
- Write a failing test (Red 🔴)
- Write just enough code to make it pass (Green 🟢)
- Refactor (Refactor 🔵)
When to use it: Always. Unless you enjoy debugging untested code at 3 AM. Then by all means, skip this one. 😏
Why it’s awesome: It prevents you from writing brittle code that breaks every time you breathe on it. Plus, it gives you confidence to refactor without fear. 💪
7. /to-issues - The Task Splitter 📝
What it does: Takes a development plan and splits it into independent, actionable GitHub issues that can be worked on separately.
When to use it: When you have a big feature that needs to be broken down into smaller tasks (because nobody can review a 5000-line PR).
Why it’s awesome: It forces you to think modularly instead of building a monolithic nightmare. 🏗️
8. /to-prd - The “Think Before You Code” Enforcer 📄
What it does: Makes you write a Product Requirements Document before coding. It forces you to think about:
- What are we building?
- Why are we building it?
- What are the acceptance criteria?
When to use it: Before starting any non-trivial feature. Unless you enjoy building the wrong thing. 🤷♂️
Why it’s awesome: It prevents scope creep and feature drift. You know, the things that turn a 2-day project into a 2-month nightmare. 😅
9. /zoom-out - The Context Keeper 🔭
What it does: When explaining code, it zooms out to show the bigger picture. Instead of, “Here’s a function,” it says, “Here’s a function that’s part of the X system, which depends on Y.”
When to use it: When you’re lost in the weeds and need to understand how everything fits together.
Why it’s awesome: It prevents tunnel vision. You know, the thing that makes you optimize a function that shouldn’t exist in the first place. 🤦♂️
⚡ Productivity Skills (3 skills - the force multipliers)
These skills make you faster without sacrificing quality.
10. /caveman - The “Speak English, Dammit” Mode � neanderthal
What it does: Forces the AI to output concise, direct responses instead of verbose explanations. It’s like switching from “professor mode” to “caveman mode” � neanderthal.
When to use it: When you’re tired of the AI giving you a 500-word essay when you just wanted a one-line answer.
Why it’s awesome: It reduces token usage by ~75%. That’s right, 75%. Your wallet will thank you. 💰
Example:
- Without
/caveman: “Well, actually, the optimal approach would be to use a combination of dependency injection and factory patterns with a sprinkle of functional programming because…” (500 tokens later) - With
/caveman: “Use factory pattern. Here’s the code. Done.” (50 tokens)
11. /grill-me - The Non-Code Interrogator 🔥
What it does: The same as /grill-with-docs, but for non-coding decisions. Want to decide between two architectural approaches? Use /grill-me.
When to use it: When you need to make a decision and you’re torn between options.
Why it’s awesome: It’s like having a devil’s advocate who challenges your assumptions. Without the emotional baggage. 😅
12. /write-a-skill - The Meta-Skill ✨
What it does: Helps you write your own skills. It’s a skill that helps you write skills. Meta, right? 🤯
When to use it: When none of the 16 skills fit your specific workflow and you need to create your own.
Why it’s awesome: It makes you self-sufficient. You don’t need to wait for Matt to add a skill - you can create your own! 🚀
🎭 Misc Skills (4 skills - the occasional lifesavers)
These are for specific scenarios, but when you need them, you really need them.
13. /git-guardrails-claude-code - The “Don’t Fuck Up My Repo” Protector 🛡️
What it does: Sets up git hooks that prevent you from running dangerous commands like git push --force, git reset --hard, or git clean -fd.
When to use it: Always. Unless you enjoy explaining to your team why you just deleted the main branch. 😅
Why it’s awesome: It’s like having a safety net. You can code fearlessly knowing that even if you do something stupid, the hooks will save your ass. 🍑
14. /migrate-to-shoehorn - The TypeScript Cleaner 🧹
What it does: Replaces TypeScript as type assertions with the shoehorn utility, which is a safer way to do type assertions.
When to use it: When your codebase is full of as any (you know who you are 🤦♂️).
Why it’s awesome: It makes your types safer without requiring a complete rewrite. It’s like a type-safe migration on easy mode. 😎
15. /scaffold-exercises - The Exercise Creator 📚
What it does: Creates a directory structure for coding exercises (useful if you’re teaching or learning).
When to use it: When you’re creating a course or tutorial and need to scaffold exercises.
Why it’s awesome: It saves you from manually creating folders and files like a peasant. 😏
16. /setup-pre-commit - The Code Quality Enforcer 🚫
What it does: Sets up Husky + lint-staged to run linters and formatters on every commit.
When to use it: Immediately after setting up a new project. Because nobody wants to review code that doesn’t pass the linter. 🤢
Why it’s awesome: It prevents “But it works on my machine!” syndrome. If it doesn’t pass the linter, you can’t commit it. Period. 🚫
🚀 How to Install and Use These Skills
Alright, enough talk. Let’s get these skills installed so you can actually use them! 😎
Step 1: Install the Skills 📦
Run this command in your terminal:
1 | npx skills@latest add mattpocock/skills |
It’ll ask you which skills you want to install. Select all of them (or at least the ones you think you’ll use).
IMPORTANT: You must select /setup-matt-pocock-skills because it’s the prerequisite for everything else. If you don’t, nothing will work, and you’ll be sad. 😢
Step 2: Run the Setup Wizard 🧙♂️
After installation, run:
1 | /setup-matt-pocock-skills |
It’ll ask you:
- What issue tracker do you use? (GitHub, Linear, or file-based)
- What labels do you use for triage? (bug, feature, chore, etc.)
- Where do you keep your documentation? (usually
docs/)
Answer these questions, and you’re good to go! 🎉
Step 3: Use the Skills! 🎯
Now you can use any of the 16 skills by typing /skill-name in Claude Code (or Cursor, or Codex).
Pro tip: Start with /grill-with-docs on your next feature. It’ll change your life. Or at least your codebase. 😏
💡 The Crown Jewel: CONTEXT.md (Why This Changes Everything)
Okay, I’ve mentioned CONTEXT.md like 57 times in this article. Let me explain why it’s the most important thing you’ll take away from this system.
What Is CONTEXT.md? 🤔
It’s a file that lives in your project root and contains:
- Terminology (what words mean in your domain)
- Definitions (what’s the difference between X and Y?)
- Boundaries (what’s in scope and what’s not?)
- Invariants (what must ALWAYS be true?)
It’s like a dictionary for your codebase.
Why Is It Awesome? 🚀
Shared Language: You and the AI (and your team) speak the same language. No more, “Wait, what’s a webhook?” 🗣️
Token Efficiency: The AI doesn’t need to ask you 47 questions to understand your codebase. It just reads
CONTEXT.mdand gets it. 💰Onboarding: New team members (or future you) can read
CONTEXT.mdand understand the project in 5 minutes instead of 5 days. 📝Consistency: The AI uses the same terminology in variable names, function names, and documentation. Your codebase becomes navigable. 🗺️
Example CONTEXT.md (Simplified) 📄
1 | # Context |
See how useful that is? Now the AI won’t name your variables user1, user2, tempUser, etc. It’ll use consistent terminology because it read the CONTEXT.md. 🎯
🥊 Matt’s Skills vs. The World (Why This Is Better)
You might be thinking, “Okay, but there are other AI coding frameworks out there. Why should I use this one?”
Great question! Let’s compare Matt’s Skills to the heavyweight frameworks like BMAD, Spec-Kit, and GSD.
| Feature | BMAD / Spec-Kit / GSD | Matt Pocock’s Skills |
|---|---|---|
| Philosophy | “We’ll take over your entire workflow” 🎭 | “Here are some tools, use them how you want” 🛠️ |
| Coupling | Tightly coupled (must use all or nothing) 🔗 | Loosely coupled (use only what you need) 🧩 |
| Complexity | High (steep learning curve) 📈 | Low (each skill is a small file you can read) 📖 |
| Flexibility | Low (the framework decides for you) 🚫 | High (you decide when and how to use each skill) 🚀 |
| Editability | Hard (good luck modifying a framework) 😰 | Easy (each skill is a small file you can tweak) ✏️ |
| Target Audience | Beginners who need hand-holding 🧑🎓 | Experienced engineers who want tools, not frameworks 🧙♂️ |
| File Structure | Prescriptive (must follow their structure) 📂 | Flexible (use your own structure) 📁 |
| Role-Based | Yes (has PM, architect, developer roles) 🎭 | No (you’re the boss, the AI is the tool) 💪 |
The Key Insight 💡
Matt’s philosophy is:
“Real engineers don’t want a framework that takes over their workflow. They want tools they can mix and match.”
It’s the difference between:
- BMAD: “I’m going to be your project manager, architect, and developer. Just sit back and relax.” (Spoiler: You won’t relax. You’ll be frustrated. 😤)
- Matt’s Skills: “Here’s a debugging tool. Here’s a TDD tool. Here’s a requirement clarification tool. Use them when you need them.”
One treats you like a child who needs hand-holding. The other treats you like an adult who knows what they’re doing.
Guess which one actually works in practice? 😏
🎯 When to Use This (And When NOT To)
✅ Use This If…
You’re an experienced engineer who’s been using AI tools and thinking, “This is cool, but it’s not quite right.” 🤔
You’ve been burned by “vibe coding” and want to write production code that doesn’t fall apart after 2 weeks. 💩
You want tools, not frameworks. You want to compose your own workflow, not have it dictated to you. 🧩
You care about code quality. You want tests, architecture, and maintainability - not just “it works on my machine.” ✅
❌ Don’t Use This If…
You’re a beginner who wants a complete system that tells you exactly what to do. Go use BMAD or Spec-Kit. They’ll hold your hand. 🧑🎓
You don’t care about code quality. You just want to ship shit fast and fix it later (aka never). 🚀
You don’t want to think. You want the AI to do everything for you, and you’re okay with the consequences. 🤖
🎉 Conclusion (Or: Why You Should Star This Repo Right Now)
Alright, let’s wrap this up.
Matt Pocock’s Skills is, quite frankly, the best thing to happen to AI-assisted coding since… well, since AI-assisted coding became a thing. 😅
It’s:
- Practical (born from real engineering, not theory)
- Flexible (use what you need, ignore what you don’t)
- Editable (you can tweak it to fit your workflow)
- Effective (it actually makes you a better engineer)
If you’re serious about using AI to write production code (instead of just generating fancy demo apps that break in production), this is the system for you.
So go star the repo: mattpocock/skills ⭐
Your future self (and your teammates) will thank you. 🙏
📚 Resources (Because I’m Not a Monster)
- GitHub Repo: mattpocock/skills - Go star it. Now. 🌟
- Matt’s Website: Total TypeScript - The best TypeScript course on the planet 🌍
- Matt’s Twitter: @mattpocockuk - Follow him for TypeScript tips and AI hot takes 🔥
💬 Final Thoughts (Or: Why I’m Not a Robot)
Look, I could keep writing, but my fingers are getting tired, and I’m pretty sure you get the point by now. 😅
Matt Pocock’s Skills is legit. It’s not some AI influencer selling you bullshit. It’s a real engineer sharing real tools that he uses every day to build real software.
And in a world full of “10x engineer” grifters and “AI will replace developers” doomers, that’s refreshing as hell. 😎
So go check it out. Install the skills. Use them. And maybe - just maybe - you’ll stop writing code that makes you question your career choices. 🚀
Now if you’ll excuse me, I have some /tdd to do. Because unlike some people, I actually write tests. 😏
Happy coding, you beautiful bastards! 🧙♂️✨
P.S. If you made it this far, you either really care about AI-assisted coding, or you’re procrastinating on something important. Either way, I’m not judging. 😂
P.P.S. If you find a bug in my article, good luck - I used /tdd to write it, so it’s probably perfect. (Just kidding, I didn’t. Please don’t hurt me, Matt. 😅)
P.P.P.S. Seriously though, go star the repo. The man deserves it. ⭐
