Most frameworks for AI-assisted development try to own the whole process — hand over a spec, get back an app, trust the pipeline in between. Matt Pocock's skills repo, built by the well-known TypeScript educator behind Total TypeScript and AI Hero, takes the opposite position: small, composable Agent Skills that fix specific, named failure modes in AI-assisted engineering, without taking control away from the person actually building the thing.
The Argument Against End-to-End Frameworks
The README makes its positioning explicit: approaches that try to own the whole development process end up making it hard to actually debug what goes wrong, because you've traded visibility for automation. Pocock's skills are built to be small, easy to adapt, and composable instead — designed to be read, understood, and modified rather than trusted as a black box. That's a meaningfully different bet than a framework promising to handle requirements-to-deployment in one pass; it's closer to a toolbox of specific fixes for specific problems than a replacement for engineering judgment.
Four Named Failure Modes, Four Fixes
Rather than a generic "best practices" list, the repo is organized around four concrete problems the author has actually observed, each with a specific skill built to address it:
| Problem | Fix | Skill |
|---|---|---|
| The agent builds the wrong thing | A structured "grilling session" — the agent asks detailed clarifying questions before writing code | /grill-me, /grill-with-docs |
| The agent is unnecessarily verbose | A shared project vocabulary that replaces long descriptive phrases with concise, agreed-on terms | Built into /grill-with-docs |
| The code doesn't actually work | Enforced feedback loops — static types, browser access, and a red-green-refactor TDD discipline | /tdd, /diagnosing-bugs |
| The codebase turns into unmanageable complexity | Periodic architecture surveys that surface concrete refactoring candidates | /to-spec, /improve-codebase-architecture |
The alignment skills are described as the most-used in the set, and the reasoning behind them is straightforward: most software misalignment between a person and whoever's building for them — human or agent — comes from an unstated gap in understanding, not a technical failure. A structured round of clarifying questions before code gets written is a cheap fix for an expensive problem, and it's notable that the fix here is a conversation discipline, not a new tool.
The Shared-Vocabulary Trick Is Worth Understanding on Its Own
One detail is worth calling out specifically because it's a genuinely transferable idea outside this specific toolset: building a project-specific glossary document that replaces long, jargon-laden descriptions with short, agreed-on terms doesn't just make output more concise — it makes an agent's variable, function, and file names more consistent (since they draw from the same shared vocabulary), makes the codebase easier for the agent to navigate on later sessions, and reduces the token cost of the agent's own reasoning because it has a more compact language to think in. That's a nice example of a very simple intervention — write down a glossary — compounding into several unrelated benefits.
The Feedback-Loop and Architecture Discipline
The /tdd skill enforces a red-green-refactor loop specifically because agents given no feedback signal on whether their code actually runs tend to produce code that looks plausible and doesn't work — a failing test written first gives the agent a concrete, checkable target rather than a vibe to match. The /diagnosing-bugs skill wraps debugging into a disciplined, phase-gated loop rather than letting an agent guess at fixes; a recent release specifically hardened this skill to redact secrets from captured command output and artifacts by default, which is a small but meaningful detail for a skill whose whole job is showing terminal output back to a human.
On the architecture side, /improve-codebase-architecture is explicitly described as a survey tool, not a rescue tool — it's built to periodically scan a codebase for concrete "deepening" opportunities (per the module-design principle that the best modules expose a lot of functionality through a simple interface) and hand back real candidates, but the README is direct that on a genuinely tangled legacy codebase, it will find problems without untangling them for you. That's an honest scoping of what an automated architecture review can actually do.
The Full Reference: User-Invoked vs. Model-Invoked
The repo's skill list splits on one axis worth understanding before adopting any of it: who's allowed to invoke a given skill. User-invoked skills only run when you type them yourself — /grill-me, /tdd, /to-spec — and their job is to orchestrate a workflow. Model-invoked skills can be triggered the same way, but the agent can also reach for them automatically mid-task when the situation calls for it — they hold the reusable discipline that a user-invoked skill leans on. The rule that keeps this from turning into a tangle: a user-invoked skill can call a model-invoked one, but never another user-invoked skill directly.
Beyond the four flagship skills already covered, the engineering set includes several more worth knowing about: /ask-matt routes you to the right user-invoked skill when it's not obvious which one fits; /triage moves issues through a defined state machine of roles; /to-tickets breaks a plan into tracer-bullet tickets with explicit blocking dependencies; /implement builds out a spec, driving /tdd at pre-agreed seams and closing with /code-review before anything gets committed; and /wayfinder is built for work too large for a single agent session — it lays out a shared map of decision tickets and resolves them one at a time until the path to the destination is clear.
On the model-invoked side, a few are notable beyond /tdd and /diagnosing-bugs: /prototype builds a throwaway artifact to answer a design question before real code gets written, /research investigates a question against primary sources and writes the findings to a cited file in the repo, /resolving-merge-conflicts works an in-progress git merge or rebase hunk by hunk rather than reaching for --abort, and /wizard generates an interactive bash script that walks a human through steps only a person can do — provisioning infrastructure or running a one-off migration. A separate, non-code-specific productivity set includes /handoff (compact a conversation into a document another agent can pick up cold), /teach, /to-questionnaire, and /wait-what — all four sit on top of /grilling, the same interview primitive behind /grill-me.
Setting Up a Repo for the First Time
Installing the skills is only step one — the README calls for a required second step before the engineering skills are usable in a given repository: running /setup-matt-pocock-skills once. It asks three concrete questions — which issue tracker to use (GitHub, Linear, or local files), what labels get applied during /triage, and where generated docs should be saved — and wires those answers into every other skill that depends on them. Skipping it is the likely reason a skill like /triage would behave unexpectedly on a fresh install.
Two Installation Philosophies
The repo ships two distinct ways to get the skills, and they represent genuinely different philosophies rather than just two download options:
- Claude Code plugin (
claude plugins install mattpocock-skills) — installs the whole set as a managed, read-only bundle from Claude Code's official marketplace that updates automatically when the author ships changes. You subscribe rather than fork. - skills.sh (
npx skills@latest add mattpocock/skills) — copies editable skill files directly into your project, so you own and can modify them, withnpx skills updateto pull upstream changes on your own schedule.
The README is direct that installing both leaves you with every skill twice — pick the philosophy that matches whether you want to hack on the skills or just consume updates passively.
Practical Implications
- These are additive to whatever agent and workflow you already use, not a replacement framework — worth adopting incrementally, starting with the alignment skills, rather than all at once.
- The shared-vocabulary technique is worth stealing even without adopting the whole skill set — writing a project glossary is a low-cost habit any team doing AI-assisted development can adopt directly.
- The
/improve-codebase-architecturesurvey is scoped honestly — treat it as a candidate-finder for a legacy codebase, not an automated cleanup, and budget real engineering time for what it surfaces. - Choose the plugin or the editable-copy install deliberately based on whether your team wants to track upstream changes passively or actively customize the skills for house conventions.
Practical Takeaway
This skill set is a useful counterpoint to any spec-driven or end-to-end AI development framework: instead of trying to own the whole pipeline, it targets four specific, well-understood failure modes with small, inspectable fixes — and it's built by someone with a long, public track record in software engineering education, which shows in how precisely each problem is named before a fix is offered. For teams comparing it against Diagram Design, Hallmark, or other Agent Skill collections, the differentiator here is scope: engineering process discipline rather than design or diagram generation.
Teams building house-specific Claude Code or Codex skills, or evaluating engineering-discipline tooling for AI-assisted development, can get hands-on help from Woyce Technologies.
FAQ
What is Matt Pocock's skills repo?
It's an open-source collection of Claude Code and Codex Agent Skills built by TypeScript educator Matt Pocock, targeting specific engineering failure modes — misalignment with requirements, agent verbosity, unreliable code, and codebase complexity — rather than trying to automate the whole development process end-to-end.
How is this different from frameworks like GSD, BMAD, or Spec-Kit?
Those frameworks try to own the entire development process from spec to deployment. Pocock's skills are deliberately small, composable, and designed to be read and modified — they fix specific problems without taking control of the overall workflow away from the engineer.
What does the "grilling session" skill do?
/grill-me and /grill-with-docs have the agent ask detailed clarifying questions about what you're building before it writes any code, closing the alignment gap that causes an agent to build something different from what you actually wanted.
Is Matt Pocock's skills repo free to use?
Yes, it's MIT-licensed and open source, installable as a managed Claude Code plugin from the official marketplace or as editable files via the skills.sh installer.
What does the TDD skill enforce?
A red-green-refactor loop, where the agent writes a failing test first and then makes it pass — giving it a concrete, checkable feedback signal instead of producing code that looks plausible without verification that it actually works.
Can I edit these skills to fit my own team's conventions?
Yes, if installed via the skills.sh method rather than the Claude Code plugin — that route copies the skill files directly into your project as ordinary, editable files you own, rather than a managed read-only bundle.
What's the difference between a "user-invoked" and a "model-invoked" skill in this repo?
User-invoked skills, like /grill-me or /tdd, only run when you type them and are meant to orchestrate a workflow. Model-invoked skills can also be reached for automatically by the agent when a task calls for them, and hold the reusable discipline that user-invoked skills lean on. A user-invoked skill can call a model-invoked one, but never call another user-invoked skill directly.
Do I need to configure anything before using the engineering skills?
Yes — run /setup-matt-pocock-skills once per repository first. It asks which issue tracker you use, what labels your team applies during triage, and where generated documentation should live, and every other engineering skill in the set depends on those answers being set.
What does /wayfinder do?
It's built for work too large for one agent session to hold: it lays out a shared map of decision tickets on your issue tracker and resolves them one at a time, so a large piece of work stays navigable across many sessions instead of getting lost.