Workflow
- •Understand the surface request — Read the user's initial ask and identify what's stated vs. what's assumed
- •Explore the problem space — Ask probing questions about the areas below, one at a time
- •Answer from codebase first — If a question can be answered by exploring the codebase, explore the codebase instead of asking the user
- •Provide a recommended answer with every question — For each question, include your best-guess recommendation so the user can confirm, correct, or refine rather than starting from scratch
- •Answer with recommendation — Ask questions (one or multiple per invocation), where each question includes a recommended answer.
- •Converge on shared understanding — Stop when you have enough context to define what to build, why, and what's out of scope
Question Areas
Probe these areas (adapt order based on the request):
- •Underlying problem — What's the real need behind the request? Why now?
- •Success criteria — How will we know this is done? What does "working" look like?
- •Edge cases and failure modes — What happens when input is invalid, network fails, user cancels?
- •Dependencies and constraints — What existing systems, APIs, or patterns must this integrate with?
- •Risks and trade-offs — What are we choosing NOT to do? What could go wrong?
- •Prioritization and MVP scope — What's the minimum that delivers value? What can be deferred?
Example
User request: "I want to add a notifications feature"
code
Question 1 [underlying problem]: "What problem are notifications solving — are users missing important events, or is this about engagement/retention? → User: "Users aren't seeing when their orders ship." Question 2 [scope]: "Should this be in-app notifications only, or also email/push? → User: "In-app for now, email later." Question 3 [edge cases]: "What happens when a user has 500+ unread notifications — do we paginate, auto-archive old ones, or cap the count? → User: "Auto-archive after 30 days, paginate." Question 4 [integration]: "I see the app uses WebSockets for real-time chat already. Should notifications use the same WebSocket connection, or poll? → User: "Yes, reuse WebSockets." Question 5 [success criteria]: "So the MVP is: in-app notifications via WebSocket when order status changes, paginated list with 30-day auto-archive. Correct?" → User: "Yes, that's it."
Notice: Question 4 was informed by exploring the codebase rather than asking blindly.
Constraints
- •NEVER propose solutions before understanding the problem — ask first, build later
- •NEVER skip edge case exploration — surface at least 2 edge cases per feature
- •NEVER ask questions the codebase can answer — explore code first
- •NEVER ask questions without a recommended answer — every question in an invocation must include one
- •ALWAYS provide a recommended answer with each question so the user can confirm or correct
- •ALWAYS summarize the agreed requirements before declaring the interview complete