Interview me

Interview Me

Overview

The cheapest bug is the one never written because the right question was asked first. This skill replaces assumption-stacking with a structured interview: ask targeted questions in small batches, feed each answer into the next round, and stop only when you could write the spec's acceptance criteria without inventing anything. It front-loads the conversation that otherwise happens as review rework.

When to Use

• The request is one or two sentences for something clearly bigger ("add offline support")
• Requirements contradict each other or the existing app's behavior
• Multiple plausible interpretations exist and picking wrong is expensive
• Before spec-driven-development when the input idea is fuzzy
• A stakeholder says "you know what I mean" — you don't

Skip when: The task is small and unambiguous (rename, obvious bug fix), or a spec with acceptance criteria already exists — go build. Don't interview to avoid starting.

Core Process

Step 1: State What You Think You Know

1. Write down the current understanding and confidence level before asking anything:

## Understanding: offline support for tasks
- Users can view cached tasks offline — confident (stated)
- Users can CREATE tasks offline — assumed, not stated
- Conflict resolution strategy — unknown
- Sync trigger (foreground only? WorkManager?) — unknown
Confidence: ~40%

Unknowns and assumptions become the question list. If nothing lands in those rows, you didn't need the interview.

Step 2: Ask in Small, Targeted Batches

2. 3–5 questions per round, highest-leverage first. One decision per question, concrete options over open prompts:

1. When a task is edited offline on two devices, which wins — last write,
   or surface a conflict to the user?
2. Should offline creation work, or is offline read-only for v1?
3. Sync on app-open only, or background sync via WorkManager?
4. What happens to offline changes if the user logs out?

3. Question rules:
   • Ask about behavior users see, not implementation ("which wins?", not "OT or CRDT?")
   • Offer defaults: "I'd propose last-write-wins for v1 — acceptable?" — easy to confirm, easy to correct
   • Surface Android realities the stakeholder may not know: background limits (Doze, see android-background-work), permission prompts, Play policy constraints (see shipping-and-launch)
   • Never re-ask what an earlier answer already settled

Step 3: Feed Answers Back and Iterate

4. After each round, update the understanding document — restate answers in your own words, mark resolved items, and let new questions emerge from the answers:

Resolved: offline read + create for v1; last-write-wins; sync on app-open.
New question raised by "last-write-wins": is silent data loss on conflict
acceptable, or should we log it for support?
Confidence: ~80%

Step 4: Stop at ~95% and Convert

5. Exit when you could write every acceptance criterion without inventing. Perfect certainty is not the bar — the remaining 5% gets written down as explicit assumptions:

Assumptions (proceeding unless corrected):
- Conflicts are rare enough that silent last-write-wins is acceptable for v1

6. Hand off to spec-driven-development with the understanding document as input. The interview output is the spec's raw material, not a substitute for the spec.

Common Rationalizations

Shortcut	Why It Fails
"I'll make reasonable assumptions and note them"	Ten stacked "reasonable" assumptions produce an unreasonable result. Assumptions are for the last 5%, not the first 50%.
"Asking questions makes me look incapable"	Building the wrong thing looks worse. Good questions demonstrate understanding of the problem space.
"The stakeholder is busy, I shouldn't bother them"	Five minutes of their time now beats a week of rework and a harder conversation later.
"I'll figure it out as I build"	Structural decisions (offline model, conflict strategy) are cheap to change in conversation and expensive to change in code.
"One big questionnaire is more efficient"	Twenty questions at once get skimmed. Small batches get real answers, and answers change the next questions.

Red Flags

• Implementation started while the understanding doc still lists "unknown" on core behavior
• Questions about implementation details instead of user-visible behavior
• The same question asked twice because answers weren't recorded
• Zero assumptions documented on a task that had ambiguity (they were made silently)
• A twenty-question wall dumped in one message
• "Interviewing" continuing past the point where acceptance criteria are writable — stalling, not clarifying

Verification

• Understanding document exists with resolved / assumed / unknown items
• Every core user-visible behavior is resolved or explicitly assumed (no silent gaps)
• Remaining assumptions are written down and shared, not private
• Acceptance criteria can be drafted without inventing behavior
• Android platform constraints (background, permissions, Play policy) surfaced where relevant
• Output handed to spec-driven-development (or the task was re-scoped/rejected)