Define the product

Before a screen, one page that says what the product is for. It is a conversation with the user, and the page is its record: PRD.md at the root of their project, beside canvases/. The canvas shows it as a tab before the project's canvases and updates it when it is rewritten, so the user watches it fill in. The user can edit it on that tab too, so read the file again before rewriting it.

It is optional. Offer it when someone starts from an idea; never make it a gate. A user who wants screens now gets screens, and the PRD can come later.

---

1. Interview, do not fill a template

The user knows things you do not, and a template filled from a one-line idea is invented content that reads like decisions.

• Ask one or two questions at a time, in the user's language. Offer lettered options (A. B. C. and "or tell me") so a reply can be one letter, and say which you would pick and why.
• Problem before solution. Get these, in this order, before any feature:
  1. Who, specifically, has the problem. One person you could picture, not "users".
  2. What they do today instead, and what it costs them. A real moment beats a statistic.
  3. Why now, or why this person is the one to build it.
• Then the solution: the one thing it must do well, and what it will not do.
• Then success: how anyone would know it worked, as something observable.
• Push back once on a vague answer ("everyone", "it's faster", "an AI that...") with a sharper question. Do not push back twice; write TBD.
• Stop when every section in §2 is 🟢 or explicitly 🔴 TBD. For most ideas that is five to eight exchanges. Do not drag it out to be thorough.

Write the file after the first answers, not at the end. Update it as each answer lands, so the tab is the conversation's running state.

---

2. What PRD.md holds

Keep it to one screen of reading.

# <Product name>

> One sentence: who it is for, what it lets them do, and why that matters.

## Problem
The person, the moment, what they do today, what it costs them.

## Users
Primary user, and anyone secondary. What each one is trying to get done.

## Value
*Why this over what they do now, and the one thing it must do well.*

## Scope
**In:** the few things the first version does.

**Out:** what it deliberately does not, and why.

## Success
*Observable signs it worked: a behaviour, a number, a thing a user says.*

## Screens
| Screen | Purpose | States |
|---|---|---|
| Home | ... | empty, loaded, error |

The flows between them, one line each.

## Open questions
- ... (TBD, who decides)

## Riskiest assumptions
1. ... and the cheapest way to test it.

Keep a status line per section while it is being written (🟢 settled, 🟡 partial, 🔴 TBD) and drop the markers once it is settled. Never fill a 🔴 with a plausible guess: a TBD is honest and tells the user what is left to decide, a guess gets built.

The Screens table is what sp-new-ui-mock designs from. Each row is a board sp-new-ui-mock can make, and States are the unhappy states it must design too: empty, loading, error, the longest plausible content.

---

3. Close it out

1. Red-team it. Name the assumptions that would sink the product if wrong, and the cheapest test of each. Write them under Riskiest assumptions. Keep it short and specific.
2. Read the one-sentence summary back to the user and ask if it is right.
3. Offer the next step: mock the first screen from the Screens table with sp-new-ui-mock, or clone a reference app with sp-clone-prototype when the user named one as "like X".

---

Revisiting it

When a design decision on the canvas changes scope, a screen or an answer, update PRD.md in the same turn and say what changed. When the user asks for screens and a PRD.md exists, read it first: its users, copy and states ground the mock.