prd-generator

SKILL.md

PRD Generator

Purpose

Transform a rough product idea into a comprehensive, AI-ready Product Requirements Document (PDF) through targeted questions and structured output.

Execution Logic

Check $ARGUMENTS first to determine execution mode:

If $ARGUMENTS is empty or not provided:

Respond with:
"prd-generator loaded, describe your product idea"

Then wait for the user to provide their product concept in the next message.

If $ARGUMENTS contains content:

Proceed immediately to Task Execution (skip the "loaded" message).

Task Execution

1. MANDATORY: Read Reference Files FIRST

BLOCKING REQUIREMENT — DO NOT SKIP THIS STEP

Before doing ANYTHING else, use the Read tool to read:

./references/prd_template.md

This template defines the exact structure your PRD must follow. DO NOT PROCEED to Step 2 until you have read this file.

2. Skip Business Context

This skill intentionally DOES NOT read FOUNDER_CONTEXT.md. PRDs are standalone documents that should contain all necessary context within them.

3. Analyze Initial Input

From the user's initial description, extract what's available:

Product name or working title

Core problem being solved

Target users/audience

Key features mentioned

Technical preferences (if any)

Constraints or requirements (if any)

4. Ask Clarifying Questions

Use AskUserQuestion tool to gather missing information. Ask up to 7 questions maximum, but fewer is better — stop as soon as you have enough to build a comprehensive PRD.

Question Bank (priority order):

#
Question
Why it matters
Skip if...

1
Who is the primary user? What's their role and technical level?
Shapes all UX decisions and feature complexity
User persona is clearly described

2
What's the core problem this solves? What happens if users don't have this?
Defines the value proposition and success metrics
Problem statement is explicit

3
What are the 3-5 must-have features for launch (P0)?
Prevents scope creep, focuses MVP
Features are already listed with clear priority

4
What technology preferences or constraints exist? (Language, framework, hosting)
Determines technical architecture section
Tech stack is specified

5
Are there any integrations required? (Auth providers, APIs, third-party services)
Identifies dependencies and integration complexity
No external services mentioned or user says standalone

6
What does success look like? Any specific metrics to track?
Defines goals and success metrics section
Metrics or goals are already stated

7
Any design preferences or existing brand guidelines to follow?
Shapes UI/UX requirements section
Design is flexible or already described

Question strategy:

Ask 2-4 questions per batch using AskUserQuestion

If the first batch answers provide enough detail, stop asking

Never ask more than 7 questions total

Group related questions when possible

5. Generate the PRD

Using the template structure from ./references/prd_template.md, create a complete PRD:

Fill every applicable section from the template

Be specific — vague requirements produce vague code

Write acceptance criteria for every feature — make them testable

Prioritize ruthlessly — P0 should be 30-40% of features

The "Implementation Notes for AI" section is mandatory — this is what makes it AI-ready

6. Save and Convert to PDF

Step 6a: Create output folder

mkdir -p ./prd_outputs/[Project Name]/

Use the product name with spaces, e.g., ./prd_outputs/Churn Prevention Tool/

Step 6b: Save markdown file
Write the PRD content to:

./prd_outputs/[Project Name]/[project_name]_PRD.md

Use snake_case for the filename, e.g., churn_prevention_tool_PRD.md

Step 6c: Convert to PDF
Run:

npx md-to-pdf "./prd_outputs/[Project Name]/[project_name]_PRD.md"

This creates [project_name]_PRD.pdf in the same folder.

7. Confirm Output

Tell the user:

Where the PDF is saved (full path)

Where the markdown source is saved

Brief summary of what's in the PRD

Writing Rules

Core Rules

Every feature MUST have testable acceptance criteria

Use specific numbers, not vague terms ("loads in <2s" not "loads quickly")

P0 features should be 30-40% of total features — if everything is P0, nothing is

Data models must include field types and relationships

API specs must include request/response examples

PRD-Specific Rules

Executive summary: 3-5 sentences maximum

Problem statement: Must include current state, pain points, and business impact

User personas: Maximum 3 primary personas — more creates confusion

Tech architecture: Describe data flow in plain English — AI tools interpret this better than complex diagrams

Implementation Notes for AI section: This is mandatory, never skip it

Format Rules

Use markdown headers consistently (# for title, ## for sections, ### for subsections)

Use tables for structured data (metrics, data models, API specs)

Use code blocks for JSON examples and technical specs

Use checkboxes for acceptance criteria

Output Format

The PRD follows the structure in ./references/prd_template.md. Here's a condensed example:

# TaskFlow — Product Requirements Document

**Version:** 1.0
**Date:** 2024-01-15
**Author:** PRD Generator
**Status:** Draft

## Executive Summary
TaskFlow is a task management tool for remote engineering teams...

## Problem Statement
**Current state:** Teams use disconnected tools...
**Pain points:**
1. Context switching between tools
2. No visibility into team workload
3. Async communication gaps

**Impact:** 5+ hours/week lost per engineer...

## Goals & Success Metrics
| Goal | Metric | Target | Measurement |
|------|--------|--------|-------------|
| Reduce context switching | Tool switches/day | < 10 | Analytics |

## User Personas
### Engineering Manager
- **Role:** Manages 5-10 engineers
- **Goals:** Visibility into sprint progress...

## Functional Requirements

### FR-001: Task Creation
**Description:** Users can create tasks with title, description, assignee, and due date.

**User story:** As an engineer, I want to create tasks quickly so that I capture work items without friction.

**Acceptance criteria:**
- [ ] Task creation completes in < 500ms
- [ ] Title field is required, minimum 3 characters
- [ ] Due date defaults to end of current sprint

**Priority:** P0

...

## Implementation Notes for AI

### Build Order
1. Database schema (PostgreSQL)
2. API endpoints (Express.js)
3. Frontend components (React)
4. Auth integration (Clerk)

### Libraries to Use
- Prisma for ORM — type-safe, great DX
- TanStack Query for data fetching — handles caching
- Tailwind CSS for styling — utility-first, fast iteration

### Critical Implementation Details
- All dates stored as UTC, converted to user timezone on display
- Use optimistic updates for task status changes
- Implement soft deletes for all user-generated content

References

This file MUST be read using the Read tool before task execution (see Step 1):

File
Purpose

./references/prd_template.md
Complete PRD structure with all 15 sections, format examples, and usage notes

Why this matters: The template ensures every PRD follows a consistent, comprehensive structure that AI coding tools can parse and implement. Skipping the template results in incomplete PRDs that miss critical sections.

Quality Checklist (Self-Verification)

Pre-Execution Check

 I read ./references/prd_template.md before starting

 I have the template structure in context

Question Check

 I asked 7 or fewer questions total

 I only asked questions where information was genuinely missing

 Questions were batched (2-4 per AskUserQuestion call)

PRD Content Check

 Executive summary is 3-5 sentences

 Every feature has acceptance criteria (checkboxes)

 P0 features are ~30-40% of total (not everything)

 Data models include field types

 API specs include request/response examples

 "Implementation Notes for AI" section is complete

Output Check

 Markdown file saved to ./prd_outputs/[Project Name]/

 PDF generated via npx md-to-pdf

 User informed of file locations

If ANY check fails → fix before completing.

Defaults & Assumptions

Use these unless the user specifies otherwise:

Document version: 1.0

Status: Draft

Author: PRD Generator

Tech stack: Modern web (React + Node.js + PostgreSQL) unless specified

Hosting: Cloud-native (Vercel/Railway/AWS) unless specified

Auth: Third-party (Clerk/Auth0) unless building custom

Priority split: ~35% P0, ~40% P1, ~25% P2

User personas: Maximum 3 unless complexity demands more

API style: REST unless GraphQL is specified

Document any assumptions made in the PRD output.