prdlisted

<!-- managed-by: harness-setup --> ## When to Trigger - "Write a PRD for..." - "Document the requirements for this feature" - "What should this feature do — write it up" - "PRD for the [X] feature" ## Overview A Product Requirements Document captures **what** a feature must do and **why**, from the user/business perspective — before anyone commits to a technical design. It is the input to a TRD (technical requirements), not a replacement for one: keep implementation detail out of it. A PRD is warranted when a feature is non-trivial enough that "what we're building and why" needs to be agreed before "how" — new user-facing capability, a change affecting multiple teams, or anything where the cost of building the wrong thing is high. ## Workflow ### 1 — Gather the essentials before writing Do not invent answers to these — ask if they aren't already clear from the conversation: - Who is this for (user/persona), and what problem do they have today? - What does success look like — a measurable outcome, not just "it works"? - What's explicitly out of scope for this version? ### 2 — Determine where it lives Store PRDs in `docs/prd/`, one file per feature: `docs/prd/<feature-slug>.md`. If that directory doesn't exist, create it. ### 3 — Write the PRD Use this format: ```markdown # PRD — <Feature Name> **Status:** Draft | Approved | Superseded by <link> **Date:** YYYY-MM-DD **Owner:** <who is accountable for this feature's outcome> ## Problem What problem does this solv