Matt Pocock's Skills: Small, Editable Agent Skills That Push Back on Vibe Coding
This repository collects Matt Pocock's reusable agent skills for TypeScript, testing, debugging, and day-to-day software work.
At a glance
- What is it?
- A look at mattpocock/skills, a collection of composable agent skills for TypeScript, testing, and debugging, and why its emphasis on grilling sessions and shared language might beat heavyweight process frameworks.
- Who is it for?
- Adopt this if you use Claude Code or Codex and want a lightweight, editable layer of process that forces alignment before coding. Skip it if you prefer a framework that owns the whole workflow, or if you are not willing to run a setup command per repo.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Shell, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What This Repo Actually Gives You
mattpocock/skills is a collection of agent skills built by Matt Pocock, aimed at TypeScript, testing, debugging, and everyday software work. The README positions these as an alternative to process-heavy approaches like GSD, BMAD, and Spec-Kit. Those frameworks, the argument goes, own the process and take away control, making bugs in the process hard to resolve. These skills are designed to be small, easy to adapt, and composable. They work with any model. The target user is a developer who uses coding agents like Claude Code or Codex and wants more control over how the agent behaves, not a team looking for a turnkey methodology.
The Core Mechanism: Grilling Sessions and Shared Language
The repo's central idea is that the most common failure mode is misalignment: you think the agent knows what you want, then it builds the wrong thing. The fix is a grilling session, a structured interrogation where the agent asks you detailed questions before writing code. Two skills implement this: /grill-me for non-code uses, and /grill-with-docs for engineering changes. The latter adds a shared language component. The README argues that agents dropped into a project use 20 words where 1 will do, and that a shared language document fixes this. The example given is the phrase 'materialization cascade' replacing a long explanation about lessons becoming 'real' in a file system. This shared language is documented in a CONTEXT.md file and in ADRs. The claimed payoff is that variables, functions, and files get named consistently, the codebase becomes easier for the agent to navigate, and the agent spends fewer tokens on thinking. This is a concrete mechanism, not a vague promise, and it is the heart of the repo.
Installation: Two Philosophies, One Command
Installation takes about 30 seconds, according to the README. There are two paths. For Claude Code, you run `claude plugins install mattpocock-skills` or `/plugin install mattpocock-skills` inside a session. This installs the whole set as a managed, read-only bundle that updates automatically when the author ships changes. For Codex and other agents, you run `npx skills@latest add mattpocock/skills`. This copies editable skill files into your repo, and you can choose which skills to take. The README warns to make sure `setup-matt-pocock-skills` is among them. The same command works for tinkerers on any agent, including Claude Code, and writes files you own and can edit. Updates are manual via `npx skills update`. The README explicitly says to pick one method, because installing both leaves you with every skill twice. After installation, you run `/setup-matt-pocock-skills` once per repo. That command asks which issue tracker you use (GitHub, Linear, or local files), what labels you apply when triaging tickets, and where to save docs. This setup step is a real requirement, not optional.
The Feedback Loop Fix: More Than Just Alignment
Beyond alignment, the repo addresses the problem of code that still does not work. The README quotes The Pragmatic Programmer: 'Always take small, deliberate steps. The rate of feedback is your speed limit.' The argument is that without feedback on how the code actually runs, the agent is flying blind. The fix is the usual tranche of feedback loops: static types, browser access, and presumably other runtime checks. The README is truncated at this point, so the exact skills for these loops are not fully visible, but the direction is clear. The repo includes skills for TypeScript, testing, and debugging, which likely cover these. The point is that the repo treats feedback as a first-class concern, not an afterthought. This is a specific design choice: instead of relying on the agent's training, you give it explicit tools to verify its own output.
Limitations and Wrong Use Cases
The most obvious limitation is that this is a personal collection. The skills are built around Matt Pocock's workflow, and while the README encourages hacking on them, they may not fit your process without modification. The README itself says to 'hack around with them. Make them your own.' That is an admission that they are not universal. Another limitation is the dependency on a setup command per repo. If you forget to run `/setup-matt-pocock-skills`, the skills may not work correctly, because they depend on knowing your issue tracker and labels. Also, the skills are only as good as the model you use. The README says they work with any model, but the grilling session relies on the model asking good questions, which is not guaranteed. Finally, if you install both the plugin and the editable files, you get duplicates, which is a footgun the README warns about. This is not a tool for teams that want a standardized process across many developers; it is a tool for an individual who wants to shape their own agent's behavior.
Alternatives: Process Frameworks vs. Editable Skills
The README names GSD, BMAD, and Spec-Kit as alternatives that try to own the process. The key difference is control. Those frameworks provide a complete workflow, which can be helpful but also rigid. If a bug appears in the process itself, you have to debug the framework. mattpocock/skills takes the opposite approach: small, composable skills that you can edit and replace. The trade-off is that you get less guidance and more responsibility. With GSD, you might get a structured sequence of steps out of the box. With this repo, you get a set of prompts and instructions that you must adapt to your own context. The README also mentions a native Codex plugin is on the roadmap, which suggests that the current Codex experience is not as polished as the Claude Code one. So if you are a heavy Codex user, you may be waiting for better integration.
Maintenance and License Implications
The repo is under the MIT license, which means you can use, modify, and distribute the skills freely, as long as you preserve the copyright notice. This aligns with the tinkerer philosophy. Maintenance cost depends on which installation method you choose. The Claude Code plugin updates automatically when the author ships changes, so you get fixes and new skills without effort, but you also get changes you did not ask for, which could break your workflow. The editable files require manual updates via `npx skills update`, which gives you control but also means you are responsible for tracking upstream changes. The repo has recent releases, with v1.2.3 pushed on 2026-08-06, so the project is actively maintained. There is no stated deprecation policy, so if you fork the skills, you are on your own. The README mentions a newsletter with about 60,000 subscribers, which suggests a community, but the repo itself does not have a formal contribution guide.
Editorial conclusion
Adopt this if you use Claude Code or Codex and want a lightweight, editable layer of process that forces alignment before coding. Skip it if you prefer a framework that owns the whole workflow, or if you are not willing to run a setup command per repo. Before adopting, verify that the skills you need exist in the repo, check the latest release notes for changes, and decide whether you want the managed plugin or the editable files, because installing both duplicates every skill.
Community notes