create-prdlisted

# Create PRD ## Trigger Use when the user asks for requirements, acceptance criteria, user stories, product scope, success metrics, or a feature spec. ## When To Use - After discovery is clear enough to define behaviour. - Before UX, system mapping, technical design, or engineering planning. - When scope needs to be testable. ## What Makes This Document Useful A PRD earns its place by being **testable and bounded**. Two rules carry most of that weight: - **Every requirement must be verifiable.** If nobody can tell whether it is met, it is a wish. "The page should be fast" is a wish; "the product list renders within 1.5s at the 75th percentile on a 4G connection" is a requirement. - **Requirements describe outcomes, not implementations.** Naming the database table in a PRD forecloses a design decision that has not been made yet. The exception is a genuine product constraint ("must remain usable offline"), which belongs here precisely because it is not the engineer's call. ## Inputs Inspected - Discovery brief and product profile from the same initiative. - Existing issues, docs, designs, and the user's prompt. - Current behaviour in the codebase where the feature already partly exists. ## Workflow 1. Inspect discovery context, product profile, existing docs, issues and designs, and current behaviour before defining anything. 2. State the **problem** and who has it, then the **goals**, then **non-goals**. 3. Describe the **users** as roles with distinct