Prd Development
Turn discovery notes and stakeholder threads into a single engineering-ready PRD before build starts.
Overview
PRD Development is an agent skill most often used in Validate (also Build) that guides structured Product Requirements Document creation from discovery inputs through problem, users, solution, and success criteria.
Install
npx skills add https://github.com/deanpeters/product-manager-skills --skill prd-developmentWhat is this skill?
- Workflow orchestrates problem framing, research synthesis, solution definition, and success criteria in one doc
- Targets major initiatives and engineering handoff—not ad-hoc task lists
- Estimated 60–120 minutes for a complete PRD from scattered inputs
- Best for post–discovery-sprint artifacts and new feature documentation before dev
- PM-artifact theme aligned with stakeholder alignment and source-of-truth documentation
- Estimated time 60–120 min per complete PRD workflow
Adoption & trust: 2.3k installs on skills.sh; 5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You finished discovery but requirements still live in threads and notes, so engineering and agents cannot ship against a single clear spec.
Who is it for?
Solo builders or PMs documenting a major feature after discovery, before any substantial build work.
Skip if: Tiny one-line tweaks, already-approved specs with tasks assigned, or pure competitive research with no solution definition yet.
When should I use this skill?
Turning discovery notes into an engineering-ready document for a major initiative.
What do I get? / Deliverables
You get a comprehensive, engineering-ready PRD that aligns stakeholders and defines success criteria—ready to feed implementation planning or agent coding workflows.
- Structured PRD covering problem, users, solution, and success criteria
- Stakeholder-alignable requirements document for engineering handoff
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
PRDs are the canonical gate between validated discovery and implementation—solo builders use this shelf when scope must be frozen for handoff. Scope subphase is where requirements documents live: problem, users, solution, and success criteria after validation, not during casual ideation alone.
Where it fits
Lock scope and success metrics for an e-commerce recommendation feature after customer interviews.
Attach the PRD as the source of truth while breaking work into agent-friendly implementation tasks.
Organize early problem framing sections before full validation, when notes are still exploratory.
How it compares
Use instead of dumping chat context into a ticket—this is a full PRD workflow, not a quick user-story generator.
Common Questions / FAQ
Who is prd-development for?
Product-minded solo builders, indie PMs, and technical founders who own scope and need a formal PRD for engineering or coding agents.
When should I use prd-development?
After validate-phase discovery when you need scope frozen—e.g. turning a sprint’s findings into a handoff doc, or writing requirements for a new AI recommendation feature before development.
Is prd-development safe to install?
Review the Security Audits panel on this Prism page and inspect the skill package in your repo before granting agent write access to product docs.
SKILL.md
READMESKILL.md - Prd Development
## Purpose Guide product managers through structured PRD (Product Requirements Document) creation by orchestrating problem framing, user research synthesis, solution definition, and success criteria into a cohesive document. Use this to move from scattered notes and Slack threads to a clear, comprehensive PRD that aligns stakeholders, provides engineering context, and serves as a source of truth—avoiding ambiguity, scope creep, and the "build what's in my head" trap. This is not a waterfall spec—it's a living document that captures strategic context, customer problems, proposed solutions, and success criteria, evolving as you learn through delivery. ## Key Concepts ### What is a PRD? A PRD (Product Requirements Document) is a structured document that answers: 1. **What problem are we solving?** (Problem statement) 2. **For whom?** (Target users/personas) 3. **Why now?** (Strategic context, business case) 4. **What are we building?** (Solution overview) 5. **How will we measure success?** (Metrics, success criteria) 6. **What are the requirements?** (User stories, acceptance criteria, constraints) 7. **What are we NOT building?** (Out of scope) ### PRD Structure (Standard Template) ```markdown # [Feature/Product Name] PRD ## 1. Executive Summary - One-paragraph overview (problem + solution + impact) ## 2. Problem Statement - Who has this problem? - What is the problem? - Why is it painful? - Evidence (customer quotes, data, research) ## 3. Target Users & Personas - Primary persona(s) - Secondary persona(s) - Jobs-to-be-done ## 4. Strategic Context - Business goals (OKRs) - Market opportunity (TAM/SAM/SOM) - Competitive landscape - Why now? ## 5. Solution Overview - High-level description - User flows or wireframes - Key features ## 6. Success Metrics - Primary metric (what we're optimizing for) - Secondary metrics - Targets (current → goal) ## 7. User Stories & Requirements - Epic hypothesis - User stories with acceptance criteria - Edge cases, constraints ## 8. Out of Scope - What we're NOT building (and why) ## 9. Dependencies & Risks - Technical dependencies - External dependencies (integrations, partnerships) - Risks and mitigations ## 10. Open Questions - Unresolved decisions - Areas requiring discovery ``` ### Why This Works - **Alignment:** Ensures everyone (PM, design, eng, stakeholders) understands the "why" - **Context preservation:** Captures research and strategic rationale for future reference - **Decision log:** Documents what's in scope, out of scope, and why - **Execution clarity:** Provides engineering with user stories and acceptance criteria ### Anti-Patterns (What This Is NOT) - **Not a detailed spec:** PRDs frame the problem and solution; they don't specify UI pixel-by-pixel - **Not waterfall:** PRDs evolve as you learn; they're not frozen contracts - **Not a subs