interview-melisted

# Interview Me Close the gap between what was asked and what is actually wanted — *before* you build on it. A cross-cutting clarification technique: grill a goal, a requirement, or a plan — the method is the same. The cheapest bug to fix is the one never built. ## When to use - A request is vague ("add auth", "make it faster") or has more than one reasonable reading. - Assumptions are piling up before a plan or feature. - **Skip** when the task is trivial or already fully specified — interrogating wastes turns. - **Skipping never licenses a silent decision.** If the request leaves an open point you resolve yourself — a "maybe X?", a "not sure if I need that" — state the decision and your one-line reason in your reply so the user can redirect: decide-and-state, never decide-and-bury. "It's cheap to build" is the rationalization to catch — the cost is not the build, it is the user discovering you decided for them. ## Procedure **1. Scan before you ask.** Read the request, then explore the codebase and context for what is already decided: conventions, similar features, libraries in use, naming. Never ask what the code already answers. **2. Ask ONE question at a time.** For each open decision, in one short message: - state what you found ("you already use Zod for validation"), - name the decision, - recommend a default with one line of reasoning. Prefer yes/no or a small multiple choice. Wait for the answer before the next question. **3. Use each answer to prune.** An ans