Grill Me: Claude Code skill for design interviews

Grill Me is a Claude Code skill for design interviews, adapted by AR Labs from Matt Pocock's public grill-me skill. Before an agent writes a plan or any code, it questions the person who owns the idea, one decision at a time, until every branch of the design has been settled. The result is a written design brief that records what was decided, why, and what was ruled out. It is for anyone about to hand a design to coding agents. We use it at the start of every campaign in our coding pipeline, the route every code change takes (spec, test-first build, second-model review, a person's merge). A campaign is work planned in one PRP and split into a tree of tasks; a PRP, or product requirement prompt, is a plan agents build from, in Rasmus Widing's format as we adapted it. We also use the skill for any plan that needs stress-testing before work begins.

The skill is adapted from Matt Pocock's public grill-me, a short prompt that tells an agent to "interview me relentlessly" and to walk down each branch of the design tree, one question at a time, with a recommended answer for each. The opening of our version is Pocock's text. We added everything after it: the five-block design brief, the rule on separating pull-request count from task breakdown, and the handoff into its pipeline. Pocock's grill-me has since become a pointer to his newer grilling skill, which asks every currently answerable question in one numbered round; we install grilling alongside our own version, unchanged.

How it works

The interview treats a plan as a tree of decisions, where some decisions only make sense once others are settled. The agent asks one question at a time and gives its own recommended answer with each, so the owner can accept, adjust or reject it quickly. If a question can be answered by reading the codebase, the agent reads the codebase instead of asking.

When the tree is resolved, the agent writes the brief straight to a file in five blocks:

1. Stated constraints: every hard fact the owner gave, quoted word for word.
2. Resolved decisions: each contested choice, with what was chosen, the owner's decisive words as evidence, the context in neutral language, the alternatives rejected and why, and a confidence level. The format follows architecture decision records, so each entry can later become one.
3. Scope boundaries: in scope, out of scope with a reason, and deferred with the condition that would bring it back.
4. System decomposition: the containers, external dependencies and data flows that were discussed, and nothing that was not.
5. Acceptance criteria in Gherkin, the Given/When/Then format, covering the happy path and the error and edge cases the interview surfaced.

The owner then chooses to continue, park or abandon. For continue or park, the last two decisions recorded are how much autonomy the coding run may have (which human approval points it may pass with nobody watching) and how the work will land (through a pull request, or committed directly to the main branch). A transcript of the interview is saved beside the brief as an audit record. A script, not the agent, records the decision on the campaign's tracking entry, so the handoff is the same every time. A continued campaign is picked up by a fresh agent session that writes the PRP, working from the brief and never from the interview conversation.

The judgement it encodes

Quote, never paraphrase. Constraints and evidence are copied verbatim from the conversation while it is still in context. A paraphrased constraint is where a plan quietly drifts from what the owner said.

Only contested choices become decisions. Uncontested defaults are left out, so the decision list stays readable and every entry marks a real fork.

Context is written neutrally. The context paragraph becomes the context section of a decision record, so it describes the forces at play rather than arguing for the chosen option.

Facts are the agent's job; decisions are the owner's. The agent looks things up itself and only asks about choices.

How many pull requests and how many tracked tasks are separate questions. A ruling that the work should land as one pull request says nothing about how finely it is tracked, and the brief records the two separately.

The interview session stops at the handoff. It does not go on to write the plan, so the next stage starts from the written record rather than from an agent's memory of the conversation.

What exists today

The skill runs at the start of every campaign in our coding pipeline, and its brief is the first written artefact of our spec-driven development. Coding Planner routes campaigns to it, and To Issues later splits the resulting plan into tasks. It can also be run by voice: a voice session can carry an interview already under way or start a new one, with the questions spoken and the brief written as usual.

Example

From a real brief for our Taskgraph project, which ported a prototype status-map tool into a tested package. The brief recorded ten resolved decisions and ten acceptance scenarios. One decision, abridged (the owner's quoted evidence line is omitted):

### RD-5: Strictness of the page comparison
- Chosen: On the recorded fixtures, v1's SVG equals the prototype's
  SVG after normalisation: same elements, text, classes and
  attributes, with numeric coordinates within one unit. Any
  difference fails, and the run stops and reports it; it never
  explains a difference away.
- Context: An unattended run that may judge a difference acceptable
  has quietly weakened the precondition.
- Alternatives rejected:
  - Byte-identical output: fails on attribute order and float
    formatting that change nothing on screen.
  - A visual pixel diff: needs a browser in the test suite and
    tolerates structural differences a consumer of the JSON would see.
- Confidence: High