The 38 skills Matt Pocock uses every day for real engineering
mattpocock/skills
Daily-working set of the Total TypeScript author: 38 SKILL.md files (engineering 20, productivity 7, misc 4 frozen, in-progress 7) behind a user-invoked/model-invoked contract, a SCOPE.md admission bar and a shared GLOSSARY.md; installs as a Claude Code, Codex, Copilot or Gemini plugin, or an editable skills.sh copy.
Editor's takeSells parts, not a process: 38 SKILL.md behind a strict user/model-invoked contract, a SCOPE.md admission bar and a shared GLOSSARY.md; the spec-to-tickets-to-implement-spec pipeline is the most complete agentic engineering loop in this channel.
claude plugin install mattpocock-skills@claude-plugins-officialPositioning: skills for real engineers, not vibe coding
The daily-working set of Matt Pocock (author of Total TypeScript), in the repo's own words: "My agent skills that I use every day to do real engineering - not vibe coding." As of 2026-10-14 the repo holds about 289.9k stars and 24.3k forks, is MIT licensed, and lists Shell as its primary language, because the product is a Markdown instruction set with a thin glue layer of scripts and plugin manifests, not a codebase.
The most useful stance here is the rejection of process-owning frameworks. The README names GSD, BMAD and Spec-Kit: they help by owning the process, and the price is that you lose control and a bug inside the process becomes hard to diagnose. The alternative is three properties, small, easy to adapt, composable, with an explicit note that the skills work with any model and that you are expected to hack them into your own.
38 SKILL.md files, four buckets, one invocation contract
| Bucket | Count | Contents |
|---|---|---|
| engineering | 20 | User-invoked: ask-matt, grill-with-docs, triage, improve-codebase-architecture, setup-matt-pocock-skills, to-spec, to-tickets, implement, implement-spec, wayfinder, retro. Model-invoked: prototype, diagnosing-bugs, research, tdd, domain-modeling, codebase-design, code-review, pr, wizard |
| productivity | 7 | User-invoked: grill-me, handoff, teach, to-questionnaire, wait-what. Model-invoked: grilling, writing-for-agents |
| misc | 4 | git-guardrails-claude-code, migrate-to-shoehorn, scaffold-exercises, setup-pre-commit. Frozen and unmaintained by policy; every issue against them is closed |
| in-progress | 7 | chief-of-staff, claude-handoff, loop-me, setup-ts-deep-modules, writing-beats, writing-fragments, writing-shape. Beta on purpose, not shipped in the plugin |
The split that matters is not the bucket but who may invoke. User-invoked skills carry disable-model-invocation: true (plus policy.allow_implicit_invocation: false in agents/openai.yaml) and are reachable only when you type them; their job is orchestration. Model-invoked skills hold the reusable discipline and may also be reached automatically when the task fits. A user-invoked skill may call model-invoked skills but never another user-invoked one, and .agents/invocation.md requires cross-references to say Call the Skill tool with "name" rather than prose like "run the /grilling skill", because prose references silently fail to load. PR #878 standardised that convention and PR #880 removed the six call sites that used it to reach user-invoked skills, in to-spec, wayfinder, to-tickets, triage, code-review and diagnosing-bugs.
The interrogation family: the agent asks you first
grill-me and grill-with-docs are the author's most popular skills: a relentless interview about your plan or design until every branch of the design tree is resolved. grilling is the reusable model-invoked primitive behind grill-me, grill-with-docs, triage, wayfinder and improve-codebase-architecture. wait-what runs the other direction: fire it the moment a message does not land and the agent re-pitches it in plain English using your GLOSSARY.md vocabulary. to-questionnaire turns a decision you cannot answer alone into an async Markdown questionnaire for the one person who can, grilling you about the send rather than the subject.
GLOSSARY.md: shared language as infrastructure
The argument is straight out of domain-driven design: at the start of a project the developers and the domain experts speak different languages, and an agent dropped into a repo guesses at jargon, spending 20 words where one will do. The fix is a glossary the skills read, so project conventions never have to be restated per prompt. The README's example compresses "a lesson inside a section of a course is made real, i.e. given a spot in the file system" into "there is a problem with the materialization cascade", and that concision pays off session after session: names stay consistent, the codebase stays navigable, and the agent spends fewer tokens on thinking.
The repo dogfoods the idea. Its root GLOSSARY.md, successor of the earlier CONTEXT.md convention, defines Issue tracker, Issue, Decision ticket and Triage role, states their relationships, and records flagged ambiguities such as retiring "backlog" entirely. grill-with-docs builds that glossary and the ADRs inline while it interviews you; domain-modeling keeps sharpening it afterwards by challenging terms against edge-case scenarios. The author calls it the single coolest technique in the repo.
From idea to merged code: the spec, ticket and implement pipeline
The engineering bucket chains into a complete loop. to-spec synthesises the current conversation into a spec with no interview; to-tickets breaks any plan, spec or conversation into tracer-bullet tickets that declare their blocking edges; implement builds one ticket at a pre-agreed TDD seam and closes with code-review; and implement-spec, graduated from in-progress into engineering in release 1.3.0, works the whole ticket graph on a single integration branch, running background implementer subagents across the ready frontier and communicating through context pointers instead of copied content. Above all of them sits wayfinder for work bigger than one agent session: a shared map issue of decision tickets, each a question whose resolution is a decision, resolved one at a time until the route is clear. retro and pr close the loop: the former audits the agent environment after a session, most severe first; the latter fixes the shape of a PR body, smallest clear visual first, before/after evidence, and an explicit one-way vs two-way door merge call.
Feedback loops get the same discipline. tdd enforces red-green-refactor one vertical slice at a time and teaches what makes a good or bad test; diagnosing-bugs is a phase-gated loop (build a feedback loop that goes red on this bug, minimise, hypothesise, instrument, fix, regression-test); code-review runs two parallel sub-agents, one on repo standards plus a Fowler smell baseline and one on fidelity to the originating spec, so neither pollutes the other; and improve-codebase-architecture surveys the codebase for deepening opportunities in John Ousterhout's sense (deep modules: a lot of behaviour behind a small interface) and hands you candidates as a visual HTML report, explicitly a survey rather than a rescue.
A curation bar, a frozen misc, five install paths
SCOPE.md keeps the set small on purpose: an issue stays open only if it reports an observed failure from a real session (what you ran, what the skill did, what you expected) and fits the philosophy; hypothetical improvements are closed, reactions do not count, and .out-of-scope/ publishes every rejected concept with its reasoning, from frozen misc to subagent recursion. Promoted skills carry a human docs page at aihero.dev/skills-<name> with four fixed sections (what it does, when to reach for it, common questions, it's working if), and the repo bans em-dashes from all prose, hand-rewriting each sentence instead of substituting the character.
# Claude Code (plugin, self-updating)
claude plugin install mattpocock-skills@claude-plugins-official
# Codex (self-updates at startup)
codex plugin marketplace add mattpocock/skills
codex plugin add mattpocock-skills@mattpocock
# GitHub Copilot CLI / VS Code
copilot plugin marketplace add mattpocock/skills
copilot plugin install mattpocock-skills@mattpocock
# Gemini CLI (per bucket, re-run both to update)
gemini skills install https://github.com/mattpocock/skills.git --path skills/engineering
gemini skills install https://github.com/mattpocock/skills.git --path skills/productivity
# Any other agent, editable copy (cursor, opencode, devin, windsurf, amp, pi)
npx skills@latest add mattpocock/skills -a <agent>Whichever path you pick, run /setup-matt-pocock-skills once per repo: it records which issue tracker you use, which labels triage applies and where docs live, and every engineering skill reads that configuration instead of hardcoding GitHub. The README also warns that the plugin route and the skills.sh route are alternatives, not additives: installing both gives you every skill twice.
Our take
Against a whole-process harness like Superpowers, this repo is the spare-parts drawer: code-review, diagnosing-bugs and tdd each stand alone without buying a methodology, which is what "composable" means in practice. The discipline is yours to supply, and that is the point rather than a gap. Even if you install nothing, two artifacts are worth stealing outright: the user-invoked / model-invoked invocation contract with its "call the Skill tool by name" rule, and a SCOPE.md plus .out-of-scope/ archive that make curation decisions visible instead of silent.