--- name: write-a-prd 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. --- This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary. 1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions. 2. Clarify the target users, current workflow, pain points, constraints, desired outcomes, and release boundaries. 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. 4. Once you have a complete understanding of the problem, goals, scope, and user-visible behavior, use the template below to write the PRD file. 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. **Announce at start:** "I'm using the write-a-prd skill to create the PRD." **Primary inputs:** - `docs/brainstorm/{date}-{feature}-design.md` - Optional `docs/research/{date}-{topic}.md` **Context:** This should usually run after brainstorming has produced the product direction document. **Save plans to:** `docs/prd/{date}-{feature}.md` - (User preferences for plan location override this default) **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. ## Research Inputs 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. ## Problem From the user's perspective, the problem they are currently facing and why it matters now. ## Goals Specific outcomes this feature must achieve for the user and the business. ## Non Goals Explicitly list what this PRD does not attempt to solve. ## Scope Describe the in-scope behaviors, flows, and boundaries for this release. ## Success Metrics List measurable outcomes that can be evaluated after delivery. ## User Stories From the user's perspective, a detailed, numbered list of user stories. Each user story should follow this format: 1. As a , I want to , so that I can 1. As a mobile banking customer, I want to see my account balance, so that I can make more informed decisions about my spending. This list of user stories should be very detailed, covering all aspects of the functionality. ## Functional Requirements Define user-visible behavior and contractual product behavior only. - Focus on what the system must do from the user's or consumer's perspective - Do not include architecture, module design, schema design, API path design, or implementation details - Tailor requirements to the feature context instead of using a fixed boilerplate list - Include error handling, retry behavior, permissions, idempotency, or observability only when the user context makes them materially necessary ## Acceptance Criteria 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 - Every criterion must be observable and unambiguous - Every criterion must map to at least one functional requirement ### Coverage Check For each PRD, explicitly check whether requirements are needed for: - Error handling - Retry behavior - Idempotency - Permissions and roles - Auditability and observability - Performance and latency - Availability and reliability - Scalability and concurrency If the feature is API-based, async, bulk, or integration-heavy, also check for: - Status and outcome behavior - Required response fields - Time constraints - Duplicate prevention behavior - Partial failure behavior ## Edge Cases 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. ## Assumptions List assumptions this PRD depends on being true. If there are no material assumptions, write `N/A` with a brief reason. ## Dependencies List dependencies on teams, systems, policies, vendors, or external events. If there are no material dependencies, write `N/A` with a brief reason. ## Open Questions 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. ## Guardrails This is a pure PM skill. Do: - Define the problem, value, scope, user-visible behavior, and release boundaries - Define measurable success metrics - Define context-appropriate functional requirements and non functional requirements - Define acceptance criteria in `Given / When / Then` - Ensure PRD minimum completeness before handoff Do not: - Design architecture - Design modules or internal system boundaries - Design API paths, handlers, schemas, or databases - Choose technologies or implementation patterns - Break work into engineering tasks - Write pseudocode or code 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. ## Minimum Completeness Gate The PRD must contain: - Problem - Goals - Non Goals - Scope - Success Metrics - User Stories - Functional Requirements - Acceptance Criteria - Edge Cases - Non Functional Requirements - Risks Add these when relevant: - Error handling - Idempotency - Observability