You need several decisions from the user, and some depend on others. Two failure modes to avoid: dripping questions one at a time (slow, and the user never sees the shape of the problem) and dumping every question at once (later questions are premature — their right framing depends on earlier answers). Instead, walk the frontier of the decision tree.
The model
- Map the decision tree. Before asking anything, list every decision the task needs. For each one, note its prerequisites: the earlier answers or facts that must be settled before the question can be asked well.
- Separate facts from decisions. A fact is anything answerable by reading the repo, the docs, or the web — package manager, existing conventions, what a library supports. A decision requires the user's judgment, taste, or authority. Facts are never the user's job. Fetch them yourself — with background sub-agents where available so fetching doesn't stall the interview — and let only the questions downstream of an unfetched fact wait.
- The frontier is every unasked decision whose prerequisites are all settled. That is what you ask, and all of it, each round.
The loop
Each round:
- Kick off fetches for any facts that would unblock questions.
- Ask the entire current frontier in one message: numbered questions, each with a recommended answer and a one-line rationale — "1. <question>? Recommend: <answer> — <why>." Make "accept all recommendations" a valid single reply.
- Accept answers in whatever form they come: full, partial, "all recommended", or pushback that reframes a question.
- Recompute the frontier. New answers may unlock downstream decisions, reshape how a pending question should be asked, or eliminate it entirely. If an answer invalidates a question you already asked but the user skipped, withdraw it explicitly rather than leaving it dangling.
- Repeat until the frontier is empty.
Rules
- Every question carries a recommendation. Never present a menu without a position.
- Never ask the user for a fact you could fetch.
- Never re-ask a settled decision. Carry answers forward verbatim; if you must restate one, quote it.
- Record the outcome where the invoking skill directs (a config doc, a plan, a proposal). The interview itself is not the artifact.
One-question-at-a-time opt-out
Offer the opt-out and honor it immediately: some users prefer strictly one question per round, and they are not wrong — field experience shows that questions which look independent often turn out coupled once an answer lands. Also invoke this judgment yourself: when the coupling risk in a round is high, shrink the round rather than batch blindly. Batching is an optimization, not the contract; the contract is that every question arrives with its prerequisites settled.