prdlisted

# prd — What to build, and for whom The document that later specs point back to. Its job is not to describe features in detail — that is what a spec does, one feature at a time. Its job is to name the **capabilities**, give each a stable id, and draw the boundary around what this product is not. Capability ids are the mechanical output — in whatever prefix this project uses: a spec cites the capability it serves, and a capability with no spec after six months is either dead or a lie. ## Where it goes `<docs>/PRD.md` — summarised into `.steering/product.md`. `<docs>` is the `- Docs:` line in `.steering/tech.md`, which defaults to `docs/`. In a multi-repo product it points at the shared documentation repository instead, so product-level truth has one home rather than one per repo. ## Steps 1. **Read `northstar`** if it exists. Every capability must move a named lever; a capability that moves none is one to argue about now rather than after it is built. 2. **Name the users** — not personas with invented names, but the distinct jobs people bring to the product. Two users with the same job are one user. 3. **Write capabilities, not features.** A capability is what the user can now do; a feature is how. A capability id survives three redesigns of the screen that delivers it; a feature id does not. 4. **Give each a stable id and the lever it serves.** Ids never change, even when the wording does. 5. **Write the boundary.** What this product deliberately does not do, and where