A user arrives with one sentence and leaves with a PRD the rest of the flow can
build on. The interview is a coverage walk: the PRD's own sections are the
plan, you visit every one, and nothing lands in the document that was neither
asked about nor visibly assumed. You visit them all before you ask anything —
/start asks exactly once.
The idea comes to you
The user's idea is attached to this instruction when the project captured one.
Read it as the brief — it is what the user actually asked for, in their words.
It is not a file: it is attached or it is absent. When absent, open with one
ask_question: "What are you building?" — a few concrete example options,
free text welcome. The answer is the brief. Getting the brief is not the
interview: it is the only thing that may precede the one form below.
The coverage walk
Walk the PRD's own sections, in its own order:
- Problem — who hurts, how, today.
- Actors — who uses the system, at product altitude.
- Journey & stories — what each actor does, end to end.
- Product decisions — policy choices: sign-in, notifications, integrations.
- Phasing — what ships first; a thin vertical slice makes the best MVP.
- Out of scope — what this project is explicitly not.
The walk is planning, not turns: you take it silently, in full, before the user sees a single question. For each section:
- Consult the organization skill first. A question its defaults answer is never asked — record the default as a plain Product Decision instead. A section fully covered by defaults and the brief needs nothing.
- Note the questions whose answers would change the document, and only those. Skip what the brief already answers.
Ask once
Then ask ONE ask_questions form — the grilling skill owns the question
mechanics — carrying the questions the walk noted, and write the PRD from the
answers. There is no second form: the next thing the user sees after answering
is their document.
- The bar, not the budget. Ask only what changes the PRD. Three questions is a good form; padding one out to the cap is an interrogation.
- More questions than a form holds → ask those whose answers change the
document most, and treat every one left behind exactly as the skip valve
does: your recommended answer, tagged
*assumed*.
Depth is opt-in: after generating, the user can go deeper in chat on any feature.
The skip valve
At any point the user may say "just generate" / "skip". Stop asking
immediately: fill every remaining decision with your recommended answer and tag
each one *assumed* where it lands in the PRD. An assumption the user can see
is a decision they can overturn; a silent one is an invention.
Write the PRD
Write specs/requirements/prd.md — always that full path. Load this skill's
reference references/prd-contract.md (via loadSkillReference) and follow it
exactly: it defines every section, the story numbering rules, and what the PRD
deliberately excludes. Per-feature depth goes to
specs/requirements/features/<slug>.md, never into the PRD body.
Anything genuinely unanswerable now goes to Open Questions — mark it, never guess it.
Running /start again
specs/requirements/prd.md already exists → this is an amendment, never a
rewrite: append new stories with fresh numbers (story numbers are permanent),
update only the sections the change touches, and leave the user's hand-edits
alone. Regenerate from scratch only when the user explicitly asks, and confirm
before overwriting. One form here too — a scoped change earns fewer questions
than a cold start, never more.
Where this stops
/start ends at the PRD. Design, components, and tasks are later steps with
their own skills and gates. Close with a one-paragraph summary of the decisions
taken (calling out every *assumed* one), then point the user at the next
step: review specs/requirements/prd.md, then run /design — open questions
must be answered or explicitly deferred before design can proceed.