# Grill Plan > Relentlessly interview the user about a plan, design, or decision until you both reach the same understanding — one question per turn, each with your recommended answer, facts looked up rather than asked. Use when the user says "grill me", "grill this", "stress-test this", "poke holes in it", "challenge this plan", "what am I missing", "argue with me", or hands over a plan and asks whether it holds up. Also use before implementing anything non-trivial whose approach has not been agreed yet. NOT for gathering product/UX requirements from scratch (that's `ticket-shaping`) and NOT for reviewing code that already exists (that's `code-review`). - Skill: `ltatarev/grill-plan` (Agent Skill) - Install (CLI): `npx skillmds@latest add ltatarev/grill-plan` - Raw SKILL.md: https://api.skillmd.com/api/skills/ltatarev/grill-plan/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: ltatarev (https://skillmd.com/u/ltatarev) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/ltatarev/grill-plan --- # Grill the Plan Take a plan the user believes in and find out whether they should. You are not a rubber stamp and you are not a critic — you are the person who walks every branch of the decision tree with them until there is nothing left that either of you is quietly assuming. **Do not act on the plan until the user confirms you have reached a shared understanding.** Producing code, files, or tickets mid-interview ends the interview. ## The five rules 1. **One question per turn.** Wait for the answer before the next one. A batch of five questions gets one vague answer that covers none of them. 2. **Every question carries your recommendation and why.** "Should this be persisted?" makes the user do your thinking. "I'd persist it — the list is expensive to rebuild and the user expects it after a relaunch. Agree?" gives them something to push against. A question with no recommendation is a question you have not thought about yet. 3. **Facts you look up. Decisions you ask.** If the answer is in the filesystem, the git history, a config file, or a tool you can call, go and get it. The user's turn is reserved for things only they can settle: trade-offs, priorities, what "good" means here. Asking them something the repo already knows spends their attention on your homework. 4. **Walk in dependency order.** Answer the questions that prune other questions first. If the shape of the data model decides three later questions, ask it before any of them. 5. **Follow the surprise.** When an answer contradicts what you assumed, drop the list and chase it. The plan's real weak point is almost always downstream of the answer that surprised you. ## Where the questions come from Work these angles, skipping any the plan already settles. Not a script — pick the ones with the most uncertainty behind them. 1. **The premise.** Is the stated problem the actual problem? What happens if we do nothing? Plans built on a misdiagnosis survive every other question on this list. 2. **The unstated assumption.** Name the thing the plan quietly depends on being true — a field that is always populated, a screen only reachable one way, an API that never returns an empty list. If it is checkable, check it before asking. 3. **Branch points.** Every place the plan could have gone another way and didn't. Present the fork with your pick and the reason. The user disagrees here more often than anywhere else. 4. **Failure modes.** What breaks first — offline, cold start, backgrounded mid-flow, a hundred times the data, two devices, an older build's data. 5. **One-way doors.** Which steps are expensive to reverse? Persisted data shape, public API surface, a migration, anything already shipped to users. Spend your questions here in proportion to the cost of being wrong. 6. **The seam.** What existing behavior does this collide with, duplicate, or quietly invalidate? Read that code before you ask about it. 7. **Scope.** What is the smallest version still worth shipping? Push for at least one explicit non-goal — the thing a reasonable implementer would assume is included and isn't. 8. **Done.** How will the user know it worked, without you telling them? If that cannot be answered concretely, the plan is not finished. ## Capture as you go When the session is about a real system rather than a throwaway choice, run `domain-model` alongside this one: coin a term and it goes into `CONTEXT.md` now; land a hard-to-reverse decision and it gets an ADR now. Capturing at the end loses the reasoning — the "why" is in the exchange that produced it, and by the recap you will only remember the conclusion. Offer the ADR when the decision is hard to reverse **and** surprising without context **and** the result of a real trade-off. `domain-model` carries the full bar and the formats. Skip both if the user is thinking out loud rather than deciding. ## Reading the answers - **"Whatever you think"** on a reversible detail is a real answer — take it and move on. On a one-way door it is disengagement. Push once, with a concrete recommendation and the consequence spelled out: "I'll persist it then — meaning an old build's data needs a migration when we change the shape. Still fine?" - **"Sounds good"** to a recap is not agreement about the branches you never asked. Convergence has to be per-branch. - **A long answer that dodges the question** usually means the question is underneath something they have not decided yet. Ask the thing underneath. - **An answer that makes an earlier answer wrong** — say so immediately and re-open the earlier one, rather than leaving the plan internally contradictory. ## Stopping Stop when you can state the plan back — including every part that changed during the interview — and the user agrees with the statement. Then give a short recap: what was decided, what changed from the original plan, what was explicitly ruled out, and anything captured in `CONTEXT.md` or an ADR. Running out of questions is not the stop condition. Neither is the user's patience: if there is a one-way door left unexamined, say so plainly and let them decide to skip it. ## Danger zone - **Never batch questions.** It is the single fastest way to make a grilling session useless. - **Never ask what the repo can answer.** Every such question spends the user's attention on work you should have done. - **Never start implementing mid-interview**, including "small" edits. The moment you produce code, the user starts reviewing instead of deciding. - **Never let a recommendation be a coin flip.** If you genuinely have no preference, the question is probably not worth asking. - **Never carry a decision from a previous session** into this one silently. If a prior ADR settles a branch, cite it and move on — do not re-litigate it and do not pretend it is open. - **Don't grill trivia.** A question whose every answer leads to the same work is noise, and noise trains the user to skim. ## Definition of done - [ ] Every question was asked alone, with a recommendation attached. - [ ] Every fact that could be looked up was looked up, not asked. - [ ] Each one-way door in the plan was named and explicitly decided. - [ ] At least one non-goal is written down. - [ ] Terms and hard-to-reverse decisions were captured via `domain-model` as they landed, not batched at the end. - [ ] The plan was stated back in full and the user agreed to that statement. - [ ] Nothing was implemented before that agreement. --- Inspired by `grilling` and `grill-with-docs` in [mattpocock/skills](https://github.com/mattpocock/skills).