prdlisted

A PRD answers **what we are building, for whom, and why** — and just as importantly, **what we are not building**. It is the scope contract for an initiative. Design briefs and backend briefs sit downstream of it and decide *how*; this document decides *what* and *whether*. ## Example prompts - "Write a PRD for the billing portal" - "I need to nail down the scope before we start building the invite flow" - "What's in scope and what's not for the analytics rebuild?" - "We decided to drop SSO from v1 — update the PRD" - "Product spec for a usage-based pricing tier" ## Step 1: Mode detection Do this before anything else — before interviewing, before sizing, before reading the template. The two modes share almost nothing, and the cost of guessing wrong is high: writing a new PRD for something an existing one already covers splits the scope contract in two, and nobody knows which half counts. 1. List `docs/prd/`. Read the title and `## Summary` of each PRD found — filenames go stale once scope drifts, so do not judge by name alone. 2. **Does one of them cover this initiative?** - **Yes** → [Amend mode](#amend-mode). This includes small asks: a one-line change to a live PRD is an amendment, not a new document, and amending is cheap. - **No** → [Create mode](#create-mode). 3. If a PRD is *adjacent* but not the same initiative — same customers, overlapping vocabulary, a dependency between them — stay in Create mode, but note the relationship. Section 3 of Create mode cover