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

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)