Loading...
Loading...
Use when generating a Product Requirements Document from a high-level idea, feature request, or product vision — covers discovery questions, structured PRD drafting, section-by-section review, and transition to implementation planning
npx skill4agent add pixel-process-ug/superkit-agents prd-generation| # | Question | Why It Matters |
|---|---|---|
| 1 | What problem does this solve? | Anchors the entire PRD |
| 2 | Who are the target users? (personas, roles) | Shapes user stories |
| 3 | How are users currently solving this? | Identifies competitive landscape |
| 4 | What is the impact of NOT solving this? | Justifies priority |
| # | Question | Why It Matters |
|---|---|---|
| 5 | What does success look like? (specific metrics) | Defines success metrics |
| 6 | What are must-have vs nice-to-have features? | Sets priority tiers |
| 7 | What are the explicit non-goals? | Prevents scope creep |
| 8 | Are there existing solutions to learn from? | Informs design decisions |
| # | Question | Why It Matters |
|---|---|---|
| 9 | What is the timeline? Any hard deadlines? | Scopes release plan |
| 10 | What technical constraints exist? | Narrows solution space |
| 11 | What resources are available? | Sets realistic expectations |
| 12 | Are there compliance or regulatory requirements? | Identifies non-functional reqs |
prd-writer# [Product/Feature Name] — Product Requirements Document
## 1. Overview
One paragraph summarizing what this is and why it matters.
## 2. Problem Statement
- Current situation
- Pain points
- Impact of not solving
## 3. Goals & Non-Goals
### Goals
- [ ] Goal 1 (measurable)
- [ ] Goal 2 (measurable)
### Non-Goals
- Explicitly NOT doing X
- Explicitly NOT doing Y
## 4. User Stories
As a [persona], I want to [action], so that [benefit].
## 5. Functional Requirements
### FR-1: [Requirement Name]
- Description
- Acceptance criteria
- Priority (P0/P1/P2)
## 6. Non-Functional Requirements
- Performance: [specific targets]
- Security: [requirements]
- Accessibility: [standards]
- Scalability: [expectations]
## 7. Technical Constraints
- Platform/stack requirements
- Integration dependencies
- Data requirements
## 8. Success Metrics
| Metric | Current | Target | How to Measure |
|--------|---------|--------|----------------|
## 9. Timeline & Milestones
| Phase | Description | Target Date |
|-------|-------------|-------------|
## 10. Open Questions
- [ ] Question 1
- [ ] Question 2
## 11. Appendix
References, mockups, related documents| Priority | Meaning | Rule |
|---|---|---|
| P0 | Must-have for launch | Without this, the product does not ship |
| P1 | Important, ship soon after launch | Significant value but not blocking |
| P2 | Nice-to-have | Enhances experience, can wait |
docs/prds/YYYY-MM-DD-<feature>.mddocs(prd): add PRD for <feature>brainstormingspec-writing| User Intent | Next Skill | Rationale |
|---|---|---|
| "Let's build this" | | Explore approaches then plan |
| "Write the specs" | | Break PRD into JTBD specs |
| "Just save it" | None | PRD is the deliverable |
| "Get estimates" | | Break into estimable tasks |
| Mistake | Why It Is Wrong | What To Do Instead |
|---|---|---|
| Skipping discovery and jumping to draft | Produces assumptions-based PRD | Always complete Phase 1 first |
| Goals without metrics | Cannot measure success | Every goal needs a number |
| Missing non-goals | Scope creep guaranteed | Explicitly list what is out of scope |
| User stories without acceptance criteria | Untestable requirements | Add Given/When/Then to each story |
| Generic success metrics ("improve UX") | Unmeasurable | Use specific numbers: "reduce load time to <2s" |
| Presenting entire PRD at once for review | User overwhelmed, gives superficial approval | Present section by section |
| Copying competitor features verbatim | Misses actual user needs | Focus on user problems, not solutions |
| Skill | Relationship |
|---|---|
| Upstream: explores ideas before PRD; downstream: explores implementation after PRD |
| Downstream: PRD provides high-level requirements; specs detail them with JTBD |
| Downstream: plan references PRD requirements for task breakdown |
| Downstream: breaks PRD into estimable work items |
| Parallel: PRD informs what documentation is needed |
| Downstream: acceptance criteria from PRD feed test definitions |
Problem: Users cannot find relevant search results in the dashboard.
Users: Data analysts (primary), team leads (secondary).
Current workaround: Export to Excel and use Ctrl+F.
Impact of not solving: 30min/day wasted per analyst (team of 12).
Success metric: Reduce average search time from 5min to <30s.
Must-have: Full-text search across all dashboard widgets.
Non-goal: Advanced boolean query syntax (P2, not launch).
Timeline: 6 weeks to MVP.
Constraint: Must work with existing Elasticsearch cluster.