Matt Pocock breaks down the skills repo every AI coder is using
Andrew Warner sits down with Matt Pocock to unpack the Claude Code skill library that passed 200,000 GitHub stars, and the small habits of alignment, pruning, and teaching baked into it.
Posted
4 days ago
Duration
Format
Interview
educational
Views
12.6K
383 likes
57 · 43
Big Idea
The argument in one line.
The highest-leverage move in AI coding isn't a smarter model or a longer prompt, it's a short structured conversation that aligns you and the agent on scope and priorities before any code gets written.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You use Claude Code, Codex, or another coding agent regularly and want a repeatable process instead of ad hoc prompting.
You've watched an agent jump straight to a full implementation before you'd actually agreed on what you were building.
You maintain your own skills or prompt library and suspect a chunk of it is dead weight nobody reads.
You're trying to scope work bigger than one context window across multiple sessions or agents.
SKIP IF…
You're brand new to AI coding tools and haven't yet felt the pain this workflow is solving.
You're looking for model or architecture internals, this is about workflow discipline, not how the models work.
TL;DR
The full version, fast.
Matt Pocock's Claude Code skills repo passed 200,000 GitHub stars by encoding a handful of small habits rather than clever prompting. The flagship skill, Grill Me, interviews you in rounds before an agent commits to a plan, aligning on scope and priorities it can't otherwise infer. Bigger work flows through a pipeline: grill, spec, tickets, implement, review, with a deterministic orchestrator called Sandcastle looping through tickets unattended. A separate skill hunts for 'no-ops,' instructions that change nothing if deleted, and prunes skills back down. The lesson: align before you build, break big work into context-sized pieces, and periodically cut the dead weight out of your own instructions.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Andrew watches Matt run a plain security-audit prompt, then prepend 'grill me' to see how a short alignment interview changes the setup before any review happens.
02:42 – 04:30
02 · Low-fidelity planning
Matt connects the moment to Ryan Singer's Shape Up: start at the lowest fidelity that still moves you forward instead of jumping straight to a finished implementation.
04:30 – 05:06
03 · Pre-alignment
Andrew admits a real miss, a tool that needed historical view-count baselines he hadn't thought to build, as the kind of gap five minutes of alignment would have caught.
05:06 – 05:42
04 · Security review, two ways
They compare the ungrilled security audit output against what's coming from the grilled version, side by side.
05:42 – 07:03
05 · Grill Me questions
The skill asks who the adversary is, what asset is at risk, what's in scope, and what the deliverable is, before generating any findings.
07:03 – 08:06
06 · Why a custom skill
Matt explains that any process you find yourself repeating is a candidate for a skill, and a small one is easier to audit and hand to a team than a clever one.
08:06 – 09:27
07 · Agent alignment
The gap between what you value and what the agent can infer never closes on its own, making your priorities explicit is the only fix.
09:27 – 12:45
08 · Inside the Grill Me skill
Matt opens the actual skill file, about 22 lines, and shows how the user-facing Grill Me skill sits on top of a deeper Grilling skill that does the real work.
12:45 – 15:09
09 · The skill workflow
The full pipeline: grill (align), spec (describe the destination), tickets (slice it up), implement, review, sourced from the skills repo documentation site.
15:09 – 16:48
10 · Shared vocabulary
Grill With Docs adds a glossary step so builder and agent agree on names for things, which makes later instructions shorter and less ambiguous.
16:48 – 17:24
11 · Implement and review
For work that fits one context window, the fast path is simply implement, commit, then run an automated review.
17:24 – 18:18
12 · Specs and tickets
A spec describes the whole destination once; tickets slice it into pieces that each fit inside a single context window.
18:18 – 19:30
13 · Multi-agent development
Tickets can be handed to different agents or different tabs running in parallel instead of one agent working through them in sequence.
19:30 – 21:54
14 · Sandcastle
Matt describes his own orchestrator, a deterministic loop that implements a ticket, clears context, and moves to the next, able to run a 30-ticket spec overnight unattended.
21:54 – 22:30
15 · Writing for agents
A skill built specifically to clean up the garbage that accumulates inside other agent-written skills.
22:30 – 24:00
16 · No-ops
Matt defines a no-op, an instruction that changes nothing if you delete it, and says you can usually cut half a viral skill file without losing anything.
24:00 – 25:21
17 · Skill pruning
Live in the editor: keep each idea to one place, and cut any line the model would already obey by default.
25:21 – 25:48
18 · Automatic skill editing
The pruning skill can be set to trigger automatically whenever you create or edit an agent instruction file.
25:48 – 27:36
19 · Teach
Matt's hand-written teaching skill creates a stateful workspace that remembers what you know and builds lessons around you, drawing on his ten years of teaching experience.
27:36 – 29:45
20 · Primary sources
The teach skill interviews you on first run, then pulls in primary-source PDFs and materials to teach from, pointing you back to the sources rather than asking you to trust it blindly.
Atomic Insights
Lines worth screenshotting.
Matt Pocock's skills repo has passed 200,000 GitHub stars by encoding a handful of alignment and review habits, not clever prompt tricks.
The Grill Me skill that does most of the heavy lifting is only about 22 lines long.
Popular, widely-shared skill files can usually have roughly half their content deleted with zero change to the agent's output, that's a no-op.
A no-op instruction, like telling an agent to 'be thorough,' changes nothing about its behavior and just burns tokens and attention.
The idea that people default to operating at higher fidelity than they need, from Ryan Singer's book Shape Up, applies directly to AI agents, which default to producing a full finished feature before any alignment happens.
A spec plus tickets lets a single feature span multiple context windows and even multiple agents working the same plan in parallel.
An orchestration script that loops through tickets and clears context between each one can run a 30-ticket spec unattended overnight.
Skills can be split so a user-invoked skill like Grill Me sits on top of a model-invoked skill like Grilling that does the actual work underneath it.
A shared vocabulary between builder and agent turns a long, ambiguous instruction into a short, specific one the agent can act on directly.
A dedicated 'writing for agents' skill exists specifically to strip the garbage that accumulates in agent-written skill files over time.
A teaching skill becomes materially more useful once it persists state across sessions instead of restarting from zero every time you open it.
A well-built teaching skill pulls from primary sources like academic PDFs rather than answering purely from the model's own memory.
The biggest communication gap in AI coding isn't a model limitation, it's that the agent has no way to infer your personal hierarchy of priorities unless you state them.
One creator went from losing his job to having the most popular skill of the week on GitHub just by publishing skills he'd already written for himself.
Takeaway
Align with the agent before you let it build anything
WHAT TO LEARN
The highest-leverage move in AI-assisted work isn't a better prompt or a bigger context window, it's a short structured conversation that gets you and the agent aligned on scope, priorities, and vocabulary before any code gets written.
01Grill Me
Before asking an agent to review or build something, spend a few minutes explicitly agreeing on what you're trying to get out of it, most people skip this and pay for it later.
A 'grilling' style skill front-loads that alignment by having the agent interview you about goals, scope, and priorities before it commits to a plan.
02Low-fidelity planning
Start planning in the lowest fidelity that still moves you forward, plain text before diagrams, diagrams before prototypes, rather than jumping straight to a finished implementation.
Agents default to high-fidelity output, a whole finished feature, because that's the easy path, but it makes review expensive when something's off.
03Pre-alignment
Catching a requirement you hadn't thought through is cheap during a five-minute planning conversation and expensive a month after you've shipped.
The cost of skipping alignment isn't the AI's token spend, it's the rework when you discover a gap in your own thinking after the fact.
04Security review, two ways
A generic 'do a security review' prompt gets you generic findings, some accurate, some not worth acting on, with no sense of what actually matters to you.
Comparing an unguided review against a guided one side by side is a fast way to see the value of alignment before assuming it's just extra overhead.
05Grill Me questions
A good pre-review interview asks who the adversary is, what asset is at risk, what's in scope, and what the deliverable looks like, before any findings get generated.
Answering these questions by referencing the question number is faster than restating each question back in full.
06Why a custom skill
If you find yourself explaining the same process to an agent more than once, that's the signal to turn it into a reusable skill instead of re-typing it.
A skill doesn't need special techniques to be valuable, a plainly-written, easily audited one you can hand to a whole team beats a clever one only you understand.
07Agent alignment
You carry an internal hierarchy of priorities the agent has no way to infer on its own, that gap in communication is permanent, not something a smarter model fixes.
Making your priorities explicit up front is the most reliable way to close that gap, because the agent literally cannot guess what you value most.
08Inside the Grill Me skill
Skills can be split so the user invokes one, like Grill Me, while the actual heavy-lifting logic lives in a separate, model-invoked skill underneath it.
The core Grill Me skill is about 22 lines, its power comes from specific instructions like mapping a design tree in rounds and delegating fact-finding to a sub-agent instead of blocking the user.
09The skill workflow
A repeatable software lifecycle for agent work looks like: grill (align), spec (describe the destination), tickets (slice it into buildable pieces), implement, review.
This turns a single big ask into a workflow that spans multiple sessions and can even be handed to multiple agents working in parallel.
10Shared vocabulary
Agreeing on consistent names for your concepts, folders, and functions before you build lets you give an agent a short, plain instruction instead of a long, ambiguous one.
This shared vocabulary is a direct product of the alignment conversation, it's what a glossary step captures for you to reuse in every future prompt.
11Implement and review
For work that fits in a single context window, the fast path is simply implement, commit, then run an automated review on the result.
Save the heavier spec and ticket process for anything too large to comfortably fit in one session, using it for everything is unnecessary overhead.
12Specs and tickets
A spec is a durable document describing the whole destination, write it once, then pass it into every session that works on any piece of it.
Tickets slice that spec into pieces that each fit inside one context window, so a large feature gets built incrementally instead of in one unreviewable pass.
13Multi-agent development
Once work is broken into tickets, those tickets can be assigned to different agents or different tabs running in parallel, not just worked through sequentially by one agent.
The spec functions as the shared source of truth that keeps parallel agents building compatible pieces instead of diverging.
14Sandcastle
A queue of tickets is fundamentally a loop, and that loop doesn't need to be an agent decision, it can be a deterministic script that implements a ticket, clears context, and moves to the next.
This kind of orchestration layer lets a 30-ticket spec run unattended overnight, with a finished PR waiting for human review in the morning.
15Writing for agents
A skill written specifically about writing skills exists because agent-written instructions accumulate a specific kind of garbage over time that quietly degrades results.
Reviewing your own skill files periodically for that garbage is worth doing even though most people find their skills too long and confusing to audit by hand.
16No-ops
A no-op instruction is one that changes nothing about the agent's actual output if you delete it, lines like 'be thorough' fall into this category almost every time.
Popular, widely-shared skills are not exempt from this problem, you can usually delete roughly half of a viral skill file and the output won't change.
17Skill pruning
Keep each idea in a skill to one place, duplicating the same instruction in multiple spots costs both maintenance effort and tokens with no upside.
Check every remaining line by asking whether the model would already do that thing by default without being told, if yes, the line is dead weight.
18Automatic skill editing
You can read the before and after diff of an automated pruning pass rather than blindly trusting it, which keeps you in control of an opinionated cleanup process.
Setting a pruning skill to trigger automatically whenever you create or edit an agent instruction file turns a one-time cleanup into a standing habit.
19Teach
A teaching skill becomes genuinely useful once it persists state across sessions, remembering what you already know instead of restarting the conversation from zero each time.
Handwriting a skill yourself, instead of having an agent draft it, is worth doing when the process is something you deeply understand.
20Primary sources
A teaching skill that pulls in primary source material rather than answering from the model's own memory produces noticeably deeper, more reliable lessons on academic topics.
Because it's still an LLM, a well-designed teaching skill should point you back to the primary sources it used rather than asking you to just trust its summary.
Glossary
Terms worth knowing.
Grill Me
A skill that interviews the user with rounds of pointed questions to align on goals, scope, and risk before an agent starts real work.
No-op
An instruction inside a skill or prompt that changes nothing about the agent's actual output if removed, a sign the line is dead weight.
Shape Up / fidelity
The idea, from Ryan Singer's book Shape Up, that early planning should happen at the lowest fidelity that still moves the work forward, such as plain text before diagrams or prototypes.
Sandcastle
A deterministic orchestration script that loops through a list of tickets, telling an agent to implement one, clearing its context, and moving to the next, without a human babysitting each step.
Architectural decision record (ADR)
A short document explaining a non-obvious design decision in a codebase, so future sessions, human or agent, understand why the code is built the way it is.
Design tree
A way of mapping a plan as decisions that branch into the decisions depending on them, used to decide which questions to ask next during a grilling session.
“Anyone could have written this skill. This is not a special sauce. Makes it very easy to audit, very easy to bring into your organization.”
reframes 'simple' as a feature, not a limitation→ newsletter pull-quote↗ Tweet quote
19:59
“You think of a set of tickets, that's just a loop. Right? You just have just loop over that, and that can be deterministic.”
collapses agent orchestration into one plain-English line→ IG reel cold open↗ Tweet quote
22:58
“You can probably go through there and delete about half of it, and not much about the output will change.”
specific, provocative claim about viral skills being half bloat→ TikTok hook↗ Tweet quote
28:52
“I interviewed this guy, Mads, who had lost his job, who went to get a job himself, and he used Claude to do it.”
human stakes payoff at the very end of the episode→ newsletter pull-quote↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphorstory
This one skill pack will make your coding agent so much smarter and get all your output to be much better. That's why it's one of the all time most popular projects on GitHub with over 200,000 stars.
Serious developers swear by it, but so do new builders like me. You're about to meet the creator, Matt Pocock, and he's gonna teach us how to get the most out of it. Let's get into it.
Presented by Zapier, the AI automation company. Alright, Matt.
What are we looking at here? What is this?
So I have just done something interesting with this application, which I have this is the application that I use in my work repo. And before, it was an entirely local application, but I have bumped it up so that part of it is sitting in the cloud.
And what I've not done is I've not done a security review on it. So what I'm keen to do is I'm just gonna prompt ClawCode. This is Opus five medium effort, uh, Clawd Max subscription.
And I'm just gonna say, I just deployed a large application, blah blah blah blah blah. And it's going to do its security review. Right?
Now this is okay. But what I really prefer doing, and what I think you're gonna get better results from, is aligning on what you actually want to get from the AI before you commit to something.
If you think about the process here, it's kind of like we are doing something with the agent, usually implementing some code or conducting a review or something like that. And then we're gonna review it at the end or review it at some point.
And so there's a kind of plan, implement, review setup. Now most people don't spend enough time on the pre alignment phase.
Right? On the aligning before you do the thing. And so what I much prefer to do is if I open up a new tab here, I'll run Claude again.
And this time, I'm just gonna prepend it with grill me here, which is kind of my most popular skill. It's the skill that does this alignment for you. What it's doing is it's gonna invoke the grilling skill, and then we're going to actually chat about the things that it's going to do, the things that it's gonna focus on and find before it goes and does the review.
So I'm keen to kind of sort of see the two different approaches here. I mean, these are nondeterministic. Right?
Like, so who knows what's gonna happen, but that's the main idea.
Yeah. I have a hard time using a skill like this before I get started because I almost need to see not almost.
I need to see a version of the finished product to touch it, to feel it, to then have some opinions about where I want it to go. When it's just an idea, it's too hard for me to think it through. And so both the eagerness of just getting started keeps me from going through a set of questions and planning with Claude, and the need to feel it keeps me from doing it.
What do you say about that? So what you're describing there is the fidelity
of the thing that you're talking about. Right? And when you're working on anything, this is like this is an old idea.
This is from Shape Up. This is Ryan Singer's great book about designing, planning stuff. And what he talks about in Shape Up is that people often feel like they're operating on or they want to operate at a higher fidelity than they need to.
So actually, when you're first starting out, it's often really good to operate at a really low fidelity. In other words, just text. And then maybe from text, can work up to, let's say, diagrams or breadboarding or various techniques.
And from there, maybe then you can go to prototypes. But what everyone seems to be doing or the default mode for agents is to just go to a massively high fidelity immediately, and just say, okay.
I'm gonna produce the entire feature for you, and then we'll review the whole thing. But then, because you've produced the whole thing, review becomes really expensive. Right?
Because you're having to review the whole thing. Maybe there are bugs you didn't expect. Maybe it's just not done the thing that you wanted to do before.
Whereas if you were to spend five minutes just aligning low fidelity first, and then you actually understand what you're building together, then you can ship something really, really good. You know,
it's still the cost isn't really an issue for me because, you know, you have the subscription. It I have the $200 a month plan, not that big a deal. Where it does end up biting me is there is something that I hadn't thought of that is a problem.
Like, I have a tool that will analyze YouTube videos related to AI and then tell me who's got more more than their average views. And then I realized a month later, oh, I didn't think through that it has to daily keep track of what their regular view counts is to know when something is an outlier.
And if I would have spent some time thinking about it, I would have caught that. But, boy, I just rushed to build so fast.
Exactly. And that means that something very simple, something very quick, a little quick check at the start, would have been able to catch that. Right?
And I don't always think that you need to operate at low fidelity. Sometimes you need a prototype before you're building the thing. And what I'm often talking about here is building really complex apps, apps that are supposed to go into production.
These are the apps that I spent my career building. And
before you build anything real, you have to align. You have to figure out where you're going. Okay.
Uh, let me know when the questions come up. I wanna see what grill.me looks like with this new form.
Totally. So let's see. So on the first one here, it basically just went and this is the one where we ran it without grill.me.
And so it just produced a security audit. Right? So it's done a very general security audit, and it's go, okay.
Vercel credentials in the public history. That's not good. I actually looked at this, and it is actually fine.
So we're okay. Drizzle are on the deployed path, low practical risk, blah blah blah blah blah. Now this is very general.
It's okay. It's gonna probably give me some decent advice. But what if we actually talked about it first, just did a very small amount of conversation?
So this is what Grillme looks like. So you essentially just have a bunch of questions where this little red check mark here, this is the question, who is the adversary, and then you have a little recommendation from Grillme on what it's thinks you should choose.
So which of these do you actually want to defend against? Anonymous person on the internet who finds the Purcell URL, etcetera. What is the asset?
Blah blah blah blah blah. What is in scope? What is the deliverable?
So it's just a little tiny set of questions, which I will then read through and dictate out my answer to. And so it's asking these questions in sensible batches.
It's going to ask multiple rounds of these questions. Mhmm. So when I submit an answer here, it's then gonna find the next round of questions and ask them to me too.
So Here's That's before you go into it, here's my challenge for how to respond to something like this.
I don't I don't know. Do I say, well, for your first question and then repeat the question and then give the answer, or do I copy and paste the whole thing in and then write underneath it?
Yeah. What I would say is for q one, yeah, I accept your recommendation.
For q two, the worst thing that can get occur is probably data loss and probably, uh, database abuse.
I want to make sure I'm not getting DDoSed. For q three, I think apps remote is the only thing that's in scope. You get the idea.
So that's why they're labeled with the numbers is so you can just reply to the number very quickly.
Okay. What's the difference while you send that out, and we're gonna get the next batch of questions? Do you wanna, uh, no.
I guess you didn't wanna answer any more other questions. What's the difference between this and just saying, Claude, ask me some questions before we get started. Force me to think about this well.
I mean, it's a really small skill. That's the thing about grill me is it's very, very small. It really is just a case of, uh, you know, your aunt, like, quiz me relentlessly about these things, use this certain format, ask them in rounds, and there's really not much to it.
So anyone could have written this skill. This is not a special source. Makes it very easy to audit, very easy to bring into your organization.
It's a teeny teeny little thing. And so, yeah, of course, you can just do your own thing. But I noticed that whenever I want to encode a process and do it again and again and again, I think that a skill is a really nice place for that.
And Grill Me, you know, you just modify it yourself. You, uh, figure out exactly what you wanna do with it, and then you're good to go.
Okay.
I do wanna see what the skill looks like in a moment, but keep going with this. I'm curious what the what the result will be.
So let's see. So it's asked a bunch more questions here. Um, it's asking about rate limits.
Right? So the whole first answer was just like, okay. Here is your security audit.
But now it's actually thinking a bit outside the box. It's extending the scope a little bit. I don't have any rate limiting today.
So I probably need to add maybe the Vercel firewall rules. Health is unauthenticated, so I probably need to figure that out as well. Last use at right, so some various stuff here.
So this is really going into depth. It's sort of become like, begun the security audit already, but now I am involved in it, and so it's kind of trying to align to where I need to go. I think what most people underestimate when they start new work is that they have an internal kind of hierarchy of values.
Right? A set of things that they want to be done, and a a set of priorities that sort of they hold that the agent just doesn't understand.
In other words, there's a communication gap between you and the agent. And that's always gonna be there. Right?
Because we as the user, like, AI can't anticipate that hierarchy of values.
So it has to figure them out, and this I found is the best way.
Would you, um, would you open up the skill and just show me how it works? Then what this is part of a collection of skills, and it has so many other things like how you you personally learn, how you get your agent to communicate with you more clearly. Um, I think there's also how you write, which is in here.
It's basically yours your set of personal skills. I'd like to see what's in it. This is so where is the skill itself?
I see this is the exact file that I'm that I'm looking at on GitHub. It is just this, a relentless interview to sharpen a plan or design?
Yeah. So there's a there's a little more to it than this. This is the grill me skill.
And one important idea about skills is that you can have skills that the model can invoke, or that the user can invoke. And this one, this skill is actually invisible to the model by default.
But the skill grilling is really where the meat is. So let me pull out grilling just here. And grilling is a little bit longer.
It just says, interview the user relentlessly until you reach a shared understanding. Map this as a design tree. Every decision branches into the decisions that hang off it.
You work the tree in rounds, and the frontier is every decision whose prerequisites are already settled. These, by the way, these bolded terms here are what I like to call leading words. They're words inside the skill that are designed to essentially trigger the agent's reasoning traces, and it's encouraging the agent to think in these terms, leading the agent to do its thing, sort of like like for it.
And so, essentially, that's that's the skill. It's just 22 lines long. It's grown a little bit since it it was a fair bit smaller, actually.
And it's just little things like finding fact is your job, never the user's. When a frontier question needs a fact from the environment, dispatch a sub agent to find it. Don't block the user.
So this is this is all the skill is, really. And it's just one utility just for creating this grueling style interview. And by the way, as someone who personally creates and lives off of skills all day long, anything that I do more than once, uh, actually, more than multiple times, I have a skill created for it.
And, um, I never did one of the things that you just showed, which is have a skill that basically just invokes another skill. Why would I do that? So it's a kind of constraint that I have, which is that I have two grilling skills.
One of which is Grill Me, and one of which is in my engineering directory, and it's Grill With Docs,
which essentially just has run a grilling session using the domain modeling skill. So it's a little layer on top of Grill Me. So it's just a it's a little bit of code sharing, basically.
There's nothing actually in the skill spec that describes how you should share code between skills, and so this is my kinda hacky attempt at it. Okay. I got it.
Um, I have my own little hacky attempt. I created an which then pulls the different skills that it needs in. Okay.
I get it. You basically you're saying, look. I have one format for grilling, but there are two different ways to grill.
One is ask questions, and the other is use these documents to get the information you need. Okay. So back to what we were doing before.
Um, do we have a response yet from the version that it's still asking more questions?
Yeah. Yeah. Yeah.
I haven't answered these questions yet, and I I could do. We could just sort of keep running through, But but I think we kinda know where it's going. We're gonna end up with a document kind of like the first one, but just way more detailed, way more tailored to what we actually want.
Okay. Alright. So the discipline here is, first of all, to just have this on my system by giving the GitHub link over to Claude or Codex and saying, now I want you to to start using this.
And then the discipline is before I start a session to say, grill me about this thing I'm starting to launch. That's one thing. By the way, if you're listening to this and you're building software that you want to bake in something like HubSpot, Slack, Jira, Gmail, or over 9,000 other apps, if you use Zapier SDK, you can do it easily, and you can have the controls that you you need over it.
Go to zapier.com/sdk and check it out. Okay.
Um, why don't we look at some of the other skills and just talk to me about why they're there? The what's the wait what? That's a new one that I saw you publish.
So if we look documentation site for the skills. We should be there we go.
Four 214,000 GitHub stars. Ridiculous.
I wanna talk first just about this main flow, basically, because you talked about, like, the discipline. And this main flow, like, going from the grill with doc skill, to the to spec skill, to the to ticket skill, to the implement skill, to the code review skill Mhmm. That's essentially a software development life cycle there.
Right? And when we're talking about skills, you can encode these processes that last more than one session.
Very, very cool. And so the all of these, these are all of the skills in the repo. Wait.
Can you go back for a moment? Just repeat what you just said. I wanna understand.
I'm not a developer, but I build tools now all the time for myself and my team. There is a, what, a product life cycle that you said, and then you also said that they will start off on their own.
Tell me tell me both those things. The way these work is that a lot of skills repos and skill setups, they try to give the model they try to make the model really powerful, and they try to make the harness really powerful.
So for instance, superpowers, which is a very, very popular set of skills, They're designed to give the model superpowers, not necessarily the user superpowers.
Mhmm. And so mind, they take a little bit more learning, a little bit more understanding. But once you've learned essentially these five skills, you can build, uh, anything of any size.
Like, it it really is a very powerful setup. And you've got grill with docs, which is essentially grill me with a little bit of, um,
little bit of an extra layer on top. What's the extra layer? What are the docs that I would use instead of the questions?
Great question. So it's it does it's essentially
the same thing as grilling. You have a a grill me session where you're answering questions, but it does two things.
It's, first of all, creates a glossary of the thing you're building, which sounds incredibly dull. Why why would you do that? But when you realize that, okay, the glossary, if I name everything consistently throughout application, and I name all of the folders like that, I name all of the concepts that I have, and I I find the right language for what I'm building, the thing about agents is that they thrive off consistent language.
And so if you say, okay, change this, let's say, two sentences of long blah blah blah blah blah blah, the way that ghost lessons materialize into ghost sections into blah blah blah blah blah.
Very complicated. Whereas if you just say, make a modification to the materialization cascade.
Right? A term that you've agreed on with the agent, it knows exactly where to look because the functions are named properly, the folders are named properly, and everything is aligned. So actually aligning with the agent, creating those glossaries is so important.
I see. So grill with docs, the difference is the output is the docs
that that have the understanding that we've gotten from the grilling session, and then that helps make the rest of the process better. But I've also got a doc of how I work, of what I I got it.
Okay. So that's the first step. What's the next and and the rest of the process?
So the there's there's another thing in Grill with Docs two, which is it creates architectural decision records, which help explain the non obvious stuff about the code, which if you've done any coding, that you'll you'll know how important those are.
And so it's essentially just layering on good software concepts onto the Grill Me skill. Once you've had that conversation, you can then you've then got a decision you need to make.
You can either if you think that you've got enough juice left in your session, if you've got enough context window left to work with, then you can just implement it. Right? You just jump to the implement skill, which just does a very simple setup.
It's just implement the code, create a commit, and then review it. So do an automated review on it. Okay.
Or if it's like a massive feature that you're building, if you know, okay, there's no way I'm gonna squeeze this into the good bit of my context window, then you need to schedule that over multiple context windows. And for that, you need two things.
You need a spec, and that specification is gonna be essentially a huge document that describes what you're building. And that description of what you're building means that you can then review it afterwards.
And it also means you can pass that into every session that comes afterwards to say, this is what we're building. And then the to tickets is we are building this slice of the spec.
I see. So what that means is you describe your destination. Okay.
We're building this huge feature. And then ticket one fits in one context window.
You're gonna build that bit. Ticket two fits in another context window. Go back.
Build that bit. So that's the whole theory. And then you implement each ticket, and you review at the end.
Can I also use I've never I've never even thought to use the ticket skills, but now I understand it? Can I also then use it to break up the project so that multiple agents or multiple tabs in my Claude code can do? I can.
That's what I So start by grilling, then create a spec. Now we know exactly what the finished product looks like. Break it up into parts, assign them to different agents or different, like, basically tabs within the window.
I've got everything ready. Now now the implementation puts it all together because it's all the features have been built, and now we need to connect them all.
Got it. You got it. And the cool thing about it is is, like, the cool thing is that you can actually just schedule this with a process.
Right? Once you created the tickets, you can then create a workflow, which you don't even have to monitor, that just builds the thing. Right?
I've had specs that have, like, 30 tickets, and I have a setup in GitHub actions where it just basically churns through. Just says, okay.
Implement this thing, clear the context, Implement the next thing. Clear the context. And that can run overnight.
Right? I don't need to be there to monitor it. And I wake up in the morning.
I review it, and I see what's what's been done. So, yeah, that's the idea. Yeah.
And that creates a PR for you, does human review. You get the idea. I'm still a bit of an amateur on this.
I'm sitting at Claude Code, for example.
How do I tell it, schedule it, and parse this out, and then wait for the context window and clear it out? You need a layer on top of the harness, basically. You think there's, like, the model model itself,
and then the harness, and the model and harness together form the agent. You need a layer on top that's gonna say, right.
Do this. Tell the agent to do this, and then clear the agent's context window. Do this.
Clear the agent context window. And because, like, you think of a set of tickets, that's just a loop. Right?
You just have just loop over that, and that can be deterministic. It doesn't have to be an agent. And so I've built something for that called sandcastle, which is pretty good.
There's also things like the AI SDK, which allow you to build these things in TypeScript. But you can you can think of even, like, Claude workflows, for instance. The workflow set up in Claude where you essentially just schedule a bunch of sub agents using a script, that's exactly the same thing.
So you can think of that as kind of like an orchestrator over your agents.
Okay. I see Sandcastle. It's another one of it's on GitHub.
Another one of your projects, I can just go there and get it, and it's Orchestrator the I might use. Exactly. You get the idea.
Okay. I see that. How about if we take it away from now that I understand the way that you build and that you think about and lead the creation of something, why don't we go to more personal stuff?
Writing. What type of writing are you able to get the agent to do with your skill?
Well, so this is this is actually a skill that I've, um, recently taken out of the repo. So I don't I don't actually I didn't end up using it that much.
I can talk about a different skill, which is sort of similar.
Oh, actually, no. Um, no. Okay.
I'm thinking of the wrong thing, actually. If you ask your question again, I think we can hit that.
Basically, I'd, uh, oh, I see. You've got writing for agents in here, but the writing that is, like, the output writing you don't have in here anymore. Right?
No. Well, I I it might be like writing beats or something, but it's it's not very that's an in progress skill. I'm not sure it's it's quite ready for one time.
Alright. What's a what's a nondevelopment skill then that I could look at here and get an understanding of the way that you personally work? These are for engineers, basically, this this skill set.
And the stuff that isn't for engineers, it's also sort of for engineers.
But the I tell you what. I I have a skill that I would love to talk about, which is Okay.
A sort of new skill. I think what everyone is doing, what you're certainly doing a lot of is writing skills.
Prompts for agents. And this writing for agents skill is essentially everything that I've learned about writing skills in a skill to help you write skills.
Okay. Essentially, it allows you to take all of the crap and all of the crud out of agent writing.
Usually, you get an agent to write something, it's just gonna be full of a specific type of garbage. And that specific garbage is no ops.
So if I search in here, I'm pretty sure I've got these. There's a specific mistake I see all the time with people create skills, which is that they will write things inside the skill that do nothing to change the actual outputs of the skill or the behavior of the agent reading that skill.
And I call these no ops. This is sort of programming term. You can remove it, and nothing will change.
Okay. And if you look at skills that you've written, or look at popular skills even that go viral, you can probably go through there and delete about half of it, and not much about the output will change.
Matt, I definitely have that. I know it confuses my agent. And largely, the more I use the skill, the more of this junk gets built in, but I don't know what's junk and what's not.
And when I say to somebody, I'll have to go and read it, they laugh at me, and it's true. I can't go and read the whole skill. I'm just saying to it at the end of each run, what could we do to improve next time?
It gives me some suggestions. I say, okay. Implement these but not those.
It implements it, and then I just trust that it's there. And the very next time when something wacky comes out, I can't audit it because it's so much text. And I bet a lot of it is junk because frankly, even when it writes for me, it's junk.
So that's what this is about.
100%. That's exactly the thing that I'm trying to kill because what you need is you just need essentially a little pass over the top.
Where is it? Skill.md. And this does a whole bunch of stuff in here.
This is certainly one of my longer skills because it surfaces a lot of important ideas. The main one that it's got in here is pruning. Right?
Keep each meaning in the skill to a single source of truth. And if you have duplication, the same meaning in more than one place, that costs you maintenance and tokens. So you check every line for relevance.
Does it still bear on what the document does? And you hunt sentence by sentence, an instruction the model already obeys by default pays load to say nothing.
That's an that's an awkward sentence, actually. I don't like that one. This is why reading the skills is actually blooming important because
I I that's that's a nasty little sentence. I think Opus wrote that.
But what you get the idea is like things like be thorough. Right? Be thorough.
What does that mean? You know, people will often say, you know, it's almost like saying don't make mistakes or something. It's just it's that's a no op.
Right? That's not gonna do anything to change the agent's output.
And so this is definitely something that I think you should run on your own skills just to have a check and see if you can remove some stuff. So, like, once a month, take all the skills that I've written and say, run it against this and and see what you can remove. Do I just trust it to make these decisions, or do I need to see it?
I mean, you can you can read the diff. Right? Read the before and after and see what it's done and see if you agree with it.
It will often really cull skills down into smaller sections. It's pretty opinionated. You know?
It contains all of my opinions. And also, if you have this on your system, this is a model invoked skill. It says use when creating or editing skills or modifying agents dot m d or claw dot m d.
So this will get invoked by your agent when it's making those crucial edits, which is very, very happy.
So it's an automatic one that I can just set and then keep using. Alright. I think that makes sense.
Why don't we just close it out real quick with a conversation about, um, the the one that you use to teach you to teach yourself?
Yeah. Teach is great. I had a bit of a boring day, because I was traveling.
And this is one that I actually wrote by hand. I didn't get an agent to do anything to this.
I'm very passionate about teaching. Before I was a I was a before dev, I was actually a voice coach.
So I taught people how to speak and how to sing, and like, I did that for about six years. Thank Yeah.
So much one to one teaching. And so between that and between now teaching devs for about four years, I've got about ten years of teaching experience.
And I wanted to encode that into a skill just for fun and see what would happen. And this has been a blast because it's you essentially just create a new folder on your system, and then teach, you can run it in that folder and say, teach me something.
And the usual thing you get with agents is that, you know, it's it's good for that conversation.
Maybe it remembers, but it doesn't necessarily remember the next time you invoke it. Whereas teach, what it does is it creates a stateful workspace where it saves information about you.
It understands how you're developing. It keeps learning records. So it's just like teacher that you have sessions with.
And then it creates these lessons in HTML, which try to teach you skills or concepts depending on what you're doing. And it taught me how to so what is it taught me?
It's taught me how to get my son eating better foods, who's about 2.5, so that's a bit of a challenge.
And taught me how to solve a Rubik's cube. It's been teaching me how to do better, like, folk harmonies as well. Like, I've been using it for all sorts of stuff.
And it's absolute joy to use. It's great fun.
Where does it know what it's teaching you? Is it researching it on its own? I know that it keeps up with what you've done so it remembers for next time to keep you developing.
Yeah. Basically, on its first run, you say you interviews you about what you want to learn and what your mission is, what the reason is you're you're learning. And then it goes out and finds primary source resources to pull in and teach itself, I found it's really good actually for academic stuff.
Because a lot of, like, those resources are in PDFs, which are publicly available. And so it goes, pulls in those PDFs, scans the stuff, and really understands it very deeply. And so, yeah, it's working from primary source information.
But of course, it's an LLM. Right? And so you should never really trust an LLM.
And so it does push you to go and read those primary sources, as far as I know. There go. Each lesson should recommend a primary source for the user to read or watch.
Alright. This is fantastic. I think that this is it seemed to me like you were a little surprised by how popular this got.
You then inspired a few other people to start putting their skills on. I actually even noticed, uh, one or two people who you interviewed then started putting their skills on, and they were excited. I think the most exciting thing about seeing your skill online was seeing how you work and think about your own personal skills helped me think about mine.
And now that I've dug in a little deeper, I've I've picked up some more understanding. And I I think this is really exciting. I interviewed this guy, Mads, who had lost his job, who went to get a job himself, and he used Claude to do it.
And he wrote all these skills for himself. He said, you know what? I'm just gonna put them online.
And as a result of that, it became the most popular skill for the week. And he didn't even know it. He just said, you know what?
I'll put it on GitHub. And he saw our show and or someone saw our show and told him, and he was shocked. And I said, do you know how many people you're helping just by saying this is the stuff that's working for you?
You're passing to others. Matt, you've done the same thing. You're inspiring me to do more of it.
I'm now finally getting started, and I I I'd love to see more of what our audience is creating. They literally are now emailing me every day what they're you what they're creating. When I get permission, I will show it on our weekly show.
And I will say to you, Matt, you've been featured on our show several times because I go through every week the top 10 GitHub repos of the week. If you're watching us and you hadn't seen the show right, uh, yet, I've got one where you can see just like I learned from Matt about his, uh, skill and his repo. Every week, I learn about the top 10, and I've got one for you right here that you can learn along with me.
See you there.
The Hook
The bait, then the rug-pull.
Andrew Warner sits down with Matt Pocock, whose open-source Claude Code skill library has passed 200,000 GitHub stars, to find out what's actually inside it: a handful of small, prunable habits for aligning with an agent, breaking work into shippable pieces, and teaching yourself in the process.
Frameworks
Named ideas worth stealing.
00:00concept
Grill Me
A relentless-interview skill that maps a plan as a design tree and works it in rounds, asking every question whose prerequisites are already settled, until you and the agent share understanding.
Steal forany prompt before a code review, security audit, or feature build where the agent would otherwise guess your priorities
12:45model
The skill pipeline: grill, spec, tickets, implement, review
Grill / Grill With Docs
To Spec
To Tickets
Implement
Code Review
A full software lifecycle for agent work: align first, describe the destination as a spec, slice the spec into context-sized tickets, implement each one, then review.
Steal forany feature too large to build and review in a single session
22:30concept
No-ops
An instruction in a skill or prompt that changes nothing about the agent's output if deleted, the target of a periodic pruning pass over your own skills.
Steal forauditing any prompt library or CLAUDE.md that's grown past a page
19:30concept
Sandcastle
A deterministic orchestration loop that runs outside the agent: implement a ticket, clear context, implement the next, letting a large spec churn through overnight without supervision.
Steal forany multi-ticket spec you don't want to babysit ticket by ticket
25:48concept
Teach
A stateful teaching skill, hand-written rather than agent-generated, that interviews you about what you want to learn, pulls primary sources, and keeps learning records across sessions.
Steal forencoding your own domain expertise into something that teaches other people, or yourself, on a new topic
CTA Breakdown
How they asked for the click.
VERBAL ASK
13:05product
“if you're building software that you want to bake in something like HubSpot, Slack, Jira, Gmail, or over 9,000 other apps, if you use Zapier SDK, you can do it easily, and you can have the controls that you need over it. Go to zapier.com/sdk and check it out.”
stitched directly into Matt's answer about workflow discipline rather than a hard cut to a separate ad break, then handed straight back to the topic
Andrew Warner spends a day cramming on "agent loops," then brings Matthew Berman on screen-share to react to five other creators' examples before showing off — and fixing — his own.
Andrew Warner and Adam run down this week's most-starred GitHub repos — three AI design tools, a parallel-agent "tokenmaxxing" rig, a video-comprehension skill — and pull the geophysicist who built the #1 trending AI job-search framework on camera to explain how it got him hired.
Two hosts react to seven creators' first hands-on tests of OpenAI's GPT-5.6 Sol against Claude Fable 5 — and land on a manager/worker split, not a winner.
00:48
01:21
01:53
02:10
02:52
03:36
03:50
04:28
04:48
04:58
05:24
05:36
06:12
06:32
07:00
07:34
07:57
08:16
08:56
09:16
09:46
11:06
11:45
12:36
12:55
13:57
14:25
14:54
15:21
16:10
16:35
17:06
17:18
17:51
18:08
18:44
19:18
19:44
20:24
21:10
21:39
22:12
22:24
22:41
23:26
23:48
24:10
24:50
25:10
25:34
25:43
25:58
26:20
27:03
27:25
27:46
28:08
28:20
29:12
29:34
35:11
37:04
32:13
07:04
39:53
33:27