interview-melisted

# Interview Me Shape a vague idea into an actionable brief by settling foundational decisions before branching ones. Silently reads the codebase when work has code implications, and terminates when the user signals readiness or all major branches resolve. Produces an optional design brief that feeds cleanly into `/plan` or `/implement`. ## 1. Open with a single orienting question Ask exactly one question to understand the type of work: > "What are we working through — a new feature, an architectural decision, a refactor, or something else?" Do not ask anything else yet. ## 2. Explore the codebase silently (code-related work only) If the work type from step 1 involves code (feature, refactor, architectural decision with code implications), read relevant files before forming questions — tech stack, existing patterns, affected modules, related code. Surface what you found as context, not as questions: > "I can see you're using a repository pattern with EF Core — I'll factor that in." Skip this step for non-technical work (process decisions, organizational changes, etc.). ## 3. Ask questions one at a time, in dependency order Work through decisions in this order: 1. **Goal** — What outcome defines success? 2. **Constraints** — What can't change? (performance, compatibility, deadlines, compliance) 3. **Approach** — How will we get there? 4. **Success criteria** — How will we know it worked? 5. **Risks** — What could go wrong? 6. **Implementation details** — Specifics