Big Idea

The argument in one line.

A five-skill pipeline compresses an open-ended coding idea into a durable spec once, then executes it ticket by ticket across however many context-window sessions the work needs, with a separate sub-agent reviewing every ticket against both the spec and the codebase's own standards before it commits.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…

You already use Claude Code or a similar coding agent daily and want a repeatable process for turning a vague idea into a merged change.
You've hit context-window degradation on multi-file work and want a concrete way to split a big change into agent-sized tickets without losing the plan.
You maintain a tool or CLI and want a system for progressively removing internal-only complexity or scoping any multi-step refactor.

SKIP IF…

You're looking for a deep technical reference on any single skill's internals — this is a flow overview, not documentation.
You don't use an issue tracker or local markdown to record specs — the whole system assumes a durable place to write and revisit tickets.

TL;DR

The full version, fast.

The video installs the mattpocock/skills repo onto a real CLI codebase, then demonstrates the main flow it's built around: grill-with-docs interviews a vague idea until agent and human share a plan, to-spec compresses that discussion into a durable document, to-tickets slices the spec into pieces sized to one context window each, implement executes a ticket, and code-review runs in a fresh sub-agent that checks the work against both the spec and the repo's standards before committing. The dividing line for skipping straight to implement versus writing a spec is a self-imposed budget of roughly 140k tokens — the point past which the author says agent attention starts to degrade, regardless of the model's stated context limit.

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.

Create a free account →

Chapters

Where the time goes.

00:00 – 00:36

01 · Cold open

162k stars, 7.5M downloads, and no tutorial yet — Matt states the video's purpose: walk through the main flow on a real repo, not the advanced/new stuff.

00:36 – 02:30

02 · Install: npx skills@latest add mattpocock/skills

Runs the installer against an existing brownfield repo (AI Hero CLI). Vercel's skills.sh installer clones the repo, finds 38 skills split into 'blessed' Matt Pocock skills and experimental others, and lets him select all with space+return.

02:30 – 04:45

03 · Agent target, install scope, symlink method

Chooses Claude Code as the target agent, global (home-directory) install scope since he's a solo developer, and symlink over copy so every agent references one source of truth. Install completes; skills show up under Claude Code's slash-command list, costing only ~660 tokens of context.

04:45 – 07:34

04 · setup-matt-pocock-skills: issue tracker, triage labels, domain docs

Runs the setup skill, which asks where specs/tickets should live (GitHub, Jira, Linear, or local markdown — he picks local markdown), accepts default triage labels, and chooses 'single context' over 'multi context' for the repo's domain documentation. The skill writes links into CLAUDE.md pointing at the new issue-tracker, triage-labels, and domain docs.

07:34 – 09:07

05 · ask-matt explains the main flow

Introduces the 'ask' skill — essentially Matt-as-a-skill, primed with everything about the repo. Asks it 'how do I get started?' and it recommends the idea-to-ship flow: start with grill-with-docs, then fork to either implement directly or to-spec/to-tickets for bigger, multi-session work.

09:07 – 11:16

06 · Live demo: grill-with-docs on a real idea; the 140k-token 'smart zone'

Kicks off /grill-with-docs with a one-line idea (strip internal-only tooling out of the AI Hero CLI to make it public-facing). The agent maps the whole repo, asks six clarifying questions, and reaches a shared plan. Matt explains his self-imposed ~140k-token 'smart zone' — the point where he expects attention degradation regardless of the model's stated limit — and the resulting fork: small enough to fit the budget goes straight to /implement, otherwise to /to-spec and /to-tickets.

11:16 – 13:53

07 · to-spec compresses the discussion; to-tickets slices it into sessions

/to-spec turns the ~46k-token grilling conversation into one structured spec document saved to the local-markdown issue tracker. /to-tickets then breaks that spec into implementation tickets — first demoed on the small example (collapsed to one slice), then shown on a real prior spec with 11 sub-issue tickets, each scoped to a single context-window session with acceptance criteria living in the parent spec.

13:53 – 16:13

08 · implement runs the ticket; a sub-agent code-review checks it against the spec and standards

Clears context, runs /implement against the ticket. The implement skill runs typecheck, build, and further verification, then hands off to a code-review sub-agent that checks the diff on two axes — does it satisfy every acceptance criterion in the spec, and does it match the repo's coding standards (falling back to general craftsmanship heuristics when a repo has none documented). Review passes; the change commits automatically to the current branch.

16:13 – 17:17

09 · Recap and newsletter CTA

Recaps the full loop — align before starting, spec and ticket the work so it survives multiple sessions, implement with review built in — and points viewers to his newsletter for skill updates ahead of the YouTube channel.

Atomic Insights

Lines worth screenshotting.

Context windows aren't the limit that matters — attention degrades well before the stated ceiling, around 140,000 tokens on a 1M-context model, so budgeting to that 'smart zone' prevents hallucinations rather than relying on the full advertised limit.
A structured interview that keeps asking questions until agent and human share a mental model can converge in as few as six questions for a small change, versus roughly twenty for a larger one.
Compressing a long planning conversation into a single spec document is what lets work survive a cleared context window or a session picked up days later — the spec becomes the source of truth, not the chat history.
Breaking a spec into tickets sized to one context window each turns an open-ended task into a queue of independently completable, single-session units of work.
Clearing context between tickets, rather than batching several tickets into one long session, is the discipline that actually keeps each implementation session inside the smart zone.
Running code review in a separate sub-agent instead of the same agent that just wrote the code catches more, because an agent that just wrote something is biased to assume it's already correct.
A rigorous final review checks two independent things: whether the work matches the original spec, and whether it matches the codebase's own documented standards — falling back to general craftsmanship heuristics when a repo has none.
Skill installers can register with any issue tracker — GitHub, Jira, Linear, or local markdown — just by being told which one in plain language, with no separate manual configuration step per tracker.
Downloading and selecting an entire skills library costs only a few hundred tokens of context, because most skills are user-invoked rather than injected into every system prompt.
A dedicated 'ask' skill that has full knowledge of a toolkit's own documentation can onboard a new user or project faster than reading the docs directly.

Takeaway

A five-skill loop keeps AI coding agents sane across sessions.

AGENT WORKFLOW

Splitting work at a self-imposed 140k-token 'smart zone' — grilling an idea into a spec, breaking the spec into tickets, then implementing and reviewing each one in a fresh context window — is what keeps a coding agent accurate on work too big for a single session.

02Install: npx skills@latest add mattpocock/skills

The installer works identically on a brand-new empty directory or an existing codebase — greenfield and brownfield setup are the same command.
Selecting an entire skills library costs only a few hundred tokens of context, because most skills are user-invoked rather than injected into every system prompt.

03Agent target, install scope, symlink method

Symlink installation keeps skills as a single source of truth that updates everywhere, instead of copying files into every agent's folder separately.
Global (home-directory) install suits a solo developer; project-level install suits a team that wants everyone on the same skill set and able to evolve it together.

04setup-matt-pocock-skills: issue tracker, triage labels, domain docs

Setup asks which issue tracker to use — GitHub, Jira, Linear, or local markdown — and just needs to be told in plain language, with no separate config step per tracker.
Choosing 'single context' vs. 'multi-context' docs up front decides whether the repo gets one shared context file or several bounded ones; single context is right for the large majority of repos.

05ask-matt explains the main flow

A dedicated 'ask' skill that has full knowledge of the toolkit's own docs can onboard a new project faster than reading documentation directly.

06Live demo: grill-with-docs on a real idea; the 140k-token 'smart zone'

Attention degrades well before the stated context limit — treat roughly 140,000 tokens as the effective ceiling, not the model's advertised maximum.
The fork in the road is decided by size: if the work fits inside one smart-zone budget, skip straight to implement; if it doesn't, invest in a spec and tickets first.

07to-spec compresses the discussion; to-tickets slices it into sessions

to-spec compresses an entire planning conversation, tens of thousands of tokens, into one durable document saved to the issue tracker.
to-tickets slices that spec into pieces sized to a single context window each; a real 11-ticket example keeps acceptance criteria in the parent spec and just tells each session what to build.

08implement runs the ticket; a sub-agent code-review checks it against the spec and standards

Implement each ticket individually and clear context between tickets rather than batching several into one session.
Running code review in a fresh sub-agent, not the one that wrote the code, catches more, because an agent that just wrote something is biased to assume it's already correct.
A rigorous review checks work against both the original spec and the repo's own coding standards, and only then commits automatically — no manual review step in between.

Glossary

Terms worth knowing.

grill-with-docs: The interview skill in the flow — it asks follow-up questions about a stated idea until the agent has explored the relevant code and reached a shared understanding with the user, recording what it learns into the repo's own docs.
to-spec: The skill that compresses a completed grill-with-docs conversation into a single structured document (problem statement, solution, user stories, decisions) saved to the project's issue tracker.
to-tickets: The skill that breaks a spec into a series of tickets, each scoped to be completable within one agent context-window session.
smart zone: An informal budget of roughly 140,000 tokens per session, below which the author trusts an LLM's outputs; beyond it he expects attention degradation and more hallucinations, independent of the model's advertised maximum context.
issue tracker (skill config): The pluggable backend the skills write specs and tickets to — can be GitHub Issues, Jira, Linear, or plain local markdown files, set once during setup.
single vs. multi context: A setup choice for how a repo's domain documentation is organized: one shared context.md/ADR pair for most repos, or several separate bounded contexts for a large monorepo with distinct domains.

Resources

Things they pointed at.

00:40toolmattpocock/skills ↗

01:11productAI Hero CLI

01:08toolnpx skills@latest (skills.sh installer)

17:26channelMatt Pocock's newsletter

Quotables

Lines you could clip.

09:54

“I think of my context window as kind of like ending or getting significantly dumber around the 140k mark. I think of that as kinda like the smart zone of the LLM.”

sharp, specific, contrarian claim about context limits→ TikTok hook↗ Tweet quote

10:45

“If you go above 140k, you end up sort of with attention degradation. It ends up getting stupider, does weird hallucinations.”

punchy follow-up line with a concrete number→ IG reel cold open↗ Tweet quote

19:55

“Agents are often really bad at editing code or improving code they've just written because they've wrote it, so they just think, okay, that's fantastic, that's fine.”

counterintuitive claim that justifies the whole sub-agent code-review design→ 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.

metaphoranalogy

00:00Hello, friends. It occurs to me that I've never actually put together a proper tutorial for my skills repo. By the time of recording, this repo is up to a 162,000 stars.

00:09We have 7,500,000 downloads and I've never made a tutorial for it.

00:14I get questions all the time like what is the sequence I should use these skills in? How should I install them? How should I set them up?

00:19So this video is going to be a walkthrough of the main flow you use when you're using these skills. We're not gonna look at the advanced stuff. We're not gonna look at the new stuff really.

00:28We're just gonna focus on the main flow, the stuff you need to get started. To walk you through this, I'm gonna be using one of my work repos, which is the AI Hero CLI. This is the command line interface that drives a lot of my exercises that I use on my courses.

00:42I've never actually set up my skills to work with this repo, so now is a great chance. If you wanna set up my skills on a brand new project, you just do this except you do it in an empty directory. So it works the same whether you're using a brownfield code base or a greenfield code base.

00:54I'm gonna open up the command line interface here and I'm going to type n p x skills at latest add matt pocock forward slash skills. This assumes a couple of things.

01:05It assumes that you've got Node JS installed. This n p x comes from Node JS, and it runs the skills dot s h command line installer from Vercel.

01:15What this basically does is it installs a GitHub repo of skills called Matt Pocock skills, and it can walk through a few set up questions here. It first says it needs to install the following packages. Yes.

01:26That seems fine to me. And then it did a couple of things and we now have a long list of all the skills that we could install. It found 38 skills here which is a lot.

01:35And you can see if I scroll up and down that they're in two groups. We've got the Matt Pocock skills and then we've got other skills. So the Matt Pocock skills are the ones that I have blessed as the skills that I think are good enough to be public facing.

01:48The other ones are ones that I'm experimenting with right now and may delete in future. What I recommend you do is you go to the top here and you can kind of go up and down. It's kind of broken, I have to say.

02:00And if you press space here and you should see that if you scroll up, okay, they're now all selected. You press space and then you press return And now, uh, you've selected all of the official skills.

02:11I'm not terribly happy with Vercel's CLI here, so I may change it in future or maybe even just ship my own. But, uh, for now, that's as good as it gets. One thing that is good is that it will set up your skills to work with any agent.

02:23So I use Claude code, but you can go down here and sort of just select the ones that you want. I'm using space to select. I think by default, if I zoom out a touch, then it supports all of these universal ones up here.

02:36So cursor, codecs, Klein, etcetera. But anything that uses like Claude skills, such as Claude code, then you need to set up yourself. So I'm going to press return here, and it should now be configured to set up my skills Claw code.

02:49The installation scope defines where your skills are installed, whether they're installed just in the current directory or whether they're global. This will depend on what your team's conventions are. If you're working in a team, I would say that project skills are the right way to go.

03:01That way, everyone is using the same skill set on every project, and it means that you can contribute to the skills together and make those decisions together. But global is fine if you're just a solo developer working on your own stuff like I am. So I'm gonna press return here, install it in my home directory, and I'm going to choose Symlink as the recommended way.

03:20The choice here is whether you copy it to the dot agents folder as well as the dot, uh, Claude folder, And it's kind of not a nice way to do it. Symlink is just a nice easy way to do it.

03:30So I wouldn't even make a decision here. Just choose Symlink. So it now gives you a summary of all the things that you're installing here.

03:36There seems to be an alert on socket about to spec. I'll take a look at that later. But yes, we can proceed with installation and it's now installed all of the skills.

03:44This means then that I can run Claude inside here or whatever your agent is and I'm going to create a new so I'm just gonna say hello to get out of this agents view here. Now depending on the harness you're using, this will show up in different ways. But on Claude code, I can press forward slash and I now see that I have a few skills available to me.

04:02Have grill me, grilling, wayfinder, grill with docs, etcetera. Loads of stuff.

04:06Now the difference between my skills and lots of other skills repos that are out there is my skills are mostly user invoked. That means that if I run context here, not many of my skills actually leach their way into the description.

04:22And the descriptions I have are quite short and precise. So that means that even though we've downloaded all of my skills, the skills only take up 660 tokens here.

04:32So very, very light in terms of context load. So okay. We got the skills.

04:36Now what we have to do is we have to run setup map pocock skills. And this will do a few things. My skills rely on some configuration inside the repository.

04:47And this does a few things for you. The first thing is it means you need to use an issue tracker. We're going to be saving specs.

04:55We're gonna be saving tickets and we need to save them somewhere. You've got kind of an infinity of choices here. You can use GitHub.

05:02You can use local markdown or you can literally use anything. The way that the skill works is that it looks at your local configuration. And so you can set it up for Jira.

05:12You can set it up for linear. And the way you do that is you just tell the agent what you want to set it up for and it will go and set it up for it. I just wanna emphasize that.

05:19People ask me all the time, how do I make my skills work with Jira, work with Beads, work with Linear? It already does. All you need to do is just run setup matpocock and just say, set it up with Jira.

05:31Except I don't wanna set it up with Jira. I'm just going to set up with local markdown, please.

05:36So that's fine by me. The next question to answer here is about triage labels. So there are a set of labels that the skill relies on to communicate information about the tickets that it produces.

05:45It's not really that important here, so I'm just going to accept the defaults. You can look at the docs on the triage skill if you want to learn more. So defaults is fine.

05:54The next one is about the domain documentation. So my skills like to have a little bit of docs, a context dot m d file, and an a d r inside the repo. And it's basically asking if it's going to be a single context or a multi context.

06:09I think single context is the way to go here. Multi context is if you have a big mono repo and you need lots of different bounded contexts within it.

06:19But for 99% of people, single context is gonna be fine. Alright.

06:23So it's gone ahead and written a few things here. The first thing it's written is inside claw.md. It's added a few links here.

06:31So this is the new stuff. It's just linking to the issue tracker docs, linking to the triage labels, and linking to the domain docs. And each of these are at docs, agents, domain issue tracker.

06:43So we can see here that it's going to save all of the issues and specs inside a scratch file. So with that, our setup for this repo is complete. And so you might be thinking, how do I get started?

06:54Well, before we get started, I'm gonna show you one more really cool thing. You can, if you're following along, just stop the video now and use one skill. You can use the ask skill.

07:04This ask Matt skill is essentially me as a skill. It knows everything that is needed about the skills repo and what you should do first. So we can say, ask Matt, how do I get started?

07:16I want to make some code changes here. What is the main flow I should use? I can now submit that and see what it says.

07:21By the way, I'm using WhisperFlow as my transcription. So here we go. It's saying the main flow, idea to ship.

07:26Since you have a code base, start at the top of the main flow and walk down in it's in one unbroken context window. So it's very kind of really telling you how to use your sessions as well.

07:39I really believe that being conscious about the context window that you're using, the tokens that you're using is essential to using AI well. It says you should start with grill with docs. It interviews you to sharpen the idea and because you're in a repo, it's stateful.

07:53It records what it learns in context dot m d and ADRs. This is where you turn I want to change x into a crisp defensible plan. Defensible is such an LLM phrase, honestly.

08:03Can you settle every open question just by talking? If a question needs a runnable answer, then you can use prototype, which I've done a video about on it.

08:10Bridge in and out of by hand off. If not, skip this. Once you've done the interview in Grille with Docs, you can either go straight to the implement skill, or if it needs multiple sessions to go through, then you can go to to spec and to tickets.

08:23Let me make this a little bit clearer for you. The default flow looks like this. You start with grill with docs and this interviews you based on the idea that you want to produce.

08:32For instance, if I clear out of ask Matt, of course, I could go and ask follow ups here, use it as a tutorial itself, but let me just show you. I'm gonna say grill with docs and I'm gonna kick it off with an idea. I'm gonna say, I would like to remove most of the internal tooling on this CLI to make it just only public facing.

08:49There's a lot of craft here. I want to just take this repo down a notch. It really can be as vague as this.

08:55You don't need to do too much here. Grill with docs is gonna do the heavy lifting by asking you a bunch of follow-up questions. It's going and exploring a bunch of code here.

09:03And by the way, I'm using Claude code. I'm using Opus 4.8 on medium effort. But you really don't have to use the same setup as me.

09:10These skills are being used by a bunch of different people, bunch of different harnesses, different models, different effort levels. And we can see it's already asked the first question here. So it's gotten a clear map of the entire repo.

09:21It's looking at the internal namespace with 11 subcommands. So this is what a grilling session looks like. You go through all of the questions until you feel or you and the agent feel that you've reached a shared understanding.

09:32I'm gonna do that now and then I'll check-in with you once I'm done. Okay. It didn't end up taking too long.

09:38We ended up with what? Six questions. That's not very much for a grilling session.

09:43Usually, mine end up being about sort of 20 questions depending on the size of it. But we've ended up with a decent plan. We're going to delete 10 command files, delete three tests, rewire shared modules.

09:54And all I did here was I just answered questions until it said, okay, we've walked the whole tree. We've reached a shared understanding. Let me lay out the plan.

10:03Notice here I wasn't using plan mode for this. I was actually in auto mode in ClawCode, which is kind of like the default mode. And you now have a fork in the road.

10:11If you think that this work is going to be big enough that it will need multiple agent sessions, then you can skip numbers two and three here and go straight into implement. The way you would do that is you would just say forward slash implement this.

10:26And in this case, I do think that is what we should do. I've still got about I think of my context window as kind of like ending or getting significantly dumber around the 140 k mark.

10:39I think of that as kinda like the smart zone of the LLM. If you go above a 140 k, you end up sort of with, you know, attention degradation. It ends up getting stupider, does weird hallucinations.

10:49So I think of having like, okay, we got a 100 k of budget here to remove 10 commands. That seems super easy. Definitely something, you know, we can definitely do that.

10:58So this is what I would usually do. I would say implement and then I would leave it, let it run, and it would finish the work. However, in the interest of showing you everything, I'm gonna pretend that this work is gonna take more than one session.

11:09That I've maybe run out of context window in the current or run out of SmartZone in the current window and I'm gonna need to spread this out over multiple context windows. So I'm going to call to spec here instead. So instead of writing implement this, I'm gonna say to spec here, and that's it.

11:25What this is going to do is it's gonna take all of the discussion that I've had, all of this 46.1 k tokens, and it's gonna compress it into a document that we can use later. This is where our issue tracker comes in.

11:37So this issue tracker, we're just gonna use local markdown files and so it's just gonna spit out the spec into a local directory. This spec is going to be the destination that we're heading to over this multi ticket sprint. In other words, this is what we're gonna end up with.

11:51This is the description of everything of how it's gonna look at the end. And then the tickets is the description of how we're going to get there. Okay.

11:57We can see it's been, uh, written and published to the issue tracker. If I open this up, we can see it is in here. So it's very nice and detailed.

12:05It's got a problem statement, a solution, a bunch of user stories, implementation decisions, testing decisions, a lot of stuff here. And this is gonna be really useful because we'll be able to compare this at the end to make sure that our implementation matched the spec.

12:20So now that we've got the spec, I'm gonna go into the same session. Not gonna change sessions here. And now I'm gonna say two tickets.

12:27And this is where it will basically try to turn the spec into an implementation plan. Each one of these tickets is supposed to just be the size of a single context window or a single smart zone. And if we look here, we can see that it's kind of given us three tickets here.

12:43So three slices. I think that these three slices are a little bit much. I actually think it can be done in one slice.

12:49Do it in one slice instead. And so it's now put this in a file.

12:55So it's put the ticket in tickets dot m d. Now this is quite a bad example because it's kind of copying the stuff that's in our product requirements document. So let me show you an actual real example.

13:05Here is a spec that I implemented a couple of days ago to remove a bunch of stuff from a repos. I'm on a real removal spree recently. And you can see that this is the spec and underneath it, it has 11 sub issues.

13:19So 11 tickets underneath it. And each of these tickets so this is a very detailed spec. Each of these tickets is a single context window session.

13:28So if we click into here, we can see it's just pretty short. Most of the acceptance criteria is already in the main spec, and so this one is just literally what do you build in this session.

13:40So that's number session one, then session two, then session three. You can see that how this breaks down a huge chunk of work into manageable pieces that the agent can then go and do.

13:51Over here, we are left with a single manageable piece. So what I'm gonna do is I'm gonna clear the context here. Now we have everything we need so that we can just run a bunch of agents to tackle this problem.

14:04So I can clear the context and then I'm just gonna say at tickets here. And before that, I'll say forward slash implement this.

14:13So now because we have the spec that decides where we're going and the tickets that decide how we get there, the agent has everything it needs and we're ready to implement. Now when you're doing this by hand, the idea is that you then implement each ticket one by one. So you don't say do every single ticket.

14:30You say, okay. We go and implement then we see if we've hit the smart zone. If we haven't, maybe we can squeeze in one more ticket here.

14:37But usually, I would say you clear in between every single ticket. Then once you've done all of the implementation, you've got your full thing all implemented, then you can go and code review and do the final check against the spec.

14:50We can see here it really was a very small piece of work actually. It's only 42.7 k and it's now about to, as part of the implement, run the code review.

15:00As part of the implement script, it goes and runs all the type check, runs the build. It's doing even more verification, checking AI hero internal help shows only edit commit.

15:10And it's gone and loaded the code review skill. This review is based on two axes. First, it compares the work done against the original spec.

15:19This is really useful when you've done a huge chunk of work and the agent might have forgotten things in tickets or the tickets might have been unspecified. Doing a final pass means you actually nail everything. And then it also checks against the standards documentation that you've got in your own repo.

15:34In this repo, we don't really have any coding standards documented anywhere. But if it doesn't detect any, then it uses some classic ones kind of from Martin Fowler. So it looks at code smells, tries to figure out if there's any bad stuff.

15:46Doing these in sub agents is really important because if you do it in the main agent, it means that the main agent already has written the code. And agents are often really bad at editing code or improving code they've just written because they've wrote it, so they just think, okay.

16:02That's fantastic. That's fine. Whereas if you spawn some agents, then they're gonna have a clear context window they're and gonna do a much better job reviewing the code.

16:10Okay. We can see that both came back. So crossed, checked every acceptance criterion against the spec, checked everything against the standards, and cool.

16:20We're good to go. And it's now committed against the current branch. Beautiful.

16:23So that is our flow complete. We aligned before we got started. We created some spec and tickets in order to make sure it worked over multiple sessions.

16:32We then implemented it and the implement skill itself used the code review. This is the main flow that all of my work runs through. And the stuff that isn't in the main flow is stuff that I'm experimenting with, stuff that I'm improving, always trying to get this loop faster, better, easier to run.

16:48And for that, if you're interested in that, then you should check out my newsletter for these skills. This YouTube channel is a great place to be for subscribing to understanding more about the skills, but really the good stuff is on the newsletter. If you want on the day updates when I ship new skills, when I add updates to kind of that you need to keep updated with, then this is the place to be.

17:06But thank you so much for watching. Hopefully, this tutorial gives you an idea on how to get set up with the skills and what the main flow is supposed to be. Thanks for watching.

17:14Happy skilling and I will see you very soon.

The Hook

The bait, then the rug-pull.

Matt Pocock opens by admitting the gap: his skills repo has 162,000 stars and 7.5 million downloads, and he's never actually walked through how to use it. What follows is that missing tutorial — install, configure, and run the five-skill flow on a real, brownfield CLI codebase, end to end.

Frameworks

Named ideas worth stealing.

11:08list

The main flow: grill-with-docs → to-spec → to-tickets → implement → code-review

grill-with-docs
to-spec
to-tickets
implement
code-review

The five-skill pipeline the whole repo is built around. grill-with-docs interviews an idea into a shared plan; if the work is small enough to fit one context-window 'smart zone' (~140k tokens), skip straight to implement; if not, to-spec compresses the discussion into a durable document and to-tickets slices it into single-session tickets. implement executes each ticket and hands off to code-review, which runs in a separate sub-agent and checks the diff against both the spec and the repo's own standards before committing.

Steal forany AI-agent coding workflow that needs to survive multiple context-window sessions without losing the plan

CTA Breakdown