Frank
c379d16858
The ask tool's recommended flag only labels option 0; the reply always names the selected options, so 'the user's single Enter accepts it' overclaimed a default-accept mechanic that does not exist. Stated truthfully: the label invites one-glance acceptance, the reply is self-documenting.
3.6 KiB
name, description
| name | description |
|---|---|
| grilling | 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. |
Grilling
Interview the user relentlessly until nothing is silently assumed and you reach a shared understanding. Map this as a design tree: every decision branches into the decisions that hang off it.
A decision is frontier when it can be asked now, without an answer you haven't heard yet. The interview is done when the frontier is empty: every branch of the tree visited.
Rounds
Work the tree in rounds: ask the whole frontier at once, then wait. A decision whose answer hangs on an open question or an unfetched fact joins a later round.
Ask each closed decision - anything expressible as 2–5 options - through the ask tool:
- One artefact per question, counted before sending. Name the artefact each question decides; two names means two questions. Shared plumbing (an endpoint, a service, a build step) still leaves two artefacts.
- Recommended answer first, marked
recommended: 0, which labels it "(Recommended)" for one-glance acceptance. Every reply names what was picked, so the record is unambiguous. - Options quote the user's goal. Their words, their stated goal, ground the wording; your todo text and table rows stay out of it.
- Your own idea is welcome: it gets its own recommended question. Attach it to its own question, so it rides there on its merits.
multi: truefor pick-many,headerfor the branch chip,previewwhen the decision needs code or config in front of the user.
Open narrative - "walk me through the deploy flow" - has no options to offer; ask it as prose in chat. Without an ask tool the whole round degrades to text: ❓ **Q1 — title**: body, then ➡️ recommendation, phrased so one bare "yes" accepts every recommendation.
Dialog mechanics, the gotchas no doc confesses: the dialog is exclusive, so dispatch scouts before the ask call in the same message and expect their results between rounds. Esc cancels the whole run with no closing turn; the ledger below is what survives it.
The ledger
The tree lives in the todo list while the interview runs, so the user watches it fall:
- One task per decision, filed under the phase for its branch;
via: <parent decision>in the task text carries the edge. pendingis the frontier;blockwith a one-line reason waits on a fact or an open decision;doneis settled. Unblock the moment the dependency settles.
Write local://grilling-state.md at the end of every round: the tree, each decision's verdict and one-line rationale. It is the durable copy of the interview; keep it current so an Esc costs one round.
Facts are yours, decisions are theirs
- Environment facts (filesystem, repo, live config): dispatch a scout per fact-cluster, batched into one
taskcall, before the round'sask. Cluster tightly; doing so keeps each scout more aware of possible adjacencies. - Outside-world facts: call
web_searchdirectly, do not delegate to a subagent. - Cheap lookups:
read/grepinline. - The main session is where questions happen: every spawn carries the exact facts to return, and comes back into the next round.
Definition of Done
The frontier is empty and nothing sits blocked. Distil the ledger into a brief: one line per decision, verdict plus rationale, grouped by branch. Put it in chat, then one closing ask: "Proceed on this brief?" Nothing executes before that yes. After it, fold the brief into the project's knowledge base, or a log markdown file, wherever the project keeps its decisions.