Get the FREE Ultimate OpenClaw Setup Guide →

niopd-pd-draft-prd

npx machina-cli add skill 8421bit/NioPD-Skills/NioPD-PD-draft-prd --openclaw
Files (1)
SKILL.md
10.9 KB

PRD 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:

  1. Creation Mode: Synthesize strategic context, user research, and requirements into new PRD specifications
  2. 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:

  1. WHY are we building this? (Problem statement, business justification)
  2. WHAT are we building? (Features, requirements, scope)
  3. FOR WHOM are we building? (Users, personas, stakeholders)
  4. 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

SectionPurposeKey Questions
OverviewContext and scopeWhat is this? Why now?
Problem StatementUser pain pointsWhat problem are we solving?
Goals & Success MetricsMeasurable outcomesHow do we measure success?
User PersonasTarget usersWho are we building for?
User StoriesFeature requirementsWhat do users need to do?
Functional RequirementsSystem behaviorWhat should the system do?
Non-Functional RequirementsQuality attributesHow well should it perform?
Out of ScopeBoundariesWhat are we NOT building?
Timeline & MilestonesDelivery planWhen will it be ready?
Dependencies & RisksBlockersWhat could go wrong?

PRD Quality Principles

  1. Clarity: Unambiguous language, no jargon without definition
  2. Completeness: All stakeholder questions answered
  3. Testability: Every requirement can be verified
  4. Traceability: Links to strategy, user research, and acceptance criteria
  5. Maintainability: Version controlled, easy to update
  6. 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:

  1. Initiative Document: An initiative file exists in 03-docs/ defining the opportunity
  2. User Research: Feedback analysis available in 02-reports/
  3. Strategic Context: SWOT, competitor analysis, or market research available
  4. 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

  1. Read .claude/AGENTS.md for user preferences and communication language
  2. Read AGENTS.md for project background
  3. Acknowledge in user's preferred language:
    • 中文: "我将帮助您创建一份专业的产品需求文档(PRD)。"
    • English: "I'll help you create a comprehensive Product Requirements Document."

Step 2: Preflight Validation

  1. Check for Initiative:

    • Search 03-docs/ for *-initiative-*.md files
    • If missing: "⚠️ No initiative document found. Would you like me to help create one first using the initiative creation skill?"
  2. Check for User Research:

    • Search 02-reports/ for feedback summaries, persona documents
    • List available research: "Found these research documents: [list]"
  3. Check for Strategic Analysis:

    • Search for SWOT, competitor, or market analysis in 02-reports/
    • Note any gaps in strategic context

Step 3: Background Information Gathering

  1. Read initiative document completely
  2. Extract:
    • Problem statement
    • Target users
    • Success criteria
    • Scope boundaries
  3. Read related research and analysis documents
  4. 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

GoalMetricBaselineTargetTimeline
[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/RiskTypeImpactMitigation
[Item]Dependency/RiskHigh/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

  1. Compile all sections using template from references/prd-template.md
  2. Generate Mermaid diagrams where appropriate
  3. Save to: 03-docs/[YYYYMMDD]-[initiative-name]-prd-v0.md
  4. 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:

  1. "Generate detailed user stories with the stories skill"
  2. "Create acceptance criteria with the acceptance-criteria skill"
  3. "Design user journeys with the journey skill"
  4. "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

ErrorResponse
No initiative foundOffer to create one or accept verbal description
Missing user researchProceed with available info, note gaps
Configuration file issuesUse defaults, note in output
Incomplete user inputAsk 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 PRD
  • niopd-ur-feedback: Analyze user feedback for requirements
  • niopd-pd-stories: Generate detailed user stories from PRD
  • niopd-pd-acceptance-criteria: Define testable acceptance criteria
  • niopd-pd-journey: Map user journeys for UX requirements
  • niopd-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

  1. Step 1: Choose Mode (Creation or Conversion) from the UI or prompt.
  2. Step 2: Provide inputs (files, file names, attachments, text content, or URLs).
  3. 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.

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers