product-requirements-documentlisted

# Product Requirements Document (PRD) ## Why this exists A PRD fails in one of two directions, almost never in the middle. Too vague ("support bulk export") and engineering ends up inventing the edge cases themselves, inconsistently, mid-build. Too prescriptive (specifying exact pixel layouts or implementation details with no hard constraint requiring it) and it strips design and engineering of the room to find a better solution than the one the PM happened to imagine. The other constant failure: no acceptance criteria, so "done" becomes a subjective argument at the worst possible time — right before ship. This skill is a structure for landing in the middle: precise about outcomes, silent about implementation unless there's a real constraint. ## Process ### 1. State the user problem, tied to evidence Name the user, the job they're trying to do, and what's broken today — and cite where this came from rather than asserting it from gut feel. If this repo's other skills produced the evidence (a `call-insight-extraction` summary, a `feedback-triage-scoring` ranking, a `usage-trend-narration` finding, an `internal-signal-scouting` pulse, or an approved BRD), link to it directly. A PRD without traceable evidence invites exactly the debate it's trying to prevent. ### 2. State the goal and how you'll know it worked If a BRD exists, this should trace directly to one of its objectives. Either way, this needs to be a measurable outcome, distinct from a list of features — "reduce