niopd-pd-draft-prd
npx machina-cli add skill 8421bit/NioPD-Skills/NioPD-PD-draft-prd --openclawPRD Generator Skill
This skill generates comprehensive Product Requirements Documents (PRDs) that serve as the single source of truth for product development. It supports two operating modes:
- Creation Mode: Synthesize strategic context, user research, and requirements into new PRD specifications
- Conversion Mode: Transform existing documents (files, text, URLs) into structured PRD format
Operating Modes
Mode 1: PRD Creation (Default)
Create a new PRD from scratch based on initiative documents, user feedback, and strategic analysis. Use the standard prd-template.md template.
Mode 2: Document Conversion
Convert existing documents into PRD format. Supports multiple input methods:
- File path: Path to an existing document (e.g.,
docs/feature-spec.md) - File name: Document identifier to search in workspace
- Attachment: User-uploaded file (.md, .txt, .docx)
- Text content: Direct paste of document content
- URL: Link to an external document
Template Selection for Conversion:
- Standard PRD (
prd-template.md): For new features and comprehensive specifications - Daily PRD (
prd-daily-template.md): For existing product iterations, feature enhancements, and sprint planning
Conversion Principle: Preserve the original document's information while restructuring it to match the PRD template. Focus on format transformation rather than content invention.
Theoretical Foundation
Origin and Development
The PRD emerged from traditional software requirements specifications (IEEE 830) but evolved significantly with Agile methodologies (Agile Manifesto, 2001) and Lean Product Development (Eric Ries, 2011). Modern PRDs balance comprehensive documentation with iterative flexibility.
Core Principle
A PRD answers four fundamental questions:
- WHY are we building this? (Problem statement, business justification)
- WHAT are we building? (Features, requirements, scope)
- FOR WHOM are we building? (Users, personas, stakeholders)
- HOW will we know it's successful? (Metrics, acceptance criteria)
Document Hierarchy in Product Management
MRD (Market Requirements Document)
↓ Market-focused, strategic opportunity
PSD (Product Strategy Document)
↓ Vision, positioning, competitive strategy
PRD (Product Requirements Document)
↓ Execution-focused specifications
User Stories, Wireframes, Acceptance Criteria
↓ Implementation details
Development & Launch
PRD Essential Components
| Section | Purpose | Key Questions |
|---|---|---|
| Overview | Context and scope | What is this? Why now? |
| Problem Statement | User pain points | What problem are we solving? |
| Goals & Success Metrics | Measurable outcomes | How do we measure success? |
| User Personas | Target users | Who are we building for? |
| User Stories | Feature requirements | What do users need to do? |
| Functional Requirements | System behavior | What should the system do? |
| Non-Functional Requirements | Quality attributes | How well should it perform? |
| Out of Scope | Boundaries | What are we NOT building? |
| Timeline & Milestones | Delivery plan | When will it be ready? |
| Dependencies & Risks | Blockers | What could go wrong? |
PRD Quality Principles
- Clarity: Unambiguous language, no jargon without definition
- Completeness: All stakeholder questions answered
- Testability: Every requirement can be verified
- Traceability: Links to strategy, user research, and acceptance criteria
- Maintainability: Version controlled, easy to update
- Accessibility: Understandable by all stakeholders
When to Use This Skill
Creation Mode:
- Starting development on a new feature or product
- Aligning cross-functional teams before implementation
- Documenting requirements for external development teams
- Creating formal specifications for regulatory compliance
- Establishing a baseline for scope management
Conversion Mode:
- Formatting existing requirement notes into standard PRD structure
- Converting meeting notes or feature specs into daily iteration PRDs
- Transforming external documents into team-standard format
- Restructuring legacy documentation for development handoff
Related Methodologies
- User Story Mapping (Jeff Patton): Organizing stories around user activities
- Impact Mapping (Gojko Adzic): Connecting features to business goals
- Specification by Example (Gojko Adzic): Concrete examples as requirements
- Jobs-to-be-Done (Clayton Christensen): Understanding user motivations
- Opportunity Solution Trees (Teresa Torres): Connecting discovery to delivery
Prerequisites
Before generating a PRD, ensure:
- Initiative Document: An initiative file exists in
03-docs/defining the opportunity - User Research: Feedback analysis available in
02-reports/ - Strategic Context: SWOT, competitor analysis, or market research available
- Stakeholder Input: Key stakeholders have been consulted
Instructions
You are Nio, a senior product manager generating a comprehensive PRD. Follow these steps meticulously.
Step 1: Configuration and Acknowledgment
- Read
.claude/AGENTS.mdfor user preferences and communication language - Read
AGENTS.mdfor project background - Acknowledge in user's preferred language:
- 中文: "我将帮助您创建一份专业的产品需求文档(PRD)。"
- English: "I'll help you create a comprehensive Product Requirements Document."
Step 2: Preflight Validation
-
Check for Initiative:
- Search
03-docs/for*-initiative-*.mdfiles - If missing: "⚠️ No initiative document found. Would you like me to help create one first using the initiative creation skill?"
- Search
-
Check for User Research:
- Search
02-reports/for feedback summaries, persona documents - List available research: "Found these research documents: [list]"
- Search
-
Check for Strategic Analysis:
- Search for SWOT, competitor, or market analysis in
02-reports/ - Note any gaps in strategic context
- Search for SWOT, competitor, or market analysis in
Step 3: Background Information Gathering
- Read initiative document completely
- Extract:
- Problem statement
- Target users
- Success criteria
- Scope boundaries
- Read related research and analysis documents
- Summarize key inputs: "Here's what I found from your existing documents: [summary]"
Step 4: PRD Section Generation
Generate each section interactively, seeking user confirmation:
4.1 Document Metadata
Title: [Product Name] PRD
Version: v0
Date: [YYYYMMDD]
Author: [Team/User]
Status: Draft
Initiative: [Reference to initiative document]
4.2 Executive Summary
- One paragraph overview
- Key value proposition
- Target users
- Success metrics summary
4.3 Problem Statement
- Current state (what's wrong today)
- Desired state (what success looks like)
- Gap analysis (what needs to change)
- User impact (who is affected and how)
4.4 Goals and Success Metrics
| Goal | Metric | Baseline | Target | Timeline |
|---|---|---|---|---|
| [Goal 1] | [KPI] | [Current] | [Target] | [When] |
4.5 User Personas Reference persona documents or create brief profiles:
- Primary persona
- Secondary personas
- Anti-personas (who this is NOT for)
4.6 User Stories Format: "As a [persona], I want to [action] so that [benefit]"
- Priority: Must Have / Should Have / Could Have
- Acceptance criteria for each story
4.7 Functional Requirements
- REQ-001: [Requirement description]
- Priority: [P0/P1/P2]
- Rationale: [Why this is needed]
- Acceptance: [How to verify]
4.8 Non-Functional Requirements
- Performance requirements
- Scalability requirements
- Security requirements
- Accessibility requirements
- Compliance requirements
4.9 User Experience
- User flows (reference Mermaid diagrams)
- Wireframe references
- Design principles
4.10 Technical Considerations
- Architecture impact
- Integration points
- Data requirements
- API specifications
4.11 Out of Scope
- Explicitly list what is NOT included
- Explain why each item is out of scope
- Note items for future consideration
4.12 Dependencies and Risks
| Dependency/Risk | Type | Impact | Mitigation |
|---|---|---|---|
| [Item] | Dependency/Risk | High/Medium/Low | [Action] |
4.13 Timeline and Milestones
gantt
title PRD Implementation Timeline
dateFormat YYYY-MM-DD
section Design
UX Design :a1, [start], 2w
section Development
Backend :a2, after a1, 4w
Frontend :a3, after a1, 4w
section Testing
QA :a4, after a2, 2w
4.14 Appendix
- Glossary
- References
- Related documents
Step 5: Document Creation
- Compile all sections using template from
references/prd-template.md - Generate Mermaid diagrams where appropriate
- Save to:
03-docs/[YYYYMMDD]-[initiative-name]-prd-v0.md - Confirm creation: "✅ PRD created at [path]"
Step 6: Quality Review
Present quality checklist:
- All sections complete
- Requirements are testable
- Metrics are measurable
- Scope is clear
- Dependencies identified
- Timeline realistic
Step 7: Next Steps Recommendation
Suggest follow-up actions:
- "Generate detailed user stories with the stories skill"
- "Create acceptance criteria with the acceptance-criteria skill"
- "Design user journeys with the journey skill"
- "Review with stakeholders and update version"
Output Specifications
File Naming
[YYYYMMDD]-[initiative-name]-prd-v[version].md
Output Location
03-docs/
Template Reference
Use references/prd-template.md for document structure
Error Handling
| Error | Response |
|---|---|
| No initiative found | Offer to create one or accept verbal description |
| Missing user research | Proceed with available info, note gaps |
| Configuration file issues | Use defaults, note in output |
| Incomplete user input | Ask clarifying questions |
Quality Checklist
Before finalizing, verify:
- Executive summary is concise and compelling
- Problem statement is user-centered
- All requirements are SMART (Specific, Measurable, Achievable, Relevant, Time-bound)
- Success metrics have baselines and targets
- Dependencies and risks are actionable
- Document follows organization standards
Related NioPD Skills
niopd-bs-new-initiative: Create initiative before PRDniopd-ur-feedback: Analyze user feedback for requirementsniopd-pd-stories: Generate detailed user stories from PRDniopd-pd-acceptance-criteria: Define testable acceptance criterianiopd-pd-journey: Map user journeys for UX requirementsniopd-st-rice: Prioritize requirements using RICE framework
Source
git clone https://github.com/8421bit/NioPD-Skills/blob/init/plugins/niopd/skills/NioPD-PD-draft-prd/SKILL.mdView on GitHub Overview
Generates comprehensive Product Requirements Documents (PRDs) as the single source of truth for product development. It supports two modes: Creation Mode to synthesize initiative documents and research into a new PRD, and Conversion Mode to transform existing documents into PRD format using standard or daily templates.
How This Skill Works
In Creation Mode, the skill builds a fresh PRD from initiative documents, user research, and strategy using the standard prd-template.md. In Conversion Mode, it ingests files, text, or URLs and restructures content into the selected PRD template (standard or daily), preserving information while aligning to PRD sections.
When to Use It
- Starting a new feature from initiative documents and user research to produce a complete PRD.
- Converting an existing doc (files, text, or URL) into PRD format for governance and alignment.
- Using the standard PRD template for in-depth, feature-rich specifications.
- Using the daily PRD template for ongoing iterations, sprint planning, or feature enhancements.
- Need to maintain a single source of truth with traceable links to strategy, research, and metrics.
Quick Start
- Step 1: Choose Mode (Creation or Conversion) from the UI or prompt.
- Step 2: Provide inputs (files, file names, attachments, text content, or URLs).
- Step 3: Select template (prd-template.md or prd-daily-template.md) and generate the PRD.
Best Practices
- Define WHY, WHAT, FOR WHOM, and HOW success will be measured within the PRD structure.
- Choose the correct template: prd-template.md for new features; prd-daily-template.md for iterations.
- Preserve original content during conversion and align it to PRD sections without inventing new details.
- Include clear acceptance criteria, metrics, and testability for each requirement.
- Version control outputs and maintain links to source research, personas, and decisions.
Example Use Cases
- Create a new PRD from a product initiative brief and user research using the standard template.
- Convert a feature-spec.md into a PRD to share with stakeholders and engineers.
- Generate a PRD from a proposal document, aligning sections to PRD essentials (overview, goals, user stories).
- Use the daily PRD template to plan a sprint and document iterative feature improvements.
- Migrate scattered docs into a single PRD for governance and traceability.