PRD Generator

Generate Product Requirements Documents through a structured workflow that identifies reusable components from your existing component library.

Workflow Overview

Input Requirements → Component Breakdown → Library Matching → Human Review → Generate PRD (DOCX)

Execute these 4 steps in order. Each step requires completion before proceeding.

Step 1: Component/Module Breakdown

Parse input requirements (text, markdown, PDF, or DOCX) and decompose into discrete components:

1. Extract functional requirements — What the system must do
2. Extract non-functional requirements — Performance, security, scalability constraints
3. Identify modules — Group related functionality into logical components
4. Map dependencies — Note which components depend on others

Present breakdown to user as a structured list before proceeding.

Output format:

## Component Breakdown

### Core Modules
1. [Module Name]: [Brief description]
   - Functional requirements: [List]
   - Non-functional requirements: [List]
   - Dependencies: [List]

### Supporting Modules
[Same structure]

### Integration Points
[External systems, APIs, data sources]

Step 2: Match Against the Component Library

Read references/component-library.md and match each identified component against available pre-built solutions.

If references/component-library.md does not exist, this is a fresh install and the catalog has not been filled in yet. Tell the user, point them at references/component-library.template.md for the expected structure, and either wait for them to supply it or continue with every component marked as custom development.

Matching criteria:

• Direct match: Component functionality aligns with library component
• Partial match: Some functionality covered, customization needed
• No match: Requires custom development

Walk the library tier by tier, in the order it defines them, and check each component's Match when line against the requirement. Proprietary frameworks come first — they typically cover the most surface area per match — then shared/standard components, then any domain-specific integrations that apply to this project's vertical.

Step 3: Human Review (Reuse vs. Build)

Present findings for user verification:

## Component Analysis: Reuse vs. Build

### ✅ Reusable from the Component Library
| Component | Library Match | Coverage | Notes |
|-----------|--------------|----------|-------|
| [Name] | [Library component] | Full/Partial | [Any customization needed] |

### 🔨 Requires Custom Development
| Component | Reason | Complexity | Notes |
|-----------|--------|------------|-------|
| [Name] | [Why no match] | Low/Med/High | [Technical considerations] |

### ⚠️ Needs Your Input
[Any ambiguous cases or decisions needed]

Wait for user confirmation before proceeding. User may:

• Approve recommendations
• Override specific decisions
• Provide additional context for ambiguous components

Step 4: Generate PRD Document

After user approval, generate the final PRD:

1. Read template from assets/prd-template.md
2. Populate all sections using gathered information:
   • Sections 1-8: From input requirements
   • Section 9 (Implementation Details): From component analysis
3. Generate DOCX using the docx skill

DOCX Generation

Create the final document with the docx skill (Claude chat) or python-docx (Claude Code):

from docx import Document
from docx.shared import Inches, Pt
from docx.enum.text import WD_ALIGN_PARAGRAPH

doc = Document()
# Follow docx skill patterns for professional formatting

Formatting requirements:

• Title: 18pt, bold, centered
• Section headers: 14pt, bold
• Body text: 11pt
• Tables: With header row styling
• Page margins: 1 inch

Save and hand over per the Environment section below.

Environment

This skill runs in both Claude chat and Claude Code. A few things differ:

Pick based on where you're running: if /mnt/user-data/ exists, you're in Claude chat. A path the user names explicitly always wins over either default. Never overwrite an existing file without saying so first.

Integration with requirements-analyzer

This skill pairs with requirements-analyzer:

1. requirements-analyzer — Extracts structured requirements from client materials
2. prd-generator — Transforms requirements into PRD with implementation details

Typical flow:

User: "Here are the project materials from the client"
→ Use requirements-analyzer

User: "Now let's create the PRD"
→ Use prd-generator (this skill)

Key Principles

• Never skip human review — Step 3 is mandatory
• Be specific about matches — Cite exact library components, not vague references
• Flag ambiguity — When uncertain about a match, ask rather than assume
• Preserve user decisions — If user overrides a recommendation, honor it in the final PRD