Frontier Interview

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

1. 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.
2. 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.
3. 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:

1. Kick off fetches for any facts that would unblock questions.
2. 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.
3. Accept answers in whatever form they come: full, partial, "all recommended", or pushback that reframes a question.
4. 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.
5. Repeat until the frontier is empty.