MCPInstall

prd-planner

Creates PRDs using persistent file-based planning. Use when user explicitly says "PRD", "product requirements document", or "产品需求文档". Combines PRD methodology with planning-with-files to avoid context switching.

Installs
830
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/zhaono1/agent-playbook --skill prd-planner
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads prd-planner automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

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

FilePurposeAudienceUpdated When
{scope}-prd-notes.mdRaw research, requirements, architecture options (A/B/C)Self + reviewersNew information gathered
{scope}-prd-task-plan.mdTrack progress, phases, checkboxes, timestampsPM + dev leadEach phase completion
{scope}-prd.mdProduct requirements (what & why), user flowsPM + stakeholders + devsAfter requirements are clear
{scope}-tech.mdTechnical design (API, data flow, implementation)Developers + architectsAfter 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)

| Edge Case | Source | Pattern Applied |
|-----------|--------|-----------------|
| (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

  1. Problem: What problem are we solving?
  2. Users: Who will use this?
  3. Success: How do we know it's successful?
  4. 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

  1. Scan codebase for existing patterns (delete strategy, error handling, empty states, pagination)
  2. Identify requirement type (CRUD, State Workflow, Async, Data Display, Form, File)
  3. Generate smart assumptions - patterns found in code don't need user confirmation
  4. Ask only when needed - no precedent, multiple patterns, or business decision required

When to Ask Users

ConditionAction
Pattern exists in codebaseAuto-apply, no question needed
No precedent foundAsk user with options
Multiple conflicting patternsAsk user to choose
Business rule requiredAsk user

Output to Notes File

Update {scope}-prd-notes.md with:

## Inferred Patterns (from codebase)
| Edge Case | Source | Pattern Applied |
|-----------|--------|-----------------|
| 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:

# Search for similar implementations
grep -r "keyword" packages/ --include="*.ts"

# Search web for best practices
web search "best practices for {feature}"

Save findings to {scope}-prd-notes.md → Research Findings section.

Step 4: Design Solution

Propose architecture with trade-offs, save to {scope}-prd-notes.md:

## 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} - because {reason}

Step 5: Write PRD

Read {scope}-prd-notes.md and synthesize into polished PRD:

1. Read {scope}-prd-notes.md to understand:
   - Requirements gathered
   - Research findings
   - Architecture decision (which option was selected)

2. Write {scope}-prd.md with:
   - Clear problem statement
   - Goals and Non-Goals (explicit exclusions)
   - Measurable success criteria (specific numbers/timings)
   - Scope (In Scope / Out of Scope)
   - Functional requirements
   - Non-functional requirements
   - User flows
   - Implementation plan (high level)

3. Reference tech doc: "See {scope}-tech.md for technical design"

Step 6: Write Technical Design

1. Read {scope}-prd-notes.md for selected architecture option

2. Write {scope}-tech.md with:
   - Overview (technical approach summary)
   - Key Components (what pieces, responsibilities)
   - API Design (signatures, contracts)
   - Data Flow (how data moves through system)
   - Implementation Details (specific notes)
   - Migration Plan (if applicable)

Step 7: Validate & Finalize

Review with user:

  1. Present PRD summary
  2. Ask for feedback
  3. Incorporate changes
  4. Mark Phase 7 complete

Important Rules

RuleBadGood
Use FilesKeep in memorySave to {scope}-prd-notes.md
Update PlanMove on without updateUpdate task-plan.md with checkbox
Read Before DecideDecide from memoryRead notes first
Separate DocsMix PRD + TechPRD for "what", Tech for "how"
Include OptionsJump to solutionDocument 2-3 options with pros/cons

Phase Transitions

Update {scope}-prd-task-plan.md after each phase with checkbox ✓ and timestamp.

Completing a PRD

Mark all phases complete, set status to "✅ COMPLETE", log final deliverables.

File Cleanup (Optional)

After PRD is complete:

  • Keep {scope}-prd-notes.md for reference (shows decision process)
  • Archive {scope}-prd-task-plan.md or delete
  • Final outputs are {scope}-prd.md and {scope}-tech.md

Quick Start Template

# PRD Task Plan: {Feature}

## Goal
Create PRD and technical design for {description}

## Phases
- [ ] Initialize 4 files
- [ ] Gather requirements
- [ ] Research & analysis
- [ ] Design solution (A/B/C options)
- [ ] Write PRD
- [ ] Write technical design
- [ ] Validate & finalize

## Status
Phase 1: Initializing files

Why This Works

ProblemSolution
Context switchingAll thinking in files, read anytime
Lost requirementsSaved to {scope}-prd-notes.md immediately
Inconsistent PRDsSame process, same structure
"Left brain vs right brain"One coherent workflow
Re-explaining contextFiles contain full context
Mixed concernsPRD (product) separate from Tech (implementation)
Hidden decisionsArchitecture options A/B/C documented

References

  • planning-with-files - File-based planning methodology
  • architecting-solutions - Non-PRD solution and architecture design
  • Edge case scanning: references/edge-case-analysis.md

Auto-Trigger (Follow-up Metadata)

When this skill completes, record or run supported follow-ups:

  1. self-improving-agent (background) - Propose reusable patterns
  2. session-logger (auto) - Save session context when supported

FAQ

What does the prd-planner skill do?

Creates PRDs using persistent file-based planning. Use when user explicitly says "PRD", "product requirements document", or "产品需求文档". Combines PRD methodology with planning-with-files to avoid context switching.

How do I install prd-planner?

Run npx skills add https://github.com/zhaono1/agent-playbook --skill prd-planner in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/prd-planner/ (personal) or .claude/skills/prd-planner/ (project).

Which AI agents can use prd-planner?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is prd-planner safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains prd-planner?

It is published by zhaono1 in zhaono1/agent-playbook. It has 830 recorded installs.

More from zhaono1/agent-playbook

View all →

self-improving-agent

zhaono1/agent-playbook

Use after a failure, user correction, repeated workflow problem, or validated success reveals a reusable lesson. Captures bounded redacted candidates, runs executable behavior evals, and separates validation from application in durable guidance.

AI & Agents35.1K installs

planning-with-files

zhaono1/agent-playbook

Uses persistent markdown files for general planning, progress tracking, and knowledge storage (Manus-style workflow). Use for multi-step tasks, research projects, or general organization WITHOUT mentioning PRD. For PRD-specific work, use prd-planner skill instead.

security-auditor

zhaono1/agent-playbook

Security vulnerability expert covering OWASP Top 10 and common security issues. Use when conducting security audits or reviewing code for vulnerabilities.

Security1.1K installs

architecting-solutions

zhaono1/agent-playbook

Designs technical solutions and architecture. Use when user says "design solution", "architecture design", "technical design", or "方案设计" WITHOUT mentioning PRD. For PRD-specific work, use prd-planner skill instead.

skill-router

zhaono1/agent-playbook

Routes an agent request to the narrowest matching portable skill when the user asks which skill to use or needs help selecting one across supported hosts.

874 installs

workflow-orchestrator

zhaono1/agent-playbook

Coordinates multi-skill workflows and records or runs follow-up actions when the host runtime supports them. Use when completing PRD creation, implementation, or any milestone that should be evaluated for additional skills.

Popular code quality & workflow skills

View category →

grill-me

mattpocock/skills

A relentless interview to sharpen a plan or design.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

handoff

mattpocock/skills

Compact the current conversation into a handoff document for another agent to pick up.

domain-modeling

mattpocock/skills

Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.

codebase-design

mattpocock/skills

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

diagnosing-bugs

mattpocock/skills

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.