181 lines
6.7 KiB
Markdown
181 lines
6.7 KiB
Markdown
---
|
|
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.
|
|
|
|
<prd-template>
|
|
|
|
## 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 <role>, I want to <feature>, so that I can <benefit>
|
|
|
|
<user-story-example>
|
|
1. As a mobile banking customer, I want to see my account balance, so that I can make more informed decisions about my spending.
|
|
</user-story-example>
|
|
|
|
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.
|
|
|
|
</prd-template>
|
|
|
|
## 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
|