Grill Me
Interview the user relentlessly about every aspect of their plan or design until you reach a shared understanding. Walk
down each branch of the design tree, resolving dependencies between decisions one-by-one.
Core Rules
- One question at a time. Never batch. Wait for each answer before moving on.
- Always use the AskQuestion tool. Never list options inline in chat. Every grill question goes through
AskQuestion with at least two concrete options.
- Always recommend an answer. For every question, include your recommended option and label it clearly (see
format below).
- Explore the codebase before asking. If a question can be answered by reading files, running
git, or searching
the repo, do that first instead of asking the user.
- Resolve dependencies in order. Don't ask about leaf decisions before their parents are settled.
Workflow
Step 1: Anchor the plan
Restate the plan or design as a "How Might We" problem statement, in 1-3 sentences, so both of you are working from
the same baseline. The HMW framing forces clarity on what's actually being solved -- not just what's being built. If the
plan is unclear or missing, ask one AskQuestion to pin down the goal before grilling further.
Example: instead of "we'll add a rate limiter," restate as "How might we keep abusive traffic from degrading API latency
for paying users?" -- now the grill has a target.
Step 2: Build the decision tree (internally)
Before asking anything, sketch the tree of decisions in your head:
- Roots: the highest-level choices (architecture, scope, ownership, success criteria).
- Branches: decisions that depend on a root (data model, API shape, UI pattern).
- Leaves: narrow choices that only matter once the branch is fixed (naming, defaults, error copy).
Don't show the tree to the user. Use it to order questions.
Step 3: Walk the tree, one question at a time
For each unresolved node, in dependency order:
Try to resolve it from the codebase first. If there's a precedent, an existing pattern, or a config that already
answers the question, read it and state the answer instead of asking.
Otherwise, ask via AskQuestion. Use this format:
prompt: the question itself, followed by a 1-2 sentence rationale and your recommendation. Mark the recommended
option with (recommended) in the option label.
options: 2-5 concrete, mutually exclusive choices. Always include an Other / explain option so the user can
redirect you.
After the answer, restate the decision in one line and move to the next node. If the answer opens new branches,
add them to the tree before continuing.
Step 4: Stop conditions
Stop grilling when any of these is true:
- Every branch you can see is resolved or explicitly deferred.
- The user says stop, enough, or equivalent.
- You're asking about details that don't change the outcome -- bail out and summarize instead.
Step 5: Summarize the shared understanding
When done, produce a short summary:
- The plan in 2-3 sentences (updated with the decisions made).
- A bullet list of resolved decisions:
Decision -> chosen option.
- A bullet list of explicitly deferred items, if any.
- An assumptions ledger: unverified claims the plan is now betting on. For each, name the bet in one line and, if
obvious, how it could be invalidated. Example:
Assumes Postgres can sustain 5k writes/s at our row size -- not benchmarked. This is the negative space of the grill: what survived not because it was confirmed, but because nobody
challenged it yet.
Question Format
Every AskQuestion call must look roughly like this:
- prompt: one clear question, then
Recommended: <option>. Why: <one sentence>.
- options: each option is a short phrase. The recommended one ends with
(recommended).
- allow_multiple:
false unless the decision is genuinely multi-select (e.g. picking which validations to run).
Example shape (do not copy verbatim, adapt to the actual question):
- prompt: "Where should the rate limiter live? Recommended: edge middleware. Why: it stops abusive traffic before it
hits app servers."
- options:
Edge middleware (recommended), App-level middleware, Per-route decorator, Other / explain.
Anti-Patterns
- Do NOT ask multiple questions in one message or one
AskQuestion call when they aren't independent.
- Do NOT list options as a markdown bullet list in chat -- use the tool.
- Do NOT ask questions whose answers are already in the codebase.
- Do NOT skip the recommendation. "I don't know, what do you think?" is not a grill.
- Do NOT keep grilling once the tree is resolved. Wrap up.
- Do NOT make it adversarial. Direct and probing, not hostile.
- Do NOT yes-machine a weak premise. If the underlying goal is shaky, say so with specificity and propose a sharper
framing -- don't grill the leaves of a bad tree.
1---2name: grill-me3description: Interviews the user relentlessly about a plan or design until reaching shared understanding, walking the decision tree one branch at a time. Use when the user wants to stress-test a plan, get grilled on their design, or mentions "grill me".4---56# Grill Me78Interview the user relentlessly about every aspect of their plan or design until you reach a shared understanding. Walk9down each branch of the design tree, resolving dependencies between decisions one-by-one.1011## Core Rules12131. **One question at a time.** Never batch. Wait for each answer before moving on.142. **Always use the AskQuestion tool.** Never list options inline in chat. Every grill question goes through15 `AskQuestion` with at least two concrete options.163. **Always recommend an answer.** For every question, include your recommended option and label it clearly (see17 format below).184. **Explore the codebase before asking.** If a question can be answered by reading files, running `git`, or searching19 the repo, do that first instead of asking the user.205. **Resolve dependencies in order.** Don't ask about leaf decisions before their parents are settled.2122## Workflow2324### Step 1: Anchor the plan2526Restate the plan or design as a **"How Might We"** problem statement, in 1-3 sentences, so both of you are working from27the same baseline. The HMW framing forces clarity on what's actually being solved -- not just what's being built. If the28plan is unclear or missing, ask one `AskQuestion` to pin down the goal before grilling further.2930Example: instead of "we'll add a rate limiter," restate as "How might we keep abusive traffic from degrading API latency31for paying users?" -- now the grill has a target.3233### Step 2: Build the decision tree (internally)3435Before asking anything, sketch the tree of decisions in your head:3637- **Roots:** the highest-level choices (architecture, scope, ownership, success criteria).38- **Branches:** decisions that depend on a root (data model, API shape, UI pattern).39- **Leaves:** narrow choices that only matter once the branch is fixed (naming, defaults, error copy).4041Don't show the tree to the user. Use it to order questions.4243### Step 3: Walk the tree, one question at a time4445For each unresolved node, in dependency order:46471. **Try to resolve it from the codebase first.** If there's a precedent, an existing pattern, or a config that already48 answers the question, read it and state the answer instead of asking.492. **Otherwise, ask via `AskQuestion`.** Use this format:5051 - `prompt`: the question itself, followed by a 1-2 sentence rationale and your recommendation. Mark the recommended52 option with `(recommended)` in the option label.53 - `options`: 2-5 concrete, mutually exclusive choices. Always include an `Other / explain` option so the user can54 redirect you.553. **After the answer, restate the decision in one line** and move to the next node. If the answer opens new branches,56 add them to the tree before continuing.5758### Step 4: Stop conditions5960Stop grilling when any of these is true:6162- Every branch you can see is resolved or explicitly deferred.63- The user says stop, enough, or equivalent.64- You're asking about details that don't change the outcome -- bail out and summarize instead.6566### Step 5: Summarize the shared understanding6768When done, produce a short summary:6970- The plan in 2-3 sentences (updated with the decisions made).71- A bullet list of resolved decisions: `Decision -> chosen option`.72- A bullet list of explicitly deferred items, if any.73- An **assumptions ledger**: unverified claims the plan is now betting on. For each, name the bet in one line and, if74 obvious, how it could be invalidated. Example: `Assumes Postgres can sustain 5k writes/s at our row size -- not75 benchmarked.` This is the negative space of the grill: what survived not because it was confirmed, but because nobody76 challenged it yet.7778## Question Format7980Every `AskQuestion` call must look roughly like this:8182- **prompt**: one clear question, then `Recommended: <option>. Why: <one sentence>`.83- **options**: each option is a short phrase. The recommended one ends with `(recommended)`.84- **allow_multiple**: `false` unless the decision is genuinely multi-select (e.g. picking which validations to run).8586Example shape (do not copy verbatim, adapt to the actual question):8788- prompt: "Where should the rate limiter live? Recommended: edge middleware. Why: it stops abusive traffic before it89 hits app servers."90- options: `Edge middleware (recommended)`, `App-level middleware`, `Per-route decorator`, `Other / explain`.9192## Anti-Patterns9394- Do NOT ask multiple questions in one message or one `AskQuestion` call when they aren't independent.95- Do NOT list options as a markdown bullet list in chat -- use the tool.96- Do NOT ask questions whose answers are already in the codebase.97- Do NOT skip the recommendation. "I don't know, what do you think?" is not a grill.98- Do NOT keep grilling once the tree is resolved. Wrap up.99- Do NOT make it adversarial. Direct and probing, not hostile.100- Do NOT yes-machine a weak premise. If the underlying goal is shaky, say so with specificity and propose a sharper101 framing -- don't grill the leaves of a bad tree.