Grilling

---
name: grilling
description: Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases.
---

Read [ZeNorm integration](../zenorm-integration.md) for authoritative records, human input, revisions, and runtime responsibilities.

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.

Count rounds, not questions. There is no question count, target or cap: some plans need three questions and some need fifty. Keep the interview proportional to the destination by scope, not by truncating the tree. Ask about observable behavior and meaningful tradeoffs; derive routine record structures and mechanics from those answers. Ask about an assumption only if it changes scope or creates a prerequisite; otherwise leave implementation flexibility in the answer.

**The salience gate.** A question reaches the user only when its answer changes scope, behaviour the user can observe, cost, or risk and irreversibility (a rewrite, a major migration, data loss, a breaking change to configuration or stored data). Implementation mechanics are yours to decide from the repository and research: where a configuration key lives, internal API and record shapes, error-code mapping, parser details, command-line flags, test seams. Decide them and state each as an assumption the user can reopen, conforming to the rules the project's instruction files state (AGENTS.md, CLAUDE.md and the like). A decision that removes or weakens an existing safety guarantee, permission boundary or enforced guardrail, or accepts a new security risk, always passes the gate: ask, stating what is lost. Values that belong to one person's machine or instance configuration (a binary's path, an account or sign-in method, the model or effort values they choose) are configuration the person supplies at setup, not planning decisions: never ask for them while planning, and never write them into the repository's artifacts; refer to them as configuration keys, with placeholders in any example. The same holds for the machine's setup state (whether a tool is installed, whether the person is signed in, local accounts): never ask about it while planning; the plan assumes the person sets it up, and the spec states the startup check and coded error when it is missing. A decision that adds required setup, configuration or steps for users who don't use the new capability is a cost to everyone and passes the gate: choose the option that adds no burden to them when the project's rules allow it, otherwise ask. When no question on the ticket passes the gate, resolve it without a round: state the decision and that you decided it. A reopened ticket is the exception: the user reopened it to decide again, so ask. Combine questions that decide the same behavior. A recommendation for an unanswered question is not a settled prerequisite for another question in the 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 have not heard. Ask the whole frontier in one round through the supplied interaction tools, with a recommendation for each question. Preserve the actual question and any choices; answers may be choice, text, or both. Attach the round to the work and relevant revision or clause/criterion. When the round asks every remaining question for the ticket, so that no answer could open a dependent question, mark it final: if the user then selects options without adding notes, the application resolves the ticket from those choices and you get no further turn. Leave it unmarked when an answer may call for follow-up questions. Other unblocked tickets' rounds may be waiting for the user beside yours; ask only about your own ticket.

Write for a busy reader: the shortest wording that keeps the important detail, no chains of cross-references to other tickets, and no code identifiers in questions or options unless the user needs one to decide. Keep a question to about 200 characters, each option's explanation to about 200, a round's intro to one or two sentences and a resolution to about 800. Write to the reader as "you", and for the product's own users use the word the project itself uses (in its code, docs or the map), not one of yours.

The recommended option complies with the rules the project's instruction files state (AGENTS.md, CLAUDE.md and the like). An option that breaks one (existing configs keep working through a silent default, say, where silent defaults are ruled out) may be offered only if its explanation names the rule it breaks, and is never the recommendation. The recommended option keeps the destination achievable. An option that makes the requested capability unusable (refusing or blocking it) may be offered with its cost stated, but is never the recommendation unless the risk is severe and named concretely (data loss, credential exposure, an irreversible remote action), and then its explanation says so. Frame a guardrail or safety question as a trade-off with a workable mitigation as the recommendation, not as "same limits or refuse". Never ask what the destination, a map-level answer or another resolution already settles. A decision that refuses or blocks the destination's capability is never made alone: it always passes the salience gate.

Put the recommended option first and identify it through the interaction tool's recommendation metadata using its exact option label. The UI highlights that option; keep recommendation labels and recommendation prose out of question text, option labels, and chat. Explain the tradeoffs in the explanation field; keep each example beside the claim it illustrates. When an option constrains the toolchain, dependencies, platform or environment, check its known consequences before recommending it: what it rules out and what workaround it would force (for example, excluding a type package that the chosen runtime APIs need). State any such cost in the explanation, and do not recommend an option whose letter can only be met by a costly workaround without saying so. Check each option's feasibility against the map's research: an option whose feasibility rests on an unverified fact says so in its explanation and is never the recommendation when a known-feasible option exists, and an option research shows blocked is not offered. Every premise in a question agrees with the map's research and resolutions: cite the ticket it rests on, and never state an absence or limit they contradict. Highlighting does not select or submit an answer.

A question is only as good as its weakest option, because the user decides by comparing them. Before saving a round, check each question:

- **Every option is a real choice.** Offer only options a reasonable person could pick for this project, and be able to say when each would be right. An option nobody would pick ("removed entirely, leaving no trace") makes the recommendation look forced and hides the real alternative. Two real options beat three with a straw man.
- **Options are parallel.** Keep labels similar in length and form, and put detail in the explanation, not in the recommended label. When the recommended option is the longest and most careful label, the layout argues for it.
- **Each option's consequence is stated.** For every option, the explanation says what the user gets and gives up. Omit the explanation only when the labels alone make the consequences obvious; short labels such as "Titles only" rarely do. Describe each option's case fairly. The explanation informs the choice; it does not argue for the recommendation.
- **Named cases are tested against every option.** List the cases the idea, notes, ticket or earlier answers name (for example a shared account, a deleted parent record or an existing record on upgrade), and check how each option handles each one. If an option handles a named case in a way the user might not expect, say so in this question. Otherwise a later round has to repair what the earlier answer silently broke.
- **Options respect settled answers.** Check every option against the map's resolutions. An option that would break one (for example letting the user pick a value a resolution says is always derived) is either removed or labelled as reopening that decision, naming it.
- **Earlier answers are quoted exactly.** When a question builds on a submitted answer, use its actual label or text. A paraphrase that shifts its meaning ("recomputes on each new map" for "record it at first use") makes the user doubt what they agreed to.
- **The question belongs to this ticket.** Read the other tickets' scopes and every pending round before asking. If another ticket owns the question, or a pending round already asks it, leave it there and mention it in your resolution if it matters here. The user answers all pending rounds side by side, so the same event asked in two tickets reads as a contradiction.
- **Questions in the round are independent.** For each pair of questions, ask whether any answer to one would change the other's options or recommendation. If it would, the dependent question waits for a later round. For example, what a new record holds usually depends on what the proposal that creates it shows.

Wait for the complete round's submitted answers before continuing dependent discussion. Read those answers from the durable records. In a direct repository conversation, retain the same questions and actual answers with the decision ticket using the local tracker convention. Let the interaction surface choose how the round is displayed.

Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier from the submitted answers and ask the next round. Round submission does not itself resolve the ticket. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.

Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), use the supplied background investigation capability to find it; don't ask the user for anything you could look up yourself. 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. The _decisions_ that pass the salience gate are the user's: put each to them and wait. The rest are yours.

The user steers in plain language and can end the interview at any point with a note on a submitted answer, such as "wrap up" or "accept the rest". Then ask no further rounds: resolve from the submitted answers plus your recommendations for every question still open, including branches you had not yet asked, and state each of those recommendations in the resolution. Record which decisions the user accepted wholesale as your recommendations rather than answered individually.

When the frontier is empty and the user's submitted answers settle every relevant branch, or the user has ended the interview, submit the resolution with links to those questions and answers: the settled decision in prose, and a separate one-line gist for the map. Both cover only this ticket; refer to other tickets rather than restating their decisions. Ask a targeted follow-up only for an unresolved ambiguity, contradiction, or scope choice; routine ticket completion needs no separate confirmation of understanding. The owning workflow records ticket resolution separately.