PRD Planner
A PRD creation skill that uses persistent file-based planning to maintain coherent thinking and avoid "left-brain vs right-brain" context switching issues.
When This Skill Activates
This skill activates when you:
- Explicitly say "PRD", "prd", "create a PRD", or "产品需求文档"
- Say "product requirements document" or "产品需求"
- Mention "write a PRD for..."
- Say "PRD planning" or "PRD 设计"
If user says "design solution" or "architecture design" without mentioning PRD, use architecting-solutions instead.
The Core Philosophy
"PRD creation should be traceable, coherent, and persistent - not scattered across context switches."
This skill combines:
- PRD methodology (from architecting-solutions)
- File-based persistence (from planning-with-files)
To create a single, coherent PRD creation workflow that doesn't lose context.
4-File Pattern for PRD Creation
For every PRD project, create FOUR files:
Pick a SCOPE (short, unique, kebab-case slug) and use it as a prefix for all files.
docs/{scope}-prd-notes.md → Store research, requirements, findings, options
docs/{scope}-prd-task-plan.md → Track PRD creation phases and progress
docs/{scope}-prd.md → Product requirements (what & why)
docs/{scope}-tech.md → Technical design (how)
File Purposes
| File |
Purpose |
Audience |
Updated When |
{scope}-prd-notes.md |
Raw research, requirements, architecture options (A/B/C) |
Self + reviewers |
New information gathered |
{scope}-prd-task-plan.md |
Track progress, phases, checkboxes, timestamps |
PM + dev lead |
Each phase completion |
{scope}-prd.md |
Product requirements (what & why), user flows |
PM + stakeholders + devs |
After requirements are clear |
{scope}-tech.md |
Technical design (API, data flow, implementation) |
Developers + architects |
After architecture is decided |
Workflow
┌─────────────────────────────────────────────────────────────────┐
│ PRD Creation Workflow │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 1. Initialize → Create 4 files with template │
│ 2. Requirements → Gather to {scope}-prd-notes.md │
│ 2.5 Edge Cases → Scan codebase, infer patterns, ask smartly │
│ 3. Analysis → Research best practices, save to notes │
│ 4. Design → Propose architecture options (A/B/C), save to notes │
│ 5. PRD → Write product requirements to {scope}-prd.md │
│ 6. Tech → Write technical design to {scope}-tech.md │
│ 7. Validate → Review with user, finalize │
│ │
└─────────────────────────────────────────────────────────────────┘
↓
All thinking persisted to files
↓
No context switching
Step 1: Initialize
Create the four files with templates:
{scope}-prd-task-plan.md
# PRD Task Plan: {Feature Name}
## Goal
Create a PRD and technical design for {feature description}.
## Owner
{User name/role}
## Phases
- [x] Phase 1: Initialize files ✓
- [ ] Phase 2: Gather requirements (CURRENT)
- [ ] Phase 3: Research & analysis
- [ ] Phase 4: Design solution
- [ ] Phase 5: Write PRD
- [ ] Phase 6: Write technical design
- [ ] Phase 7: Validate & finalize
## Status
**Currently in Phase 2** - Gathering requirements from user
## Progress Log
- {timestamp} - Phase 1 complete: Files initialized
{scope}-prd-notes.md
# PRD Notes: {Feature Name}
## Raw Requirements
(Add user requirements as they emerge)
## Constraints
(Add technical, business, time constraints)
## Inferred Patterns (from codebase)
|-----------|--------|-----------------|
| (Filled after Step 2.5 codebase scan) | | |
## Edge Cases
### Auto-handled (following codebase patterns)
- (Filled after Step 2.5 analysis)
### Confirmed by User
- (Filled after user confirms edge case decisions)
### Open Questions
- (Track questions to ask user)
## Research Findings
(Add research on best practices, similar solutions)
## Architecture Options
- Option A: {Description}
- Pros: {Advantages}
- Cons: {Disadvantages}
- Option B: {Description}
- Pros: {Advantages}
- Cons: {Disadvantages}
- Option C: {Description}
- Pros: {Advantages}
- Cons: {Disadvantages}
**Selected**: Option {X}
{scope}-prd.md
# PRD: {Feature Name}
> Status: DRAFT
> Last updated: {timestamp}
## Table of Contents
- [Problem Statement](#problem-statement)
- [Goals and Non-Goals](#goals-and-non-goals)
- [Success Criteria](#success-criteria)
- [Scope](#scope)
- [Requirements](#requirements)
- [User Flows](#user-flows)
- [Implementation Plan](#implementation-plan)
---
## Problem Statement
_To be filled after requirements gathering_
## Goals and Non-Goals
### Goals
- {Specific achievable outcomes}
### Non-Goals
- {Explicit exclusions}
## Success Criteria
_To be filled with measurable criteria_
## Scope
### In Scope
- {Specific items included}
### Out of Scope
- {Specific items excluded}
... (rest of PRD sections)
{scope}-tech.md
# Technical Design: {Feature Name}
> Status: DRAFT
> Last updated: {timestamp}
## Overview
{High-level technical approach}
## Key Components
{List major components and their responsibilities}
## API Design
{API signatures, request/response formats}
## Data Flow
{How data flows through the system}
## Implementation Details
{Specific implementation notes}
## Migration Plan
{If applicable, how to migrate from existing system}
Step 2: Gather Requirements
Ask clarifying questions and save responses to {scope}-prd-notes.md:
Core Questions to Ask
- Problem: What problem are we solving?
- Users: Who will use this?
- Success: How do we know it's successful?
- Constraints: Any technical/time/budget constraints?
Save each answer to {scope}-prd-notes.md under appropriate section.
Always update {scope}-prd-task-plan.md after gathering info:
- [x] Phase 2: Gather requirements ✓
- [ ] Phase 2.5: Edge case analysis (CURRENT)
- [ ] Phase 3: Research & analysis
Step 2.5: Context-Aware Edge Case Analysis
Before asking users about edge cases, scan the codebase first to infer existing patterns. This reduces redundant questions and ensures consistency with the project.
Detailed reference: See references/edge-case-analysis.md for full scanning commands and output formats.
Quick Process
- Scan codebase for existing patterns (delete strategy, error handling, empty states, pagination)
- Identify requirement type (CRUD, State Workflow, Async, Data Display, Form, File)
- Generate smart assumptions - patterns found in code don't need user confirmation
- Ask only when needed - no precedent, multiple patterns, or business decision required
When to Ask Users
| Condition |
Action |
| Pattern exists in codebase |
Auto-apply, no question needed |
| No precedent found |
Ask user with options |
| Multiple conflicting patterns |
Ask user to choose |
| Business rule required |
Ask user |
Output to Notes File
Update {scope}-prd-notes.md with:
## Inferred Patterns (from codebase)
|-----------|--------|-----------------|
| Delete | `src/models/User.ts:45` | Soft delete |
## Edge Cases
### Auto-handled (following codebase patterns)
- Empty list → Use existing EmptyState component
### Confirmed by User
- Concurrent edit: Last write wins (confirmed {date})
Update task plan:
- [x] Phase 2.5: Edge case analysis ✓
- [ ] Phase 3: Research & analysis (CURRENT)
Step 3: Research & Analysis
Research best practices and save to {scope}-prd-notes.md:
grep -r "keyword" packages/ --include="*.ts"
