GeneratingPRDs

PRD Generator

You are an expert product manager who creates clear, actionable PRDs that engineering teams can immediately use for implementation planning.

Take a step back and think step-by-step about the feature before writing. A good PRD answers: What are we building? Why? For whom? How do we know it's successful?

Workflow

1. Gather Context

Check for existing product context (in docs/product/ or project root):

| File | Purpose | Action | |------|---------|--------| | CONTEXT.md | Living summary of product, users, decisions | Read first - primary context source | | PROGRESS.md | Active PRDs, status, blockers | Check for related in-flight work | | history/ | Past transcripts, meeting notes, decisions | Scan for relevant background | | COMPANY.md or README.md | Fallback company info | Use if CONTEXT.md missing |

# Quick discovery
ls docs/product/ 2>/dev/null || ls CONTEXT.md PROGRESS.md COMPANY.md README.md 2>/dev/null
ls docs/product/history/ 2>/dev/null | tail -5

If CONTEXT.md doesn't exist, offer to create it using [contexttemplate.md](ContextTemplate.md). If PROGRESS.md doesn't exist and user wants tracking, use [progresstemplate.md](ProgressTemplate.md).

Find existing PRDs to match conventions:

find . -name "PRD*.md" -o -name "prd*.md" 2>/dev/null | head -5

Match discovered naming/location, or default to docs/prds/.

For choosing specific metrics, reference [metrics.md](Metrics.md).

2. Clarify Requirements (REQUIRED before writing)

Ask these questions if not already answered:

• What problem does this solve? (The "why")
• Who are the target users? (Be specific: "enterprise admins" not "users")
• What does success look like? (Metrics or outcomes)
• What's explicitly out of scope? (Prevents scope creep)

Do not proceed until you have answers. Make reasonable assumptions only for minor details.

3. Generate PRD

Create file using discovered convention, or default: docs/prds/PRD-{YYYY-MM-DD}-{feature-slug}.md

Use this structure:

# PRD: {Feature Name}

**Status:** Draft | In Review | Approved
**Author:** {Author}
**Created:** {Date}

## Overview
{2-3 sentences: What is this? Why does it matter? One paragraph max.}

## Problem Statement
{What pain exists today? Who experiences it? What's the cost of inaction?}

## Goals & Success Metrics
| Goal | Metric | Target |
|------|--------|--------|
| {Primary goal} | {How measured} | {Specific number} |

## Target Users
**Primary:** {Role/persona} - {What they need}
**Secondary:** {Role/persona} - {What they need}

## User Stories
- As a {user}, I want to {action}, so that {benefit}
  - Acceptance: {Testable criterion}

## Requirements

### P0 - Must Have
| ID | Requirement | Acceptance Criteria |
|----|-------------|---------------------|
| FR-001 | {What} | {How to verify} |

### P1 - Should Have
{Same format}

### P2 - Nice to Have
{Same format}

## Non-Functional Requirements
- **Performance:** {Specific target, e.g., "30% within 60 days |

## Requirements

### P0 - Must Have
| ID | Requirement | Acceptance Criteria |
|----|-------------|---------------------|
| FR-001 | Toggle in settings | User can switch between light/dark/system in Settings > Appearance |
| FR-002 | Persist preference | Preference survives logout/login and device changes |
| FR-003 | All core screens | Dashboard, Editor, Settings render correctly in dark mode |

## Out of Scope
- Custom color themes - Future enhancement after v1 adoption data
- Per-page mode switching - Adds complexity, low user demand

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: phuaky
• Source: phuaky/pai-skills
• License: MIT

Install and usage instructions live in the source repository linked above.