**July 24, 2026**

# Grilling is uncertainty reduction — why grill-me works, and how it compounds

You type `/grill-me` and the agent refuses to write code. Instead it starts asking questions —
[over fifty of them](https://medium.com/@marc.bara.iniesta/the-ai-coding-repo-that-went-viral-because-it-adds-friction-e2b5c4d2fcc2)
before it will produce a single line, in sessions that
[run about forty-five minutes](https://www.aihero.dev/my-grill-me-skill-has-gone-viral). Matt
Pocock's skill went viral for exactly this move, and his skills pack became the most-installed one
for Claude Code. The popular verdict, sharpest in Marc Bara's write-up, was that the skill works
because it *adds friction*: it "does not make the agent smarter" — it makes it "slower in exactly the
places where slowing down matters."

That verdict is close, and it's the reason the skill gets adopted and then half-understood. Friction
is the right observation and the wrong name. Something is being spent, but slowness is the byproduct,
not the product. What the questions actually buy is certainty — and once you see the mechanism that
way, everything about when and how to use it falls into place.

## Friction is the wrong name

Friction is a cost you tolerate. You don't get anything for it; you accept it because the alternative
is worse. If that were all grilling did, the honest pitch would be "slow down, it's good for you" —
and nobody installs a skill for that.

But look at what each question does. The agent is walking down a decision tree, and every answer
prunes a branch. Pocock's own prompt says it plainly: *interview me relentlessly about every aspect
of this plan until we reach a shared understanding*, and *walk down each branch of the design tree
resolving dependencies between decisions one by one*. That is not resistance being added. It is
possibilities being removed. Before the session, the space of things you might have meant is wide;
after it, it's narrow. The value isn't the questions and it isn't the minutes — it's the **drop in
uncertainty** about what you actually want built.

Rename the mechanism and the skill stops being a discipline you endure and becomes an instrument you
reach for.

## What interrogation actually reduces

The vocabulary for this is decades old and predates agents entirely. Software estimators call it the
**cone of uncertainty**: at the start of any piece of work, what you know about it is at its widest
spread, and the cone narrows as you go. Steve McConnell's canonical point is the one that matters
here — the cone narrows "both by research and by decisions that remove the sources of variability."
It doesn't close on its own, and it doesn't close by writing more code. It closes when someone makes
a call that eliminates a way the work could have gone.

Grilling is that, industrialized. The agent is querying the one knowledge base no repository contains
— your tacit intent, the thing you know but never wrote down — and turning it into decisions that
remove variability. Pocock frames it as modern rubber-ducking: talking an idea through until you've
found all the permutations. The permutations were always there. The interrogation is just the
cheapest instrument we have for surfacing and resolving them, one branch at a time, before any of
them gets built by accident.

## Why before, not after

If the questions buy certainty, the next question is *when* to buy it — and the answer isn't "as
early as possible." Lean software development named the right moment: the **last responsible moment**,
which Mary and Tom Poppendieck defined as the point at which failing to decide would eliminate an
important option. Decide before that and you're guessing; the
[cost-of-change curve is far flatter than it used to be](https://www.mountaingoatsoftware.com/blog/the-cost-of-change-curve-is-outdated),
and locking requirements early mostly means building the wrong thing with great discipline. Decide
after it and the decision gets made for you, by default, in code you now have to unwind.

Grilling lives at that moment. It's not "specify everything up front" — it's "drive uncertainty down
far enough to commit, right before commitment, and no sooner." Certainty is cheapest to buy before
you've built anything, because there's nothing yet to throw away. Building starts when the decision
entropy is low enough that committing is safe. That's why the skill runs at the *start* of a task and
then gets out of the way: it's front-loading the one purchase that's cheapest when made first.

## The same move at every commitment line

Once you can name the move — reduce uncertainty at the last responsible moment — you start seeing it
everywhere work crosses from "maybe" into "committed."

A Definition of Ready is a grilling. It asks: do we understand this well enough to start? A spec
review is a grilling. Replenishment triage — deciding what's allowed to become active work — is a
grilling. Each is a checkpoint where someone certifies that the uncertainty has been driven down far
enough to spend real effort on the other side. "Ready" has always meant "grilled." The viral skill
didn't invent the practice; it gave a single, visible session to a move that good teams were already
making, informally, at every commitment boundary they respected.

Which is also why the practice belongs to the workflow, not to one tool. A commitment point with an
entry gate — a declared statement of what "ready" requires — is grilling made into a contract instead
of a mood. The gate is where the uncertainty reduction gets certified, and its criteria are the
questions you already know you'll need answered. This is the readiness half of
[making policies explicit](ref:/blog/make-policies-explicit): the gate isn't ceremony, it's the place
the grilling's verdict gets recorded so the next person doesn't have to take it on faith.

## Reduction that evaporates gets re-bought

Here is the catch that the roundups miss. A grilling session that leaves nothing behind is a purchase
with no receipt. You resolved fifty branches today; tomorrow's work — a new session, a fresh agent,
next week's you — starts from the wide end of the cone again and re-buys the same certainty at the
same price. The reduction was real, and then it evaporated with the context window.

The skill's own evolution is the proof, and it's sitting in the source repo. Pocock's `grill-with-docs`
is a grilling session that *also* builds the project's domain model — "sharpening terminology and
updating CONTEXT.md and ADRs inline." The persistent `CONTEXT.md` file exists precisely because a
grilling that only lives in one conversation isn't enough: the resolved terminology and the decisions
have to be written somewhere durable, or the next session can't inherit them. (This is worth
attributing carefully — the persistence idea comes from the skills repo, not from the "went viral"
essay, which covers only the single-session skill.) The residue is the point. Without it, you're not
compounding; you're re-purchasing.

## Compounding: a knowledge layer is CONTEXT.md generalized

`CONTEXT.md` is the first step. The general form is a **knowledge layer** — a place where grilled-out
answers become durable records, not one file but a fabric of them, so that the next piece of work
starts partway down the cone instead of at its mouth.

This is where a board earns its keep, at the level of principle rather than mechanics. When resolved
intent rides on the work item itself, the answers aren't in a chat log someone has to remember — they
travel with the work. When acceptance criteria are written down, they *are* the grilling's residue in
contract form: the must-haves the interrogation surfaced, now checkable by someone other than the
agent that produced them. When decisions become records that persist across sessions, the reduction
stops resetting. The board is simply where grilled-out knowledge lands and accumulates — and because
it accumulates, tomorrow's grilling is shorter, because half its branches were already pruned and the
pruning was written down.

That's the whole arc: grilling reduces uncertainty; the reduction is only worth what survives the
session; a knowledge layer is what lets it survive. A spec, in that light, is the interrogation's
living output — which is exactly the artifact
[spec-driven development](ref:/blog/spec-driven-development) argues has to stay true after the code
moves on.

## Your next grilling is worth more if it outlives the session

The skill is right, and the internet named it half-right. The questions aren't friction; they're the
cheapest instrument we have for buying certainty at the last responsible moment, before commitment,
when it's cheapest to hold. That much you get for free the moment you install it.

The other half is the part that compounds: capture the answers where the next piece of work will
inherit them. Do that and every grilling session pays forward — the cone starts narrower each time,
because last week's decisions are still resolved.

If you want the answers your grilling produces to become durable records the next work inherits,
that's what [kanbento](ref:/start) is for.

## Run your workflow as a protocol, not a board

kanbento is a headless, agent-native kanban — your agents operate the board through a CLI while state lives in plain files you can read and diff.

[Get started](/start)