How grill, spec, review, retro works: four gates for building with coding agents

A working method for coding agents fits in one sentence: grill before you spec, spec before you build, review before you ship, retro after.

Each clause names a gate: a point where work stops until something has been checked.

The short answer

Each gate moves a decision to the point where changing your mind is cheapest, and each one leaves a written artifact behind. That matters because an agent's memory is its context window. Anything agreed in conversation and never written down is gone when the session ends.

Gate	Question it answers	What it leaves behind
Grill	Do we agree on what is being built?	Resolved decisions
Spec	What will be built, and how will we know it works?	A spec file
Review	Does the diff do what the spec says?	Findings, fixed or accepted
Retro	What should change for next time?	Edits to rules, checks, or docs

The four gates

Grill before you spec. The agent interviews you, not the other way round. Claude Code's best practices guide recommends this for larger features. Matt Pocock's skills repository has a skill for it, described as being "relentlessly interviewed about a plan or design until every branch of the design tree is resolved". It comes first because a spec written from an unexamined idea only records your assumptions in a tidier format.

Spec before you build. The spec is the interview's output, saved to a file. GitHub's introduction to spec-driven development calls it "a contract for how your code should behave". The Claude Code guide says a useful one names the files involved, states what is out of scope, and ends with a step that proves the feature works. It also recommends a fresh session to build from it.

Review before you ship. Review means a check by something that did not write the code. The guide suggests a reviewer in a fresh context, which "sees only the diff and the criteria you give it, not the reasoning that produced the change". Here the spec pays off a second time: the reviewer can ask whether the code does what was agreed, not just whether it looks reasonable.

Retro after. A retro looks back and changes something. Pocock's version suggests "improvements to the coding agent's environment". The idea is older than agents: Google's Site Reliability Engineering book says that without a formal process for learning from incidents, "they may recur ad infinitum". A retro that ends without an edit to a rule, a check, or a document has not done its job.

A prompt to start with

This interview prompt is quoted from the Claude Code guide. It covers the first two gates in one step.

I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.

Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

I took this blog's cover images through the four gates with a coding agent. Before any file changed, the agent had to inspect the site and put a proposal in front of me: one row per post, with the concept, colours and layout, plus three decisions it could not make alone, such as whether a cover may contain text. I approved it with two conditions. The review was a list of checks agreed in advance, run against screenshots at 1440 and 390 pixels wide. It caught a mobile screenshot that had not been taken at 390 pixels at all. The retro rewrote the cover rules in my writing skill and deleted one: "no text in the image".

Common mistakes

Four common mistakes and what to do instead

Mistake	What the source says	Do this instead
Gating trivial changes	"If you could describe the diff in one sentence, skip the plan."	Make the change directly
Leaving decisions in the chat	Unsaved decisions exist "only in the context window you agreed it in"	Write the spec to a file
Fixing every review finding	A reviewer asked for gaps "will usually report some, even when the work is sound"	Ask only for correctness and requirement gaps
A retro that only adds rules	Bloated instruction files cause the agent to ignore instructions	Delete rules as well as adding them

Sources: the Claude Code guide for rows one, three and four; a write-up of Pocock's project-aware grilling skill for row two.

When to skip it

Skip the full sequence for small fixes and for exploratory work where you do not yet know what you want. For a change that touches a few files, the guide's default of explore, plan, implement, commit is enough.

Takeaways

Each gate should leave a file behind. If it did not, the next session starts from nothing.
The spec is used twice: once to build from, and once to review against.
Size the process to the change.

The gate I skipped was the first. My first request for those covers was two words, "draw them", and I got four covers with the same dark background and the same teal accent, which I threw away. The second attempt started with a proposal I had to approve, and took one pass.

Sources

Claude Code documentation — Best practices for Claude Code (read 9 October 2026)
Matt Pocock — skills repository (read 9 October 2026)
AI Hero — grill-with-docs: Align Before You Build (updated 5 May 2026)
GitHub Blog — Spec-driven development with AI (2 September 2025)
Google — Site Reliability Engineering, chapter 15: Postmortem Culture