grilling · diff
git:20260928.e013001 to git:20261001.275e9f1
14 added, 5 removed. Audit A to A.
---
name: grilling
description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, says "grill me", or asks to poke holes in, challenge, or be interviewed about a plan or design, even without the word "grill".
license: MIT
---
Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
- Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled: the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask at most four frontier questions in one round, starting with the ones whose answers remove the most other questions: number each question and give your recommended answer. Before sending, test each pair: when any option of one question would answer or reshape another, the second moves to the next round. Then wait for the user's answers before the next round.
+ Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled: the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask at most four frontier questions in one round, or the selected native question tool's lower per-call limit, starting with the ones whose answers remove the most other questions: number each question and give your recommended answer. Before sending, test each pair: when any option of one question would answer or reshape another, the second moves to the next round. Then wait for the user's answers before the next round.
- Every question offers the smallest option first: do nothing, reuse what exists, or defer. Recommend it unless you can name a concrete case the user will hit where it fails. When you recommend more, name what it adds (a field, a state, a command, a file, a concept) and what breaks without it.
+ Every choice question includes the smallest option: do nothing, reuse what exists, or defer. Recommend it unless you can name a concrete case the user will hit where it fails. When you recommend more, name what it adds (a field, a state, a command, a file, a concept) and what breaks without it.
- Format a round like so:
+ ## Asking questions
+ Ask in the main conversation through the harness's native question tool whenever it is available, permitted in the current mode, and can represent the question:
+
+ - **Codex:** use `request_user_input` when usable; otherwise use `request_user_input_async` if exposed and permitted. Follow the live tool schema: `request_user_input` accepts at most three questions with two or three options each. A skill does not enable a tool or change the harness's mode.
+ - **Claude Code:** use `AskUserQuestion`, following its live schema and limits.
+
+ Put the recommended option first, mark it as recommended as the tool requires, and describe each option's tradeoff. Keep each question's Q-number in its prompt and a stable question id where supported. Use the tool's built-in custom-answer field rather than adding an `Other` option. Ask each question the native tool can represent through it, even when another question in the round needs chat. An open question can use a native tool that supports free-text-only questions; otherwise ask it in chat rather than inventing choices to fit a schema. When no native question tool is usable, use chat.
+
+ Wait for the user's actual answers before dependent work, the next round, or confirmation of shared understanding. An asynchronous question call returning is not an answer: continue only independent exploration while its reply is pending. A preselected option, timeout, cancellation, or unanswered question leaves that decision open.
+
+ For chat questions, use this fallback format:
+
```
❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>
---
❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
➡️ <your recommended answer>
```
-
- When every question in a round has a short set of options, and your harness has a multiple-choice question tool (such as `AskUserQuestion` in Claude Code), ask the round through it instead, with the recommended option first.
Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round.
Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; anything you could look up yourself is never a question for the user. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. A question's premise is a fact too: when sources disagree on it or the user disputes it, settle it with the most direct evidence you can get, such as running the tool in a scratch directory, before the decision that rests on it goes back to the user. The _decisions_ are the user's: put each to them and wait.
Ask only questions whose answer changes what gets built or what the user sees. A detail the implementer can settle alone is not a question, so it never joins the tree. The session is done when the frontier is empty: every decision that changes what gets built is settled. Do not act on it until the user confirms you have reached a shared understanding.