Interrogate

Generation amplifies ambiguity: a vague request produces a confident, plausible, wrong implementation. This skill resolves the ambiguity before any code exists, where a question costs seconds instead of a review round.

Rules of engagement

• Ask in small batches (1–3 questions), hardest first. Never a wall of 15.
• Prefer concrete failure scenarios over abstract preferences: "the worker dies after the row is claimed but before the job is queued — what should the user see?" beats "how should we handle errors?"
• After each answer, update the open-branch list and say what it closed.
• Offer a recommendation with each question when you have one — for open decisions, as numbered options with the recommendation marked and its reason stated. The user should mostly be choosing, not authoring.
• Start from whatever material exists (notes, threads, a spike) and ask only what it doesn't answer; arriving with nothing is equally fine.
• Push back once when an answer creates a contradiction with an earlier one or with the codebase. Twice is nagging; note it and move on.

Question categories — walk all that apply

1. Scope edges — what is explicitly OUT? What is the smallest version that would still be worth shipping?
2. State and concurrency — what are the states, who moves them, and what happens when two movers race? (Cancel-vs-fire, retry-vs-supersede, double-click, two tabs.)
3. Time — timezones, DST, clock skew, "what does 'tomorrow' mean", staleness cutoffs, how late is too late.
4. Failure policy — for each external call: retry, fail loudly, or degrade? Who is told, in what words?
5. Data lifecycle — creation, mutation ownership, deletion. What happens to dependent rows when the parent goes away?
6. Permissions — who can trigger this? What about admins acting as users?
7. Observability — how will you know it worked in production? What log line or metric proves it?
8. Blast radius — what existing behavior could this change accidentally?

Stop condition

Stop when the remaining open branches would not change what gets built — list them as "deferred" with an owner. Do not stop because the user got tired; compress instead: batch the remaining branches with your recommended answer for each and ask for line-item vetoes.

Exit artifact

A decision list, in the conversation or appended to the spec:

DECIDED:
- Cancel wins over a concurrent fire; user sees "canceled" not "published".
- Posts >2h late fail loudly rather than publish. Retry is manual.
DEFERRED:
- Rescheduling UI (owner: next iteration; cancel+recreate is the workaround).

Terms coined during the session (state names, verbs) go into CONTEXT.md while they're fresh.