Prd
Turn a vague product or AI feature idea into a stakeholder-ready PRD with user stories, technical specs, risks, and explicit non-goals after a structured discovery interview.
Overview
prd is an agent skill most often used in Validate (also Idea research, Build PM) that produces interview-driven Product Requirements Documents for software and AI features.
Install
npx skills add https://github.com/github/awesome-copilot --skill prdWhat is this skill?
- Mandatory Phase 1 discovery interview—no PRD text until gaps on problem, metrics, and constraints are filled
- Three-phase workflow: Discovery, Analysis & Scoping, then Technical Drafting
- Outputs executive summary, user stories, technical specifications, and risk analysis for software and AI-powered feature
- Forces user-flow mapping and non-goals to protect timeline
- Bridges business vision and engineering execution in one document
- Three-phase operational workflow: Discovery, Analysis & Scoping, Technical Drafting
- Phase 1 discovery MUST complete before any PRD lines are written
Adoption & trust: 19.1k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have momentum on an idea but no shared document that defines problem, metrics, scope, and technical expectations for you or your coding agent.
Who is it for?
Solo builders starting a new feature or product who can answer discovery questions and want one source of truth before coding.
Skip if: Teams that already have an approved spec and only need task breakdown (use a writing-plans-style skill instead) or trivial one-line tweaks with no scope debate.
When should I use this skill?
Starting a product or feature cycle, translating a vague idea into a spec, defining AI feature requirements, or when the user asks to write a PRD, document requirements, or plan a feature.
What do I get? / Deliverables
You get a structured PRD with user stories, specs, risks, and non-goals ready to hand off into planning or implementation workstreams.
- Product Requirements Document with executive summary, user stories, technical specifications, and risk analysis
- Documented non-goals and user flow outline
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
PRDs lock scope and success criteria before full Build—canonical shelf is Validate when you are proving what to build. Scope subphase is where requirements, non-goals, and user flows get defined as the source of truth for implementation.
Where it fits
Interview clarifies the core problem and success metrics before you commit to a build path.
Draft non-goals and user flows so a prototype or MVP does not sprawl.
Capture constraints and timeline implications that affect what ships in v1.
Refresh the PRD when stakeholders add AI behavior or integration dependencies mid-project.
How it compares
Interview-first PRD workflow—not a quick markdown template dump without discovery or success metrics.
Common Questions / FAQ
Who is prd for?
Indie product owners, solo technical founders, and agent users who need formal requirements before Build or stakeholder check-ins.
When should I use prd?
In Idea when researching what to build; in Validate when scoping a feature or AI capability; in Build PM when refreshing scope before a major milestone—and whenever you ask to write a PRD or document requirements.
Is prd safe to install?
Review the Security Audits panel on this Prism page; the skill elicits business context—avoid pasting secrets you do not want in generated documents.
Workflow Chain
Then invoke: writing plans
SKILL.md
READMESKILL.md - Prd
# Product Requirements Document (PRD) ## Overview Design comprehensive, production-grade Product Requirements Documents (PRDs) that bridge the gap between business vision and technical execution. This skill works for modern software systems, ensuring that requirements are clearly defined. ## When to Use Use this skill when: - Starting a new product or feature development cycle - Translating a vague idea into a concrete technical specification - Defining requirements for AI-powered features - Stakeholders need a unified "source of truth" for project scope - User asks to "write a PRD", "document requirements", or "plan a feature" --- ## Operational Workflow ### Phase 1: Discovery (The Interview) Before writing a single line of the PRD, you **MUST** interrogate the user to fill knowledge gaps. Do not assume context. **Ask about:** - **The Core Problem**: Why are we building this now? - **Success Metrics**: How do we know it worked? - **Constraints**: Budget, tech stack, or deadline? ### Phase 2: Analysis & Scoping Synthesize the user's input. Identify dependencies and hidden complexities. - Map out the **User Flow**. - Define **Non-Goals** to protect the timeline. ### Phase 3: Technical Drafting Generate the document using the **Strict PRD Schema** below. --- ## PRD Quality Standards ### Requirements Quality Use concrete, measurable criteria. Avoid "fast", "easy", or "intuitive". ```diff # Vague (BAD) - The search should be fast and return relevant results. - The UI must look modern and be easy to use. # Concrete (GOOD) + The search must return results within 200ms for a 10k record dataset. + The search algorithm must achieve >= 85% Precision@10 in benchmark evals. + The UI must follow the 'Vercel/Next.js' design system and achieve 100% Lighthouse Accessibility score. ``` --- ## Strict PRD Schema You **MUST** follow this exact structure for the output: ### 1. Executive Summary - **Problem Statement**: 1-2 sentences on the pain point. - **Proposed Solution**: 1-2 sentences on the fix. - **Success Criteria**: 3-5 measurable KPIs. ### 2. User Experience & Functionality - **User Personas**: Who is this for? - **User Stories**: `As a [user], I want to [action] so that [benefit].` - **Acceptance Criteria**: Bulleted list of "Done" definitions for each story. - **Non-Goals**: What are we NOT building? ### 3. AI System Requirements (If Applicable) - **Tool Requirements**: What tools and APIs are needed? - **Evaluation Strategy**: How to measure output quality and accuracy. ### 4. Technical Specifications - **Architecture Overview**: Data flow and component interaction. - **Integration Points**: APIs, DBs, and Auth. - **Security & Privacy**: Data handling and compliance. ### 5. Risks & Roadmap - **Phased Rollout**: MVP -> v1.1 -> v2.0. - **Technical Risks**: Latency, cost, or dependency failures. --- ## Implementation Guidelines ### DO (Always) - **Define Testing**: For AI systems, specify how to test and validate output quality. - **Iterate**: Present a draft and ask for feedback on specific sections. ### DON'T (Avoid) - **Skip Discovery**: Never write a PRD without asking at least 2 clarifying questions first. - **Hallucinate Constraints**: If the user didn't specify a tech stack, ask or label it as `TBD`. --- ## Example: Intelligent Search System ### 1. Executive Summary **Problem**: Users struggle to find specific documentation snippets in massive repositories. **Solution**: An intelligent search system that provides direct answers with source citations. **Success**: - Reduce search time by 50%. - Citation accuracy >= 95%. ### 2. User Stories - **Story**: As a developer, I want to ask natural language questions so I don't have to guess keywords. - **