Matt Pocock's Skills Repo Is a Better Pattern Than Vibe Coding

Last updated: June 24, 2026

The Trend Was Real. The Count Was Not The Point.

The original version of this article was a GitHub Trending snapshot. mattpocock/skills had picked up thousands of stars in a day, the repo was everywhere, and the obvious story was that a TypeScript educator had open-sourced his .claude directory.

That story was true, but it missed the better lesson.

Matt Pocock's skills repo matters because it shows a healthier pattern for agent-assisted engineering: small, readable skills that encode workflow discipline without taking over the whole process.

As of this refresh, the public GitHub API shows mattpocock/skills is still active, MIT licensed, Shell-heavy, pushed on June 18, 2026, and sitting around 143k stars with more than 12k forks. The README describes the repo as skills for real engineers, straight from Pocock's .claude directory, and explicitly positions the collection against approaches that own the whole process and make bugs in the process harder to resolve.

That positioning is the interesting part. The repo is not trying to be a giant agent framework. It is trying to make repeatable engineering behaviors portable.

That connects directly to why skills beat prompts for coding agents, Karpathy-style CLAUDE.md rules as product surface, and skills needing production governance. Agent skills are not prompt hacks anymore. They are reusable process units. The broader Agent Skills standard matters here too: skills are increasingly a cross-tool package shape, not only a Claude Code convention.

What Changed Since The First Wave

The old May writeups described the repo mostly as a list of trending slash commands. The current README is more precise.

It splits skills by invocation mode. User-invoked skills are commands you explicitly run, like /grill-me or /to-prd. Model-invoked skills can be reached by the agent when the task fits. A user-invoked skill can call model-invoked skills, but not another user-invoked skill.

That split is useful because it turns skills into a controlled workflow graph. The human still chooses the orchestration moment. The model can still reuse discipline when the task matches.

The current engineering list includes user-invoked skills such as:

• ask-matt, a router over the available user-invoked skills
• grill-with-docs, a requirements interview that updates CONTEXT.md and ADRs
• triage, an issue-state workflow
• improve-codebase-architecture, which produces a visual HTML report before drilling into a chosen improvement
• setup-matt-pocock-skills, the repo-specific setup step
• to-issues, for slicing plans into independently workable issues
• to-prd, for turning a conversation into a product requirements document
• prototype, for throwaway terminal or UI prototypes

The model-invoked engineering skills include diagnosing-bugs, tdd, domain-modeling, and codebase-design. That is a good shape: keep the command surface small, but let the model reach for repeatable discipline inside the work.

The productivity category is also clearer now. grill-me, handoff, teach, and writing-great-skills are user-invoked. grilling is the reusable loop behind the grilling skills. The miscellaneous category includes git guardrails, test migration, exercise scaffolding, and pre-commit setup.

The takeaway is not "install every skill." The takeaway is that skills should be narrow enough to read, adapt, and delete.

The changelog makes that point better than any essay could. In v1.0.0, the repo removed caveman because it was a duplicate test skill that was never meant to be public, removed zoom-out because it went unused, renamed diagnose to diagnosing-bugs, and replaced write-a-skill with writing-great-skills. In v1.0.1, the teach skill became reuse-first by reading components before authoring a lesson. That is what healthy skill maintenance looks like: prune, rename, clarify dependencies, and reuse common pieces.

The Four Failure Modes

The README is organized around four practical failures.

First, the agent did not do what you wanted. Pocock's fix is a grilling session: force the agent to ask detailed questions before it writes code. That aligns with the guardrails in vibe coding without losing the plot. Speed is useful only after the task is understood.

Second, the agent is too verbose. The repo's answer is a shared language document, usually CONTEXT.md, that gives the agent concise domain terms. That is not just a token trick. It is a domain-modeling move. If a project has a term like "materialization cascade," the agent should not spend twenty words rediscovering it in every session.

Third, the code does not work. The answer is feedback loops: static types, browser checks, tests, and a red-green-refactor loop. This is where tdd and diagnosing-bugs matter. They turn debugging from free-form guessing into a sequence: reproduce, minimize, hypothesize, instrument, fix, regression-test.

Fourth, the codebase becomes a ball of mud. Pocock's answer is to care about design every day. to-prd, improve-codebase-architecture, domain-modeling, and codebase-design all push the agent to reason about module boundaries, vocabulary, and design quality.

That is a stronger point than the star count. The skills are interesting because they encode boring software fundamentals at the exact places agents tend to skip them.

Why This Beats A Giant Framework

The README explicitly calls out full-process approaches like GSD, BMAD, and Spec-Kit. The critique is not that frameworks are useless. It is that owning the whole process can take away control and make process bugs harder to debug.

Small skills have a different failure mode. If tdd is too strict for one repo, you can edit it. If triage assumes the wrong labels, you can configure it. If grill-with-docs produces too much ceremony, you can run grill-me instead.

That is exactly why skills are becoming a better distribution unit than giant prompts. They are readable, scoped, and composable. A team can inspect one skill before installing it. A reviewer can ask whether a skill changed behavior. A maintainer can version it.

This is also why agent skills need package-manager governance. Once skills become installable dependencies, the questions become familiar: who owns them, what version is installed, what permissions do they imply, how do updates get reviewed, and how do we remove one that no longer helps?

What To Adopt

The most immediately useful pattern is setup before use.

/setup-matt-pocock-skills asks about issue tracker, triage labels, and where docs should be saved. That sounds small, but it is the difference between a generic workflow and a repo-aware workflow. Agents need local conventions before they can be useful teammates.

The second pattern is separating orchestration from reusable discipline. A user runs /grill-with-docs; the model can reuse domain modeling beneath it. A user asks for debugging; the model can invoke a diagnosis loop. This keeps the user-facing command list understandable without making every session carry every instruction.

The third pattern is making handoffs first-class. The handoff skill exists because long agent sessions end. If the next session cannot understand what happened, the previous session did not finish cleanly. That connects to long-running agents needing harnesses and agent swarms needing receipts.

The fourth pattern is guarding git separately from prose. git-guardrails-claude-code belongs in the same family as permissions, logs, and rollback for AI coding agents. Do not rely only on the agent remembering not to run dangerous commands. Put the guardrail where the command happens.

The Opposing View

There is a real risk that a popular skills repo becomes another thing developers install because it feels like everyone else did.

That is not engineering.

A skill should earn its place in the repo. It should make the next diff smaller, the next plan clearer, the next bug easier to reproduce, or the next handoff easier to review. If it adds ritual without improving output, delete it.

There is also a context risk. A repo with too many skills can become a junk drawer. The agent may load irrelevant procedures, confuse similar instructions, or follow a workflow that conflicts with local reality. This is the same failure mode we covered in agent config files are executable supply chain: instructions are not harmless just because they are markdown.

The healthiest way to use this repo is not to clone it forever. It is to read it, steal the patterns that fit your team, and write your own local versions.

The removed skills are a useful warning. The community saw star velocity around a repo that still contained experiments. That is normal for living software, but it means teams should not treat popularity as review. Installable agent behavior needs the same skepticism as any dependency.

The Take

mattpocock/skills is worth studying because it treats agent workflows like engineering artifacts.

The skills are small. The failure modes are concrete. The setup step makes local configuration explicit. The split between user-invoked and model-invoked skills gives teams a way to orchestrate without building a giant framework.

That is the better path beyond vibe coding: not more prompts, not more magic, but small reusable practices that keep agents aligned, concise, tested, and design-aware.

Install the repo if it fits. More importantly, copy the discipline.

FAQ

What is mattpocock/skills?

It is Matt Pocock's public collection of agent skills from his .claude directory, focused on real engineering workflows such as planning, debugging, TDD, domain modeling, handoff, and git guardrails.

Does it only work with Claude Code?

The repo is built around Claude-style skills and slash-command workflows, but the README says the skills are designed to work with any model. The practical fit is strongest in tools that support local skills or equivalent reusable instructions.

What is the difference between user-invoked and model-invoked skills?

User-invoked skills are commands the developer explicitly runs. Model-invoked skills can be reached by the agent when a task fits. This lets a skill orchestrate reusable discipline without exposing every subroutine as a command.

Should teams install every skill?

No. Treat the repo as a menu. Start with one or two skills that target a real workflow problem, measure whether they help, then adapt or remove them.

What is the main governance risk?

The risk is treating skills as harmless markdown. Skills shape agent behavior, so teams should review them, track versions, define owners, and remove stale ones.

What is the strongest pattern to copy?

Copy the setup pattern: ask for local issue-tracker, label, documentation, and workflow conventions before expecting the agent to behave like it understands the repo.

Sources

• mattpocock/skills GitHub repository
• mattpocock/skills README
• mattpocock/skills changelog
• skills.sh listing for mattpocock/skills
• Agent Skills standard
• Claude Code skills docs
• Claude Code plugins docs
• Claude Code hooks docs