Matt Pocock's AI Skills Repo: What Works and What

There's something a little absurd about a collection of markdown files accumulating over 200,000 GitHub stars. No compiled code. No runtime. Just text files that tell AI agents how to behave—and apparently, that's exactly what the developer community needed badly enough to star it in extraordinary numbers.

Matt Pocock's skills repo is the artifact in question, and in a recent video, Theo (of t3.gg) spent 38 minutes doing what most people who starred it probably haven't done: actually reading the files, testing the skills against real projects, and thinking critically about what's worth keeping.

That exercise is worth covering. But I'd rather not spend 1,200 words just narrating Theo's video. The repo is public. The markdown is readable. And when you look at what's actually there—and who's writing it—some more interesting questions surface.

What a "skill" actually is

If you haven't been deep in the agentic coding world lately, the terminology can feel slippery. A skill, in this context, is a markdown file that gets loaded into an AI agent's context window when it's relevant. The agent sees a list of skill names and short descriptions, decides which ones apply to the current task, and reads the full content of those files into context.

That's it. No special runtime. No plugin system in the traditional sense. Just text, loaded conditionally.

The architectural simplicity is either elegant or alarming depending on your priors. What it means practically: the quality of a skill is entirely a function of the quality of the writing. There's no code to debug. If an agent keeps producing em-dashes (Theo's particular complaint about Pocock's own skills, which apparently contain nine em-dashes per page), the fix is just... editing the markdown. The skills are editable, forkable, composable. They're documentation that also functions as behavior specification.

What's interesting when you actually read the Pocock skills is how much they function as engineering judgment compressed into prose. The "grill with docs" skill doesn't just say "ask questions"—it prescribes a specific decision-tree methodology, working from settled prerequisites outward to unsettled ones, and instructs the agent to build ADRs and a glossary as it goes. The "diagnosing bugs" skill is model-invoked rather than user-invoked, meaning it fires automatically when relevant rather than requiring an explicit command. That distinction—between plugins you summon and behaviors that activate themselves—is actually a meaningful architectural choice, and Pocock is deliberate about it.

This is the skill mechanics question that most discussions skip: not "which skills are cool" but "how does the invocation model shape what you can build with them?"

The Potato problem (or opportunity)

Here's where it gets interesting from a community-dynamics standpoint.

Theo rates Pocock's collection as good. He rates another collection—Pstack, built by Lauren, who goes by Potato online—as arguably better, at least for his workflow. Pstack's "unslop" skill, which strips AI-generated text of its characteristic puffery ("pivotal moment," "testament to the evolving landscape," "highlighting, ensuring, reflecting, showcasing"), produced results that Theo describes as transformative enough to change how much he wants to read agent output at all.

I looked at the unslop skill itself. The writing philosophy embedded in it is genuinely good: "React to facts instead of neutrally listing pros and cons. Vary rhythm. Short sentences then longer ones that take their time. Acknowledge complexity. 'Impressive but also kind of unsettling' beats 'impressive.'" That last one is better prose advice than you'd get in most style guides. The skill is building an aesthetic into the agent's behavior, not just a ruleset.

But here's the thing I keep turning over: Lauren (Potato) is, per Theo's characterization in the video, a React core team contributor who now works at Cursor.

That career trajectory is worth sitting with. React core contribution is community-governed, volunteer-weighted work—the kind of labor that OSS sustainability advocates have spent years trying to make visible. Cursor is a VC-backed company that has raised hundreds of millions of dollars to build AI coding tools on top of the same foundation models everyone else is using. The move from one to the other isn't unusual in tech. But the fact that the most-praised open-source agent skills collection outside of Pocock's comes from someone now employed at a major tooling company is worth naming explicitly.

Is Pstack open source in the traditional sense? Formally, yes—it's a public repo with an open license. But the author's institutional context has shifted. When the people with the sharpest intuitions about how to write behavior specifications for AI agents get absorbed into the companies selling AI development tools, what happens to the commons? Does Cursor benefit from Potato's public work in ways that aren't fully legible? Is that fine? The answer isn't obvious, but the question is live, and it's exactly the kind of community-governance signal that gets lost when we focus on star counts.

Theo notes in the video that Pstack's skills are sometimes "a little too Cursor-specific"—some skills assume Cursor's architecture in ways that don't translate cleanly to other environments. He says he'd love to see someone fork it into a generic version. That's a reasonable wish. It's also a mild example of the platform capture dynamic that's reshaping what "open source" means in the agentic tooling space, where the distinction between "tool" and "behavior spec for tool" is genuinely blurry.

The skill you should actually have

Back to the object level for a moment, because it's worth being direct: the unslop skill works, and the AI coding assistant community has undersold how much the readability of agent output affects willingness to engage with it.

Theo's live comparison—same model, same prompt, with and without unslop—is striking enough that you should watch the relevant segment if you haven't. The unslopped output drops the ambient haze of AI-generated prose and delivers information as information. The slopped output, which he reads back aloud, is almost painful—the kind of text you skim past on your way to finding the actual answer, except the actual answer is buried in it.

This matters more than it sounds. If agent output is hard to read, developers start skimming. If they skim, they miss things. If they miss things, they get bugs. The readability of AI output is a correctness issue dressed up as an aesthetic one.

Pocock's "wizard" skill addresses a different problem: situations where an agent can't complete a step because it lacks access to some dashboard or needs a credential it can't hold. Wizard turns the agent into a step-by-step guide that walks the human through the parts only they can do, then hands back control. The framing Theo uses is right—it's a workflow design choice, not just a prompt trick. The agent knows its own limitations and structures its guidance accordingly. That's the kind of thing that sounds minor and saves you forty-five minutes.

The curation problem scales badly

The honest tension in this space is that skill design is still almost entirely artisanal. Pocock's skills are good because Pocock is a careful technical writer who has iterated them over time. Pstack's skills are good because Potato understands both compiler internals and prose. These aren't properties you can audit automatically. You have to read the files.

Theo's advice—don't blindly install skills, read the markdown before you copy it—is correct and also somewhat impractical at scale. The moment these collections get large enough, or numerous enough, the cognitive overhead of careful evaluation exceeds what most working developers will spend. We're already seeing a skill-repo proliferation pattern: Theo explicitly notes that "the vast majority of these skill repos are absolute slop and should be ignored."

That's not a solvable problem through better tooling alone. Theo is building a skill manager into T3 code precisely because the coordination overhead is becoming real. But a UI for managing skill files doesn't solve the evaluation problem—it just makes it easier to install skills you still haven't read.

What the community actually needs is some version of the editorial layer that exists for package registries: maintainability signals, community review, deprecation paths. The skills format is becoming infrastructure, which is a thing I've watched happen to enough ecosystems to know that the governance conversation needs to start before the infrastructure is load-bearing, not after. The skills-as-infrastructure framing isn't hyperbole—it's a warning.

Pocock and Potato are writing good behavior specs. Someone needs to start thinking about what happens when the behavior specs are what your agents run on, and the people who wrote them have moved on, changed employers, or decided the maintenance burden isn't worth it anymore. We've been here before with open source. The markdown is new. The story isn't.

Dev Kapoor covers open source software and developer communities for Buzzrag.