grilling

Interview the user relentlessly until you reach a shared understanding. Map this as a decision 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 the whole frontier in one round: number each question and give your recommended answer. Number sequentially across the whole interview rather than restarting each round, so an answer naming Q2 points at one question. Then wait for the user's answers before the next round. Where this session engaged a deputy through /deputy and has not dismissed it, what is put to the user here goes to the deputy instead, as ROUNDS.md says, and the deputy's reply is printed verbatim under a one-line header before anything acts on it; otherwise it goes to the user as written.

Format a round like so:

❓ **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>

Word each question so "yes" accepts your recommended answer.

A presented question is locked: title, body, options and recommendation stay word-for-word as first shown, and only the user's own feedback can reshape or retire it. Presenting is therefore a commitment — put a question to the user only once you are sure nothing still running can change what you'd ask.

Every message of the interview ends with its questions: newly ready ones in full in the format above, under fresh numbers, then one line naming the numbers still open from earlier messages. The lock is what makes that line safe — a number keeps pointing at the exact text first shown, so scrolling to it beats reprinting it. Anything above the questions — findings, replies to the user's remarks — is commentary.

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. A question whose answer depends on another question still open in this round belongs to a later round, not this one.

When the user's answers carry a question or remark of their own, answer it before opening the next round; never let a new round bury the reply.

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 with a fresh context window to find it — in the background (Claude Code: do not use run_in_background: false) — rather than asking the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite — ask the rest of the frontier now, and hold every question the report could reword. A question is downstream of an exploration when its body, options, or recommendation would read differently depending on what comes back — a body that mentions the pending result has declared itself downstream; when in doubt, hold it, since a held question costs one round and a locked question overtaken by facts costs the user's trust in every question still on the table. When an exploration reports, give its findings one short paragraph and fold them into the questions it unblocks; a finding that bears on a locked question goes in that paragraph as commentary for the user to weigh, and the question stands as asked. When the fact lives in external docs or specs rather than the environment, propose /research instead. The decisions are the user's: put each to them and wait.

Closing

The session is done when the frontier is empty: every branch of the decision tree visited, nothing left silently assumed. Where another skill invoked this interview, hand back to it there — the close belongs to whichever skill owns the flow. Otherwise close with a single sentence stating that shared understanding is reached — no summary — then recommend the next step as a flow pointer (the message's final paragraph, a blockquote in full italics opening Next: — or Next steps: over one bullet per pointer — each pointer naming its skill the way this skill was itself invoked, same prefix and namespace, and ending in a one-clause rationale after an em dash) — a choice, rendering the step whose condition holds — and wait for the user's go-ahead:

• /spec (user-invoked) when the outcome is a feature worth a written contract — in this session, since it synthesizes the interview; implementation then starts fresh.
• /implement (user-invoked) directly when it's a small fix that needs no spec — in this session, which already carries the context.
• /prototype when an unresolved question survived the interview and needs empirical evidence — in this session, feeding the verdict back here.
• /research when an unresolved question needs facts from primary sources — it runs in the background while this session continues.
• /questionnaire (user-invoked) when an unresolved question needs facts only another person holds — in this session, drafting the document; the answers come back on the recipient's clock.

Where this session engaged a deputy through /deputy and has not dismissed it, a choice is put to the deputy as ROUNDS.md says and rendered as the one step it chose, any other closing is rendered as written, and each rendered step that names a skill is then taken: one marked (user-invoked) by notifying the user where the harness has a tool for it and waiting for them to type it, any other by invoking it, notifying nobody.