This is an explainer, not a review. I read the repo, its changelog and its commit history, and I have not run these skills on Trellis yet. Whatever I say about how they behave comes from the files, the docs or other people.
Matt Pocock skills is a free, MIT-licensed GitHub repo of small markdown files that teach a coding agent like Claude Code or Codex to work like a careful engineer. You type a slash command such as /grill-me or /tdd, and the agent follows a routine instead of improvising. Matt Pocock, the educator behind AI Hero, shipped 1.3.1 on October 4. The plugin ships 27 skills; the repo holds 38 counting misc and in-progress ones.
Below: install, all 27 skills, grill-me’s history, context cost, critics, who should skip it, and GSD, BMAD and Spec-Kit compared.
Why this repo took off
As of October 23 it has over 300,000 stars and over 25,000 forks, on a repo created February 3. Franchement, I can’t remember another plain-text repo growing like this.
My reading: these are the files Matt works from every day, opened up. His pitch is that big frameworks take over the process, while these skills are small, editable and work with any model. It lives in the GitHub repo.
How to install Matt Pocock skills
The README calls it a 30-second setup. Claude Code is one command:
claude plugin install mattpocock-skills@claude-plugins-officialCodex takes two lines:
codex plugin marketplace add mattpocock/skills
codex plugin add mattpocock-skills@mattpocockCopilot and Gemini CLI have commands in the README. For Cursor, OpenCode, Windsurf and the rest, the skills.sh installer copies editable files into your project. Swap cursor for your agent, or leave the flag out and it asks:
npx skills@latest add mattpocock/skills -a cursorPick one method per agent, because installing both ways means every skill shows up twice. The skills.sh copy is yours to edit and updates with npx skills@latest update.
One trap on that path: include setup-matt-pocock-skills when the installer asks. The repo’s FAQ has an entry that starts “I installed grill-me on its own and nothing happens.” Reason: grill-me hands off to grilling, and grill-with-docs also needs domain-modeling. Take everything. Then run /setup-matt-pocock-skills once in each repo, the step people forget. It asks about your issue tracker, ticket labels and docs location.
What the 27 skills do, and who can call each one
The axis that matters more than the names is who can call a skill. A user-only skill has disable-model-invocation: true in its frontmatter and runs only when you type it. The others can also fire when the agent decides they fit. I read all 27 frontmatters for that column. The “take” is from reading, not running.
| Skill | What it does | Who can call it | My take (read, not run) |
|---|---|---|---|
| ask-matt | Router: which skill fits | You only | Run it first |
| setup-matt-pocock-skills | One-time repo setup | You only | Not optional |
| grill-me | Shortcut that starts a grilling | You only | My first try |
| grilling | The interview engine | You or the model | Worth reading line by line |
| grill-with-docs | Grilling plus glossary and ADRs | You only | Where I start |
| domain-modeling | Sharpens terms and ADRs | You or the model | Docs: auto-loading is weak |
| research | Primary-source research to Markdown | You or the model | I do this by hand |
| to-spec | Conversation to spec, no interview | You only | Good after a grill |
| to-tickets | Plan to tickets with blocking edges | You only | Same |
| wayfinder | Decision-ticket map for huge work | You only | Overkill for most |
| triage | Issue and PR triage states | You only | Later, if backlog hurts |
| to-questionnaire | Questions for someone else | You only | Curious, not urgent |
| implement | Builds a ticket, red-green, review | You only | The one I must test |
| implement-spec | Builds a whole spec | You only | Same, wider |
| tdd | Test-first routine | You or the model | Mock complaint lives here |
| prototype | Throwaway prototype | You or the model | Handy for UI doubts |
| diagnosing-bugs | Hard-bug diagnosis loop | You or the model | First try on a bug |
| codebase-design | Deep-module vocabulary | You or the model | Vocabulary, not workflow |
| improve-codebase-architecture | Architecture report, then grill | You only | A weekend one |
| code-review | Standards and Spec review | You or the model | For ad-spend code |
| pr | Writes the PR body | You or the model | Tiny, why not |
| retro | Session retrospective | You only | End of my test week |
| wizard | Bash wizard for human-only steps | You or the model | Eberhardt got stuck here |
| handoff | Handoff doc for another agent | You only | Compare to /compact |
| teach | Teaches you a concept | You only | For me, not the job |
| wait-what | Re-pitches the last message | You only | Best name in the repo |
| writing-for-agents | Rules for skills and AGENTS.md | You or the model | Read before editing |
Of the 27, 16 are user-only and 11 can be called by the model. The other 11 in the repo (4 in skills/misc, 7 in skills/in-progress) are not in the plugin.
The grill-me skill started as 28 words
If you try one thing, try /grill-me. The agent interviews you about your plan until every branch of the decision tree is settled. I walked the full git history of the file to see how a viral skill gets built.
February 25, first version: 28 words, two sentences, no frontmatter. Interview me relentlessly, one decision-tree branch at a time. By March 26 it had frontmatter, “provide your recommended answer” and “ask the questions one at a time,” and the body was 56 words. That is the version most people mean.
May 31 is the structural change. The text moves into a new skill called grilling, and grill-me becomes a 20-word pointer that only you can call. Other skills now reuse the engine.
July 3 adds a confirmation gate, so the agent cannot build until you say the understanding is shared. July 6 is my favourite commit. Students reported that /wayfinder was grilling itself, answering its own questions. The commit message quotes Matt: “that sounds like a bug.” The fix separates facts the agent can look up from decisions that belong to you.
July 16 is the big reversal. The March rule, one question at a time, is replaced by rounds: every question whose prerequisites are settled goes out in one numbered batch. The changeset says the same 13 questions now take about 3 rounds instead of 13. On October 7 came the latest tweak, a line asking the agent to word each question so that “yes” accepts its recommendation.
So a 28-word idea became a 56-word skill, then a roughly 330-word engine (frontmatter included). The repo’s SCOPE.md keeps an issue open only if it describes a real failure in a real session, and this history shows that rule working. The old behaviour survives: the docs call one-at-a-time a supported setting for people who work in a second language. Me, I will turn it on.
What it costs in context
27 skills sounds like a context hog. The Claude Code skills docs say descriptions load so the model knows what exists, while full content loads only when invoked, and with disable-model-invocation: true the description is not in context at all.
So only the 11 model-invoked descriptions advertise themselves. I counted them with tiktoken and its o200k_base tokenizer. Claude’s own tokenizer is not public, so this is a proxy, not a bill. The 11 descriptions are 2,150 characters and 445 tokens, or 479 with the skill names. The characters-divided-by-four rule gives about 540, so it overshoots by roughly 20 percent here. The biggest is code-review at 91 tokens, the smallest pr at 7.
The bodies are the real weight, paid only when you call them: grilling is 391 tokens, wayfinder 2,767, ask-matt 2,955. The /implement docs say a non-trivial ticket over 100k tokens is normal. The listing is cheap. The work is not.
I made the same standing-cost argument in my post on minimal agent harnesses. I did not verify how Codex, Cursor and the other agents load skills.
What critics found, starting with Eberhardt
Colin Eberhardt, CTO at Scott Logic, rebuilt KartLog, a real karting-tracker app on Supabase, through the skills and wrote an honest review. Around a year ago he tried SpecKit and found it “did little more than emit excessive amounts of markdown”. This time he was “genuinely delighted” by the implementation loop, where the reviews caught bugs. His reservations:
- The spec.
/to-specproduced an 80-line spec in user-story form. For basic CRUD he would “personally favour a specification that represents this as a data model”, and warns that this is where to be careful of “AI theatre”. - The tests. For a client of around 15 lines, the agent tested every entity, and “the tests do more to validate the mocks that they have constructed than the code itself!”
- The wizard. The Supabase wizard sent him to pages that no longer existed, and “the shell script has no escape hatch.”
- The feel. “The output occasionally felt a little amateurish,” like “simulating the rituals of software engineering” without the judgement behind them.
His conclusion is that skills “do not eliminate the need for judgement”. He also says his test was greenfield and modest, and he did not tailor the skills.
On Hacker News, commenters were blunter: one thinks it could all be a single AGENTS.md, another says preset instructions never work out in the long run, another that skills are hardly transferable between people.
How do I weigh it? The AGENTS.md point is partly right: if yours is tight, much of this pack is a tidier version of it, and what it adds is the order of steps. Eberhardt’s spec complaint I can fix, since the file is Markdown and I can write “data model, not user stories”. His mocks complaint is the one I trust most, and I will watch for it. His app was greenfield; Trellis is not, so neither of us has tested the brownfield case.
Who should not use this, and where it is overkill
- Tiny fixes, or people with a tuned AGENTS.md. The repo agrees:
wayfinderstops when it finds no fog, theto-specdocs say to skip the spec when the work fits one window, and SCOPE.md says one person’s tweaks belong in your own CLAUDE.md. For a one-line change, just ask the agent. - Teams on Jira, Linear, Azure DevOps or Trello. First-class support is GitHub, GitLab and local markdown. Everything else goes through an “Other” option where you describe your workflow, and Jira requests were closed as out of scope.
- Weaker or faster models. The docs say lower-effort and non-frontier models skip the confirmation gate and cut a grilling to a couple of questions.
- Regulated codebases. This one is my judgement: I found nothing in the repo about compliance, while the Spec-Kit README lists presets to enforce organizational or regulatory standards.
How it compares to GSD, BMAD and Spec-Kit
Matt’s README puts these three on the other side of the fence. I read each README on October 23 and have not run any of the four.
| Project | Stars on Oct 23 | What it is | I would pick it when |
|---|---|---|---|
| Matt’s skills | Over 300,000 | 27 small Markdown skills you edit | You want to own every file, adopt piece by piece |
| Spec-Kit | Over 140,000 | A specify CLI: spec, plan, tasks, implement; presets for team rules | You want a written process and team standards |
| BMAD | Over 54,000 | Agile roles and a full idea-to-delivery path | You want planning, architecture and roles, with a bigger team |
| GSD | Over 64,000 (archived original), over 10,000 (GSD Core) | Phase loop that runs work in fresh-context sub-agents | You build large things in long sessions and context rot is your pain |
Spec-Kit is a Python CLI that walks you through a constitution, a spec, a plan, tasks, then implement and converge. I would pick it for a team that wants a written process in every repo.
BMAD calls itself agile AI-driven development. It brings product, architecture, UX and test roles into the agent. I would pick it for a bigger team that accepts more ceremony for planning and architecture.
GSD has a story. The original repo, gsd-build/get-shit-done, is archived and points to GSD Core. Its loop is discuss, plan, execute, verify, ship, with sub-agents in fresh context to fight what it calls context rot. I would pick it for long builds where that is the pain.
When do I choose Matt’s? When I want to read every file, delete half of them, and adopt one skill at a time. The others ask you to buy into a process. Bon, that is also the weakness: you design the process yourself.
Two things to know before you try it
Misc skills install the same way, for example npx skills@latest add mattpocock/skills --skill=git-guardrails-claude-code, which blocks risky git commands. But misc is frozen, and one closed issue title says the hook fails open without jq. Check it before you trust it near git.
If /grill-with-docs asks everything at once with no recommended answers, it probably never loaded grilling. The docs call this a real bug, still unfixed, and the fix is to ask the agent whether it loaded grilling and domain-modeling.
What I run on Trellis next
This is my plan, not a result. It is the experiment I run next, on the repo that hurts most.
Day one: install and run /setup-matt-pocock-skills. Day two: take one fuzzy feature through /grill-with-docs, one question at a time (a supported CLAUDE.md line), no code, and read the GLOSSARY.md it leaves. Day three: /to-spec, /to-tickets, then let /implement build one ticket. At Trellis a bad change can touch a seller’s ad budget, so I want to see the review step. End of the week: /retro, then decide what stays. I will count Eberhardt’s mock-heavy tests and the tokens per ticket.
The follow-up post, with the Trellis results, will say what survived and what I deleted.
