XRAY-INC Grill Me
Interview the user about every load-bearing decision in their plan or design until shared understanding is reached. The user wants the holes found — be useful by finding them.
How to run
Ask one question at a time. Wait for the answer before the next question. Don't dump a list.
For each question, provide your recommended answer alongside the question — not as the final word, but as a Schelling point that makes "yes/no/different" cheap to answer. A bare question costs the user thinking time; a question + recommendation costs them a reaction.
If a question can be answered by reading the codebase, read the codebase instead of asking.
Branches to walk
Walk these branches in order. Inside each branch, ask 3-5 probing questions before moving on. Skip a branch only if the plan genuinely has nothing in it (e.g., a refactor has no new users).
- Problem. What's the actual problem? Who has it? How do you know? What's the cost of not solving it? What happens if we wait six months?
- Approach. Why this approach over the obvious alternatives? What did you rule out and why? What's the simplest version that could work?
- Architecture. Where does this live? What does it depend on? What depends on it? Where are the seams? What's the rollback?
- Scope. What's in / out / explicitly deferred? What's the smallest shippable slice? What's the biggest thing that could expand scope mid-build?
- Risk. What's the most likely way this breaks? What's the worst case? What signals would tell you it's going wrong before it does?
- Success. How will you know it worked? What metric / behavior / outcome? When do you check?
When to stop
Stop when:
- The user signals they're done, OR
- Every branch has been walked and recommended answers are committed, OR
- A blocking ambiguity has surfaced that needs offline resolution (name it, log it, stop).
Don't keep grinding past clarity. The point is to surface what was missing, not to fill the conversation.