interview

# Interview one feature The product pass (`start`) has written the product page, the product-wide page and a stub per feature. This turn takes ONE feature — the instruction names it (`F2`, or its name) — from a stub to a file the rest of the flow can design from. Everything else stays as it is. Read before you ask: `specs/requirements/prd.md`, `product-wide.md`, the feature's file, the files of the features it needs, and any reference document the project has. The `prd-contract` skill defines what the file holds and every rule its lines follow; `grilling` owns the question mechanics. ## The spine, then the file 1. **Ask the spine — two or three questions, one `ask_questions` form.** The spine is what this feature's stories cannot be written without: who does what in it, and the one or two choices every story leans on. Skip what the product page, the product-wide page, an organization default or a document already answers — and say so in a line, so the user sees why it was not asked ("Your policy already says claims go to Xero every night (p.9), so I won't ask about timing."). 2. **Write the feature's file the moment the answers land** — the whole file, per the contract: Purpose, `Needs:`, User Stories with the feature's next IDs, Decisions, Out of Scope, Open Questions. A line a document states carries its source and is not assumed. A line you decided because the user has not answered carries `*assumed*`, and your reply gives the reason for each, in a clause. 3. **Stop there.** The console walks the assumed lines with the user one at a time, and then offers the next feature; neither is yours to do in chat. Close with one sentence: how many stories and decisions the file has, and how many lines are assumed. **Writing is not converging, but the walk is the round.** Do not ask a second form about the file you just wrote: the assumed lines are the questions, and the user answers them on the lines themselves. ## When the interview cannot go on A **blocking question** is one whose answer changes every story of the feature — Xero or ADP for a payroll export. Do not guess it and do not write stories on top of a guess. Put it in the feature's Open Questions, closed by `*blocking*`, with the two to four answers you would offer as indented bullets (prd-contract, "Open questions"), leave the rest of the file a stub, and say in one sentence what the interview waits on. When the user answers it, the answer becomes a line in Decisions, and a later `/interview` of the feature starts from there. ## Check facts yourself A fact the world holds — what an external service's API allows, a published limit, a regulation's retention period — you check with the tools you have (web search, the organization's registered resources), without asking first. Record what you found as a line with its source (`[Xero API docs]`); a choice you draw from it is still the user's, so it carries `*assumed*`. Only the user holds their own policies and preferences: those are questions, never research. ## Stay in the feature The feature's file is the one you write. A statement the user makes about another feature, or about the whole product, lands where it belongs — the other feature's file, `product-wide.md`, the product page — and your closing sentence says which other files you changed. A need on a feature that is still a stub is fine: record it (`Needs: F5.`) and move on.