description: Create a pure PM PRD through user interviews and requirement refinement. The primary output is a PRD file for downstream PM stages; a GitHub issue is optional only if explicitly requested.
3. Interview the user relentlessly about every aspect of the problem until you reach a shared understanding. Walk down each branch of the product decision tree, resolving scope, behavior, and acceptance expectations one-by-one.
If a research brief exists, use it to inform problem framing, success metrics, functional requirements, non functional requirements, and risks. Do not copy competitor solutions mechanically.
Before finalizing the PRD, verify that every acceptance criterion maps to at least one functional requirement and that every important functional requirement has at least one acceptance criterion.
**Optional secondary output:** If and only if the user explicitly requests it, the PRD may also be submitted as a GitHub issue after the file has been written.
Summarize relevant market, competitor, user, or regulatory insights when they materially influence the PRD. If no research was needed, write `N/A` with a brief reason.
For each user story or feature, define the specific, testable conditions that must be met for the feature to be considered complete and working correctly.
- Every criterion must be measurable, testable, and rejectable
- Every criterion must be implementation independent
- Always use `Given / When / Then`
- Focus on observable behavior rather than implementation details
List meaningful product edge cases based on context, such as empty input, invalid input, duplicates, retries, timeouts, concurrency, partial completion, permission conflicts, and large payloads when relevant.
## Non Functional Requirements
List only the NFRs that matter for this feature and explain them in measurable product terms when possible.
- Examples may include performance, availability, scalability, security, privacy, auditability, accessibility, retention, or compliance
- Do not force irrelevant NFR categories into the PRD
## Risks
List product, operational, compliance, or adoption risks that could affect delivery or outcome.
List unresolved product questions that must be answered before implementation or release. If there are no open questions, write `N/A` with a brief reason.
The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints when needed for scope clarity, but must not derive or prescribe implementation design from internal code structure.
