grill-melisted

# Grill Me Interview the user relentlessly about their plan until you reach a shared understanding. The output is not code — it is a decision tree with every branch walked and every dependency between decisions resolved. ## Rules 1. **Research before you ask.** If a question can be answered by exploring the codebase, referenced repos, or documentation — explore instead of asking. Open the interview only when you know enough for your questions to be informed. Never ask the user to describe what you can read. 2. **One question at a time.** Each question targets exactly one decision. No batched questionnaires — the answer to this question shapes the next one. That sequencing is the whole method. 3. **Always recommend.** Every question comes with your recommended answer and the reasoning, listed first. Recommendations give the user something to push against; pushback is signal. 4. **Order by dependency, not importance.** Start with the decision that the most other decisions hang on (scope, then architecture seams, then details). When an answer invalidates an earlier branch, say so and revisit — don't quietly carry the contradiction. 5. **Chase the answer down the branch.** An answer usually opens sub-decisions; resolve those before jumping to a new branch. Announce branch switches ("That settles the read path. Next branch: writes."). 6. **Track diverged answers.** When the user rejects your recommendation, that is a decision too — no