Modern Creator
Why Modern Creator?
The Hype Kevin · YouTube

Ship like the best engineers: Matt Pocock's AI workflow

A walk-through of Matt Pocock's v1.3 skills plugin for Claude Code, following one coffee-subscription feature from a one-line prompt through an interview, a written spec, ticket-sized builds, and a two-agent review.

Posted
4 days ago
Duration
Format
Essay
educational
Views
113.9K
1.7K likes
Big Idea

The argument in one line.

Matt Pocock's skills plugin turns a one-sentence coding prompt into a structured interview, a written spec, and ticket-sized builds, so every decision an agent would otherwise silently guess gets made by you instead.

Who This Is For

Read if. Skip if.

READ IF YOU ARE…
  • Developers using Claude Code, Cursor, or similar coding agents on real production features who want a repeatable process instead of one giant prompt.
  • Anyone who has watched an agent silently guess at an edge case and ship the wrong assumption without flagging it.
  • Engineering leads evaluating structured 'skills' plugins (grill-me, spec, tickets, retro) as a team workflow for AI-assisted coding.
SKIP IF…
  • You're looking for a no-code or non-technical AI workflow; this is a developer-tooling walkthrough built around GitHub issues and Claude skills.
  • You want a quick one-line tip; the video is a 9-minute, 17-step walkthrough of a full process.
TL;DR

The full version, fast.

Matt Pocock's skills plugin for Claude Code, now at version 1.3, replaces one long prompt with a staged process. The grill-me skill interviews you before any code is written, mapping every decision the agent would otherwise guess silently as a tree and asking only the 'frontier' of questions whose parents are already settled. A glossary locks down ambiguous words, and a throwaway prototype handles anything too visual to settle by talking. /to-spec writes the agreed plan into numbered user stories; /to-tickets slices it into pieces sized to stay under the roughly 150,000-token point where agents reason worse. Each ticket gets implemented and reviewed by separate fresh agents, and /retro turns anything the agent struggled with into a permanent rule, check, or lint.

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:17

01 · So what are you there for?

Cold open: an agent can build a whole feature in a coffee break, so Matt Pocock's skills plugin, with more GitHub stars than React, answers what's left for the developer to do.

00:17 – 00:47

02 · The silent guess

A one-sentence prompt to add a subscription-pause button ships fast, but the agent silently decides billing timing, the already-packed coffee bag, pause length, and email wording on its own.

00:47 – 01:02

03 · Couldn't you write a longer prompt?

A longer prompt doesn't fix it, because you'd only write down the decisions you already thought of, and the packed bag wasn't one of them.

01:02 – 01:54

04 · The decision tree in the fog

Before any code exists, the grill-me skill interviews you, mapping the feature as a tree of decisions and asking only about the 'frontier' whose parent is already settled; small changes get ~6 questions, normal ones ~20, and one lesson got 46.

01:54 – 02:41

05 · One word for one thing

Grill with Docs keeps a glossary in the repo while grilling, giving 'pause' and 'skip' precise, distinct definitions and listing words to avoid, so the agent stops using 20 words where one would do.

02:41 – 02:56

06 · Questions you can't settle by talking

For 'ungrillable' questions like what a screen should look like, the agent hands off to a fresh session that builds a throwaway prototype for you to click through and pick.

02:56 – 03:29

07 · /to-spec: the destination

Once the fog clears, /to-spec writes up the problem, the fix, and numbered user stories, and agrees on the single 'seam' the tests will poke at; the spec is the destination, tickets are the journey.

03:29 – 04:08

08 · /to-tickets and the smart zone

Agents reason worse past roughly 150,000 tokens, the 'smart zone,' so /to-tickets slices the spec into pieces sized to fit inside it, each running the full stack from database to button.

04:08 – 04:41

09 · The build, one clean head per ticket

Each ticket starts in a clean chat and builds test-first at the agreed seam; the new implement-spec command in 1.3 can instead run every ready ticket in parallel, each in its own repo copy, landing on one branch.

04:41 – 05:19

10 · Review at two desks

An agent that wrote the code thinks it's fine because it wrote it, so review goes to two fresh agents: one checks the diff against the spec, the other against coding standards the implementer never saw.

05:19 – 05:40

11 · /pr and merge danger

The /pr skill, adapted from Dex Horthy's Show Me skill, writes PR descriptions around the smallest picture that explains the change, before/after proof, and a Merge Danger section rating one-way/two-way door and blast radius.

05:40 – 06:31

12 · /retro

Before clearing the chat, typing RETRO makes the agent read back the session and suggest changes to the repo, checks, and instructions; a mistake a machine can spot becomes a lint rule, not just a written standard.

06:31 – 07:06

13 · A real run from Matt's repo

A real spec with 41 user stories produced 10 dependency-linked tickets in four minutes; they merged as 28 commits and roughly 14,000 lines about two hours after the spec was written.

07:06 – 07:33

14 · Isn't this waterfall?

The common pushback, addressed by Uncle Bob on Matt's own livestream: once a feature ships, Matt deletes the spec, treating it as a projection of decisions now captured in the code, tests, and glossary.

07:33 – 08:04

15 · Too defensive for today's models?

The other pushback, via a quoted tweet from Joe Sadoski switching to pstack: most skills cost nothing until invoked, and Matt deletes skills once models outgrow the need for them.

08:04 – 08:28

16 · The one-line skill

The grill-me skill file, with over a million installs on skills.sh, is one line long; the grilling logic behind it is 28 lines, which Matt calls the most influential four sentences he's written.

08:28 – 09:05

17 · Your job

The agent can write every line of the feature, but every decision, the bill, the bag, the word skip, still belongs to you; Matt frames the agent as a tactical programmer and you as the strategic general.

Atomic Insights

Lines worth screenshotting.

  • An AI agent given a one-sentence feature request doesn't ask about edge cases, it silently guesses at them and keeps going.
  • A longer prompt doesn't fix silent guessing, because you can only write down the decisions you already thought of.
  • Matt Pocock's grill-me skill maps a feature as a tree of decisions and interviews you only on the 'frontier,' the questions whose parent decision is already settled.
  • On a small change grill-me asks about 6 questions, on a normal one about 20, and it once asked 46 questions while Matt was filming a course lesson.
  • A shared glossary kept in the repo during grilling stops an agent from using 20 words where one precise term would do.
  • Decisions too visual to settle by talking, like a UI screen, get handed to a fresh session that builds a throwaway prototype for you to click through and pick.
  • Once grilling is done, /to-spec turns the settled decisions into numbered user stories and agrees on the 'seam,' the one place the tests will poke at the feature.
  • Agents reason worse somewhere past about 150,000 tokens, a point Matt calls the smart zone, so /to-tickets slices a spec into pieces that each fit inside it.
  • The rule of thumb for ticket count: estimate the tokens a job needs and divide by 150,000, so a million-token refactor becomes about seven tickets.
  • Every ticket starts in a clean chat, because a fresh head reasons better than one still holding the last ticket's context.
  • An agent that wrote code believes it's fine, because it wrote it, so code review goes to two separate fresh agents instead of the one that built the feature.
  • One review agent checks the diff against the spec for anything missing or unasked for; the other checks it against coding standards the implementer never saw.
  • The /pr skill writes a 'Merge Danger' section into every pull request: is this a one-way or two-way door, and how big is the blast radius.
  • Typing RETRO before clearing the chat makes the agent read back its own session and suggest fixes to the repo, the checks, or the instructions it struggled with.
  • A mistake a machine can catch becomes a lint rule or pre-commit check, not just a note in the coding standards, which are reserved for judgment calls.
  • Matt refuses to let retro run on autopilot, because an agent fixing its own findings starts chasing false positives.
  • A real spec with 41 user stories produced 10 linked tickets in 4 minutes and merged as 28 commits and roughly 14,000 lines about two hours later.
  • Once a feature ships, Matt deletes the spec, because he treats it as a projection of decisions already captured in the code, tests, and glossary.
  • 16 of the 27 skills in Pocock's plugin only load when you type their name, so an idle agent never sees them and the full installed set costs 660 tokens.
  • The actual grill-me skill file is one line long; the real grilling logic is 28 lines, which Matt calls the most influential four sentences he's written.
Takeaway

Grill the agent before it builds anything.

WHAT TO LEARN

Matt Pocock's skills plugin forces every decision an agent would otherwise guess silently through an interview, a written spec, ticket-sized builds, and two-agent review before a line of code ships.

01So what are you there for?
  • An agent that can build a whole feature in the time it takes to make coffee shifts your job from writing code to deciding what the code should do.
  • The real value of a coding-agent workflow isn't speed, it's making sure a fast agent doesn't quietly answer questions you never saw it ask.
02The silent guess
  • A one-sentence feature request gets built fast, but the agent fills every unstated gap with its own guess and never mentions it did.
  • Check what an agent decided on your behalf after a short prompt: billing timing, edge-case handling, and wording are exactly the kind of gaps it guesses at.
  • A working feature isn't the same as a correct one; 'the tests pass' only confirms what you remembered to specify.
03Couldn't you write a longer prompt?
  • Writing a longer prompt doesn't fix silent guessing, because you can only write down the decisions you already thought to make.
  • The fix isn't a bigger prompt, it's letting the agent interview you before it writes any code, so it surfaces the decisions you didn't think of.
04The decision tree in the fog
  • Treat a new feature as a tree of decisions in fog rather than a single request, with each top-level choice branching into smaller ones underneath it.
  • Have the agent ask only about the 'frontier,' the decisions whose parent choice is already settled, instead of dumping every possible question on you at once.
  • Let the agent fetch facts from your own code with a helper lookup, but keep every actual decision with you; facts are its job, decisions are yours.
  • Expect more questions on a bigger change: roughly 6 on something small, 20 on something typical, and don't be alarmed if a genuinely complex feature asks 40 or more.
05One word for one thing
  • Keep a living glossary in the repo while grilling a feature, defining ambiguous terms like 'pause' and 'skip' precisely enough that the agent can't blur them together.
  • List the words to avoid alongside each glossary term, because an agent that doesn't know your project's jargon defaults to using 20 vague words instead of one precise one.
  • If an agent's answer is unclear, don't accept it: ask it to restate the same point in plain English using only the terms from your glossary.
06Questions you can't settle by talking
  • Some decisions, like what a screen should look like, can't be settled through a text interview; hand those to a fresh session that builds a disposable prototype instead.
  • Build several visibly different throwaway options rather than one polished mockup, so the choice between them is obvious and fast, then feed the decision back into the plan.
07/to-spec: the destination
  • Once every decision is settled, convert the conversation into a written spec with the problem, the fix, and numbered user stories, so nothing settled gets lost or reinterpreted later.
  • Agree on the 'seam,' the single place in the code the tests will exercise, before any tickets get written; fewer seams means a cleaner, more testable feature.
  • Treat the written spec as the destination and the tickets that follow as the journey toward it, not as two competing sources of truth.
08/to-tickets and the smart zone
  • Agents reason worse somewhere past roughly 150,000 tokens of context, so size each unit of work to fit comfortably under that ceiling rather than however big the feature naturally is.
  • Estimate the tokens a job needs and divide by 150,000 to get a rough ticket count; a million-token refactor becomes about seven separate tickets.
  • Make each ticket a full vertical slice, database to interface, so it can be built and tested on its own instead of leaving half-finished layers behind.
09The build, one clean head per ticket
  • Clear the chat between tickets so each one starts in a clean context instead of carrying forward the noise and assumptions of the last one.
  • Build test-first at the agreed seam: write a failing test, then the minimum code to pass it, one slice at a time rather than the whole feature at once.
  • If an agent consistently skips a step like refactoring no matter how you ask, stop fighting it in the build phase and move that check downstream to review.
10Review at two desks
  • Don't let the agent that wrote the code review its own work; it already believes the code is fine because it wrote it.
  • Split code review into two narrow, separate passes: one checking the diff against the spec for anything missing or unasked for, another checking it against your coding standards.
  • Hide your coding standards from the agent that implements the feature and show them only to the reviewer, so the review finds real violations instead of pre-cleaned code.
11/pr and merge danger
  • Have every pull request state whether the change is a one-way or two-way door and how big its blast radius is, so reviewers can calibrate scrutiny to actual risk.
  • Write PR descriptions around the smallest picture that explains the change plus before-and-after proof, not a wall of generated prose nobody will read.
12/retro
  • Before clearing the final chat on a ticket, have the agent read back through its own session and suggest fixes to the repo, the checks, or its instructions.
  • Turn any mistake a machine can reliably detect into a lint rule or pre-commit check instead of a line in your coding standards document.
  • Reserve written coding standards for judgment calls only; anything checkable automatically belongs in a deterministic check, not a document an agent might skim past.
  • Don't let an agent act on its own retro suggestions automatically; review and pick which fixes to keep, because an agent grading its own work chases false positives.
13A real run from Matt's repo
  • A real 41-story spec produced 10 dependency-linked tickets in four minutes, and the whole chain merged as 28 commits and roughly 14,000 lines about two hours later.
  • Let independent tickets build in parallel, each in its own copy of the repo, and land on one branch instead of serializing work that doesn't actually depend on itself.
  • Leave a ticket open on purpose when it's genuinely research rather than forcing a decision before you have the information to make it well.
14Isn't this waterfall?
  • Delete the spec once the feature ships instead of keeping it as a stale artifact; treat it as a snapshot of decisions that now live in the code, tests, and glossary.
  • Avoid waterfall by keeping grilling, prototyping, and ticket slicing cheap and fast, so planning stays close to the moment of building instead of happening far in advance.
15Too defensive for today's models?
  • Weigh the real criticism that a heavily structured process can feel defensive against models that already infer intent well, and judge it against your own models and stakes, not the default.
  • Make sure the structure you add costs nothing until it's invoked; skills that only load when named don't burden every interaction, even if you keep dozens installed.
  • Delete process you've outgrown; a step that compensated for a weaker model's limitations should come out once better models make it unnecessary.
16The one-line skill
  • Don't confuse a skill's value with its length; the core interview skill here is one line long, and the real logic behind it is only 28 lines.
  • The leverage in a structured agent workflow comes from the quality of the questions it asks, not from the volume of instructions or code behind it.
17Your job
  • An agent can write every line of a feature and still leave every real decision, the pricing, the edge case, the exact wording, in your hands.
  • Think of the agent as the tactical programmer executing a plan and yourself as the strategic one setting the plan, not as two interchangeable coders.
Glossary

Terms worth knowing.

Grilling (grill-me)
A Claude Code skill that interviews you about every decision in a feature before any code is written, instead of letting the agent guess.
Frontier
The set of decisions in a feature's decision tree whose parent decision is already settled, so they're the only questions the agent asks you in a given round.
Smart zone
The roughly 150,000-token range in which an AI agent reasons sharply; past it, response quality degrades, a term Matt Pocock credits to Dex Horthy.
Seam
The single place in the codebase where the tests for a feature will exercise it, agreed on before tickets are written.
/to-spec
The skill that converts a grilled-out set of decisions into a written spec: the problem, the fix, and numbered user stories.
/to-tickets
The skill that slices a spec into pieces small enough to stay under the smart-zone token limit, each covering one full vertical slice of the feature.
/retro
A skill run at the end of a session that reviews the agent's own struggles and suggests changes to the repo, its instructions, or its automated checks.
Merge Danger
A section the /pr skill adds to every pull request describing whether the change is a one-way or two-way door and how big its blast radius is.
One-way / two-way door
A decision-making metaphor for how reversible a change is: a two-way door is easy to undo, a one-way door isn't, used here to flag how risky a merge is.
Resources

Things they pointed at.

00:08toolmattpocock/skills (GitHub) ↗
00:08productTotal TypeScript
00:00channelMatt Pocock on X ↗
08:09linkskills.sh install counts ↗
07:37linkJoe Sadoski's pstack switch (X post) ↗
06:31linkcourse-video-manager issue #1641 / PR #1652 ↗
07:06linkcourse-video-manager PR #1759 (merge danger example) ↗
Quotables

Lines you could clip.

00:00
“Your agent can build a whole feature while you make a coffee. So what are you there for?”
cold open hook, works standalone→ TikTok hook↗ Tweet quote
01:36
“Facts are its job. Decisions are yours.”
tight thesis line→ IG reel cold open↗ Tweet quote
08:45
“The value is in the questions.”
closing punch, quotable on its own→ newsletter pull-quote↗ Tweet quote
08:50
“So the agent is the sergeant, and you're the general.”
memorable closing metaphor→ TikTok hook↗ 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
Your agent can build a whole feature while you make a coffee. So what are you there for? Matt Pocock has an answer.
He teaches developers for a living. He made Total TypeScript, and his answer is a folder of agent skills with more stars on GitHub than React. On October 4th, he shipped version 1 .3.
Say you run a coffee subscription app, and you type, let users pause their subscription. 10 minutes later, there's a pause button, the tests pass, and it works. Then, a customer pauses on the 29th and still gets a bag of coffee on the 1st because it was already roasted and packed.
Somebody had to decide what happens to that bag. Your agent decided. It also decided whether the bill stops today or at the end of the month, how long a pause can last, and what the reminder email says.
You wrote one sentence, so it filled every gap with a guess and kept going. Agents are polite like that. Couldn't you write a longer prompt?
You'd only write down the decisions you thought of, and the packed bag wasn't one of them. Matt turns the conversation around. Before any code exists, the agent interviews you, and his skill for it is called Grill Me, a relentless interview about your plan.
Picture the feature as a tree of decisions in the fog. Pause sits at the top. Under it hang billing, the packed bag, and how long a pause lasts, and each of those has more decisions hanging off it.
The grilling skill maps that tree, finds every decision whose parent is already settled, called the frontier, and asks you all of them in one numbered round. Each question comes with the agent's recommended answer, so a lot of the time you type yes, yes, no, end of the month. Your answers settle a layer, a new frontier lights up, and the fog moves back.
Facts are the agent's job. If the answer is somewhere in the code, it sends a helper agent to go and read it. Decisions are yours.
And it can't start on the code until the frontier is empty and you agree you're on the same page. On a small change, Matt gets about 6 questions, and around 20 on a normal one. While filming a lesson for his course, it once asked him 46.
His post about it? Dude, chill, you're scaring the noobs. Halfway through, you mention customers can skip a month.
The agent stops you. Is skip the same thing as pause? This version is called Grill with Docs, and it keeps a glossary in your repo while it grills.
Pause gets one line. No deliveries and no charges until the resume date. Skip gets another.
One delivery missed. Billing carries on. Under each, the words to avoid, like hold and freeze.
An agent dropped into a project has to guess its jargon, so it uses 20 words where one would do. Matt once read out a real reply from Opus 5 that ended, It is genuinely load -bearing though, so that's how you know it matters. Then he asked the obvious question, What does that mean?
So there's a skill for that moment too. type wait what and the agent pitches its last message again in plain english using the words from your glossary some questions won't settle by talking like what the pause screen should look like for those ungrillable ones the agent hands off to a fresh session builds a throwaway prototype with a few screens that look nothing alike and you click through them and pick then the answer comes back to the grilling when the fog is gone you stay in the same chat and type to spec no more questions this time The agent writes up everything you settled, the problem, the fix, and a long, numbered list of user stories.
As a customer who pauses after my bag is packed, I still get that bag, and my pause starts after it. First, though, it agrees the seams with you, the places where the tests will poke at the feature. And the ideal number of seams is one.
For us, that's the billing module. The spec goes up as an issue in your tracker, labeled Ready for Agent. The spec is the destination.
The tickets are the journey. Why tickets? Because an agent gets worse the more it's holding.
Somewhere past 150 ,000 tokens, it stops reasoning as sharply. And the part before that is the smart zone, a term Matt says he stole from Dex Horthy. So, to tickets cuts the spec into slices that each fit one fresh session.
Each slice runs through every layer, database to button, so it works on its own. Ticket 1. Pausing stops the next charge.
Ticket 2. A resume date. Ticket 3.
The packed bag. Ticket 4. The emails.
Three and four can't start until one is done. The rule of thumb? Guess the tokens a job needs and divide by 150 ,000.
So a million token refactor becomes seven tickets. Then the build. Type implement on ticket one, clear the chat, implement ticket two, so every ticket starts in a clean head.
Or use implement spec, new in 1 .3, which builds the whole spec in one go. One agent per ready ticket, each in its own copy of the repo, all landing on one branch. Either way, it works test first.
A failing test at the agreed seam, then only enough code to pass it, one slice at a time. The skill used to have a refactoring step too. Matt dropped it, because the agent never ever ever did it.
Refactoring moved to review, and review happens at a different desk. An agent that has written some code thinks it's fine, because it wrote it. So code review hands the diff to two fresh agents.
One reads it against the spec, looking for anything missing, anything nobody asked for, and anything that looks done but is wrong. The other reads it against your coding standards and a dozen classic code smells from Martin Fowler's refactoring. The agent that wrote the code never saw those standards.
Models are bad at following a list of don'ts while they build, and a reviewer hunting for exactly those problems has nothing else on its mind. On ticket 3, the spec reviewer quotes our user story back. Pausing today cancels the packed bag.
When the fix goes up as a pull request, a skill called PR writes the description. It's adapted from Dex Horthy's Show Me skill. The smallest picture that explains the change, proof from before and after, and a section called Merge Danger.
Is this a one -way door or a two -way door? And how big is the blast radius? Ours adds a column to the subscriptions table.
Two -way door, blast radius, billing. The last step is the other big one in 1 .3. Before you clear the chat, type RETRO.
The agent reads back through the session it just had and suggests changes to its surroundings, the repo, the checks, the instructions. That matters, because your agent won't complain. It bumps into problems, keeps pushing until the feature works, and the struggle stays buried in the transcript.
Here it spent 10 minutes hunting for the billing code, so it suggests one line in your agent instructions that points at it. It called the payment provider directly, twice, which your codebase never does, so that becomes a lint rule. A mistake a machine can spot gets a check, full stop.
and the written coding standards keep only the judgment calls. Found an error? Do a retro and make it impossible next time.
People keep asking Matt to put retro on autopilot, and he says don't, because an agent fixing its own findings ends up chasing false positives. It only suggests, and you pick which fixes to keep. A coffee app is a toy, so take something real.
On September 25th, in the app Matt uses to make his courses, a spec went up with 41 user stories. Within four minutes, there were 10 tickets, linked by what blocks what. One ticket started the chain, five waited on it, and the last one stayed open on purpose as research.
All of it landed on one branch. 28 commits and almost 14 ,000 lines, merged a little over two hours after the spec was written. Five days later, the next features pull request had its own merge danger section.
Two -way door, blast radius deploy ordering. Isn't this waterfall with extra steps? That's the most common pushback, and Uncle Bob made the case on Matt's own livestream.
Watch what happens to the spec though. Once the work ships, Matt closes the issue and the spec is gone. He calls a spec a projection of the decisions made during grilling, and by then those decisions live in the code, the tests, and the glossary.
The prototypes keep it from turning into waterfall, and anything small enough for one session gets planned in one session. The other pushback says smart models don't need this much structure. One builder switched to PStack, the stack from our last video, because Matt's skills felt too defensive for today's models.
Most of them cost nothing until you call them, though. 16 of the 27 skills in the plugin only exist when you type their name, so the agent never sees them. And in his tutorial, the whole installed set took up 660 tokens.
He also deletes skills once the models catch up. Version 1 .3 removed the merge conflict skill because the harness can handle it. So what's inside the repo with more stars than React?
Open GrillMe, which skills .sh counts at over a million installs. It's one line long. Call the skill tool with grilling.
The grilling skill it calls is 28 lines, and Matt calls the original GrillMe the most influential four sentences I've ever written. There's almost nothing in there to copy. The value is in the questions.
and only you can answer them. So what are you there for? The decisions.
The agent can write every line of the pause feature, and every call inside it still belongs to you. The bill, the bag, the word skip. Matt thinks of agents as brilliant tactical programmers who need a strategic one above them.
So the agent is the sergeant, and you're the general. Our customer pauses on the 29th, gets the bag that was already packed, and pays nothing more until the resume date. You decided that in round two on your coffee break.
I'm Kevin. When something new drops in AI or tech, I take it apart here and tell you if it's worth the hype. Subscribe so you catch the next one.
The Hook

The bait, then the rug-pull.

Matt Pocock's agent-skills plugin has more GitHub stars than React, and version 1.3 answers an increasingly obvious question: if an agent can build the whole feature while you're on a coffee break, what exactly are you there for? Built around a coffee-subscription pause button, the answer is that you're there to make the dozens of small decisions the agent would otherwise make silently.

Frameworks

Named ideas worth stealing.

01:02model

Grilling (the decision tree / frontier model)

Treats a feature as a tree of decisions in fog; the agent only asks about the 'frontier,' decisions whose parent is already settled, one round at a time until the tree is fully decided.

Steal forany AI-agent coding workflow where a vague prompt currently leads to silently guessed edge cases
02:56list

Spec to tickets to build to review to retro pipeline

  1. /to-spec
  2. /to-tickets
  3. implement (one clean head per ticket)
  4. review at two desks
  5. /pr merge danger
  6. /retro

The five-skill sequence that turns a grilled-out decision set into shipped, reviewed code with a permanent feedback loop back into the repo's instructions and checks.

Steal forany team process for using coding agents on production features
03:29concept

The smart zone / 150K-token ticket sizing rule

Agents reason sharply only up to roughly 150,000 tokens held in context; ticket size is set by dividing the estimated tokens a job needs by 150,000.

Steal forsizing any agent task so it stays inside peak reasoning quality
04:41model

Two-desk review (spec reviewer + standards reviewer)

  1. Spec reviewer: checks against the user stories for anything missing, unasked-for, or wrong
  2. Standards reviewer: checks against coding standards and classic code smells the implementer never saw

Code review is split across two fresh agents with different, narrow mandates instead of one agent reviewing everything at once.

Steal forany AI-assisted code review process
05:19concept

Merge Danger (one-way/two-way door + blast radius)

Every pull request description states whether the change is easily reversible and how far its impact reaches, borrowed from Dex Horthy's 'Show Me' skill.

Steal forPR templates for any team shipping agent-generated code
CTA Breakdown

How they asked for the click.

VERBAL ASK
08:56subscribe
“Subscribe so you catch the next one.”

a single, brief sign-off line after the thesis lands, no hard sell or sponsor pitch

MENTIONED ON CAMERA
00:08toolmattpocock/skills (GitHub) ↗
00:00channelMatt Pocock on X ↗
08:09linkskills.sh install counts ↗
07:37linkJoe Sadoski's pstack switch (X post) ↗
06:31linkcourse-video-manager issue #1641 / PR #1652 ↗
07:06linkcourse-video-manager PR #1759 (merge danger example) ↗
FROM THE DESCRIPTION
OTHER LINKSAlso linked in the description.
Storyboard

Visual structure at a glance.

open
hookopen00:00
the fog
valuethe fog01:02
the destination
valuethe destination02:56
smart zone
valuesmart zone03:29
two desks
valuetwo desks04:41
/retro
value/retro05:40
real run
valuereal run06:31
your job
ctayour job08:28
Frame Gallery

Visual moments.

open00:01Frame at 00:10 from Ship like the best engineers: Matt Pocock's AI workflow00:10Frame at 00:17 from Ship like the best engineers: Matt Pocock's AI workflow00:17Frame at 00:23 from Ship like the best engineers: Matt Pocock's AI workflow00:23Frame at 00:30 from Ship like the best engineers: Matt Pocock's AI workflow00:30Frame at 00:37 from Ship like the best engineers: Matt Pocock's AI workflow00:37
open00:01Frame at 00:10 from Ship like the best engineers: Matt Pocock's AI workflow00:10Frame at 00:17 from Ship like the best engineers: Matt Pocock's AI workflow00:17Frame at 00:23 from Ship like the best engineers: Matt Pocock's AI workflow00:23Frame at 00:30 from Ship like the best engineers: Matt Pocock's AI workflow00:30Frame at 00:37 from Ship like the best engineers: Matt Pocock's AI workflow00:37Frame at 00:44 from Ship like the best engineers: Matt Pocock's AI workflow00:44Frame at 00:51 from Ship like the best engineers: Matt Pocock's AI workflow00:51Frame at 00:57 from Ship like the best engineers: Matt Pocock's AI workflow00:57the fog01:04Frame at 01:11 from Ship like the best engineers: Matt Pocock's AI workflow01:11Frame at 01:18 from Ship like the best engineers: Matt Pocock's AI workflow01:18Frame at 01:25 from Ship like the best engineers: Matt Pocock's AI workflow01:25Frame at 01:31 from Ship like the best engineers: Matt Pocock's AI workflow01:31Frame at 01:38 from Ship like the best engineers: Matt Pocock's AI workflow01:38Frame at 01:45 from Ship like the best engineers: Matt Pocock's AI workflow01:45Frame at 01:52 from Ship like the best engineers: Matt Pocock's AI workflow01:52Frame at 01:59 from Ship like the best engineers: Matt Pocock's AI workflow01:59Frame at 02:06 from Ship like the best engineers: Matt Pocock's AI workflow02:06Frame at 02:12 from Ship like the best engineers: Matt Pocock's AI workflow02:12Frame at 02:19 from Ship like the best engineers: Matt Pocock's AI workflow02:19Frame at 02:26 from Ship like the best engineers: Matt Pocock's AI workflow02:26Frame at 02:33 from Ship like the best engineers: Matt Pocock's AI workflow02:33Frame at 02:40 from Ship like the best engineers: Matt Pocock's AI workflow02:40Frame at 02:46 from Ship like the best engineers: Matt Pocock's AI workflow02:46Frame at 02:53 from Ship like the best engineers: Matt Pocock's AI workflow02:53Frame at 03:00 from Ship like the best engineers: Matt Pocock's AI workflow03:00Frame at 03:07 from Ship like the best engineers: Matt Pocock's AI workflow03:07Frame at 03:14 from Ship like the best engineers: Matt Pocock's AI workflow03:14the destination03:20Frame at 03:27 from Ship like the best engineers: Matt Pocock's AI workflow03:27Frame at 03:34 from Ship like the best engineers: Matt Pocock's AI workflow03:34Frame at 03:41 from Ship like the best engineers: Matt Pocock's AI workflow03:41Frame at 03:48 from Ship like the best engineers: Matt Pocock's AI workflow03:48Frame at 03:55 from Ship like the best engineers: Matt Pocock's AI workflow03:55Frame at 04:01 from Ship like the best engineers: Matt Pocock's AI workflow04:01smart zone04:08Frame at 04:15 from Ship like the best engineers: Matt Pocock's AI workflow04:15Frame at 04:22 from Ship like the best engineers: Matt Pocock's AI workflow04:22Frame at 04:29 from Ship like the best engineers: Matt Pocock's AI workflow04:29Frame at 04:35 from Ship like the best engineers: Matt Pocock's AI workflow04:35Frame at 04:42 from Ship like the best engineers: Matt Pocock's AI workflow04:42Frame at 04:49 from Ship like the best engineers: Matt Pocock's AI workflow04:49two desks04:56Frame at 05:03 from Ship like the best engineers: Matt Pocock's AI workflow05:03Frame at 05:09 from Ship like the best engineers: Matt Pocock's AI workflow05:09Frame at 05:16 from Ship like the best engineers: Matt Pocock's AI workflow05:16Frame at 05:23 from Ship like the best engineers: Matt Pocock's AI workflow05:23Frame at 05:30 from Ship like the best engineers: Matt Pocock's AI workflow05:30Frame at 05:37 from Ship like the best engineers: Matt Pocock's AI workflow05:37Frame at 05:44 from Ship like the best engineers: Matt Pocock's AI workflow05:44/retro05:50Frame at 05:57 from Ship like the best engineers: Matt Pocock's AI workflow05:57Frame at 06:04 from Ship like the best engineers: Matt Pocock's AI workflow06:04Frame at 06:11 from Ship like the best engineers: Matt Pocock's AI workflow06:11Frame at 06:18 from Ship like the best engineers: Matt Pocock's AI workflow06:18Frame at 06:24 from Ship like the best engineers: Matt Pocock's AI workflow06:24Frame at 06:32 from Ship like the best engineers: Matt Pocock's AI workflow06:32Frame at 06:38 from Ship like the best engineers: Matt Pocock's AI workflow06:38Frame at 06:45 from Ship like the best engineers: Matt Pocock's AI workflow06:45real run06:52Frame at 06:58 from Ship like the best engineers: Matt Pocock's AI workflow06:58Frame at 07:05 from Ship like the best engineers: Matt Pocock's AI workflow07:05Frame at 07:12 from Ship like the best engineers: Matt Pocock's AI workflow07:12Frame at 07:19 from Ship like the best engineers: Matt Pocock's AI workflow07:19Frame at 07:26 from Ship like the best engineers: Matt Pocock's AI workflow07:26Frame at 07:33 from Ship like the best engineers: Matt Pocock's AI workflow07:33Frame at 07:39 from Ship like the best engineers: Matt Pocock's AI workflow07:39Frame at 07:46 from Ship like the best engineers: Matt Pocock's AI workflow07:46Frame at 07:53 from Ship like the best engineers: Matt Pocock's AI workflow07:53Frame at 08:00 from Ship like the best engineers: Matt Pocock's AI workflow08:00Frame at 08:07 from Ship like the best engineers: Matt Pocock's AI workflow08:07Frame at 08:13 from Ship like the best engineers: Matt Pocock's AI workflow08:13Frame at 08:20 from Ship like the best engineers: Matt Pocock's AI workflow08:20Frame at 08:27 from Ship like the best engineers: Matt Pocock's AI workflow08:27Frame at 08:34 from Ship like the best engineers: Matt Pocock's AI workflow08:34Frame at 08:41 from Ship like the best engineers: Matt Pocock's AI workflow08:41Frame at 08:47 from Ship like the best engineers: Matt Pocock's AI workflow08:47your job08:54Frame at 09:01 from Ship like the best engineers: Matt Pocock's AI workflow09:01
One-click upgrade to your Google

Get more breakdowns in your search results

Add Modern Creator as a preferred source and Google shows you more of our breakdowns in Search, Top Stories, and AI Overviews. It only changes what you see, and you can undo it in your Google settings anytime.

Add to Preferred SourcesOpens your Google source preferences with us pre-loaded. Tick the box and you're done.
Watch next

More from this channel + related breakdowns.

49:22
Theo - t3․gg · Tutorial

You're using AI agents wrong

Theo says he barely codes hands-on anymore, then spends 49 minutes proving he still ships more than most full-time engineers by showing exactly how he runs dozens of AI agents at once.

September 9th
33:48
Theo - t3․gg · Essay

He's right.

Boris Cherny said coding is solved. Matt Pocock called it VC-funded bullshit. Theo argues they're both right, because they're using the word coding to mean two different things.

August 24th
43:15
Theo - t3․gg · Tutorial

A proper guide to Fable 5

How Theo turned a returned, unmetered Claude release into a five-and-a-half-hour unattended agent run that cleared a month of stalled pull requests for about $150.

July 6th