# Prd > Generate production-ready Product Requirements Documents for software systems and AI-powered features. Use when starting a product or feature cycle, translating a vague idea into requirements, defining AI system requirements, planning a feature, or creating a stakeholder source of truth. - Skill: `paulasilvatech/prd` (Agent Skill) - Install (CLI): `npx skillmds@latest add paulasilvatech/prd` - Raw SKILL.md: https://api.skillmd.com/api/skills/paulasilvatech/prd/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - License: MIT - Author: paulasilvatech (https://skillmd.com/u/paulasilvatech) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/paulasilvatech/prd --- # Product requirements document Turns an idea, feature request, or stakeholder brief into a measurable PRD with user stories, acceptance criteria, AI evaluation requirements when applicable, technical specifications, risks, and rollout plan. ## When to invoke - "Write a PRD for this feature." - "Turn this idea into product requirements." - "Plan an AI-powered feature with evaluation criteria." - "Create a source of truth for scope and acceptance criteria." - "Document requirements before development starts." ## Procedure 1. Run discovery before drafting: identify the core problem, success metrics, constraints, and stakeholders. 2. Ask at least two clarifying questions when the request lacks problem, user, metric, or constraint details. 3. Synthesize scope: map the user flow, dependencies, non-goals, and hidden complexity. 4. Draft the PRD using the schema in `## PRD structure`. 5. Label unknowns as `TBD` instead of inventing constraints. 6. Present the draft and ask for feedback on specific sections. ## Discovery prompts | Area | Ask | | --- | --- | | Core problem | Why are we building this now, and what pain point exists today? | | Users | Who uses it, who buys or approves it, and who supports it? | | Success metrics | How do we know it worked? Name measurable KPIs. | | Constraints | What budget, deadline, stack, compliance, data, or operational constraints apply? | | AI behavior | What tools, APIs, guardrails, evaluation set, and human review path are required? | ## PRD quality standards | Weak requirement | Strong replacement | | --- | --- | | "The search should be fast and return relevant results." | "The search must return results within 200ms for a 10k record dataset." | | "The UI must look modern and be easy to use." | "The UI must follow the Vercel/Next.js design system and achieve 100% Lighthouse Accessibility score." | | "AI answers should be accurate." | "The answer evaluator must reach >= 85% Precision@10 and citation accuracy >= 95% on the benchmark set." | Use concrete, measurable criteria. Avoid `fast`, `easy`, `intuitive`, and unsupported claims unless each is backed by a metric. ## PRD structure | Section | Required content | | --- | --- | | Executive Summary | Problem Statement, Proposed Solution, and 3-5 measurable Success Criteria. | | User Experience & Functionality | User Personas, User Stories in `As a [user], I want to [action] so that [benefit].` form, Acceptance Criteria, and Non-Goals. | | AI System Requirements | Include only when applicable: Tool Requirements, APIs, Evaluation Strategy, output quality, accuracy, and safety criteria. | | Technical Specifications | Architecture Overview, data flow, component interaction, Integration Points, APIs, DBs, Auth, Security & Privacy. | | Risks & Roadmap | Phased Rollout from MVP -> v1.1 -> v2.0, technical risks, latency, cost, dependency failures, and mitigations. | ## Examples ### Good **Input:** "Build intelligent documentation search for developers." **Expected behavior:** Produce measurable success criteria such as reducing search time by 50%, citation accuracy >= 95%, and a benchmark with 50 common developer questions. ### Bad **Input:** "Write the PRD; assume the tech stack." **Incorrect behavior:** Inventing stack choices. Use `TBD` or ask a clarifying question if the stack is a real constraint. ## Gotchas - **Do not skip discovery**: never write a PRD from a vague idea without asking at least two clarifying questions or explicitly marking assumptions. - **Do not hallucinate constraints**: if the user did not specify a tech stack, budget, or deadline, ask or label it `TBD`. - **Do not omit testing for AI systems**: specify benchmark data, expected pass rate, evaluation criteria, and human review path. - **Do not treat non-goals as optional**: they protect timeline and stakeholder alignment. ## PRD drafting vocabulary A `production-grade`, `high-quality` PRD may include a `GOOD` example, `MUST` constraints, `multi-turn` user flows, and tool placeholders such as `codesearch`, `grep`, and `webfetch` when the product genuinely needs them. ## Output template ```markdown # Product Requirements Document: ## 1. Executive Summary **Problem Statement:** <1-2 sentences> **Proposed Solution:** <1-2 sentences> **Success Criteria:** - - - ## 2. User Experience & Functionality **User Personas** - : **User Stories** - As a , I want to so that . **Acceptance Criteria** - **Non-Goals** - ## 3. AI System Requirements **Tool Requirements:** **Evaluation Strategy:** ## 4. Technical Specifications **Architecture Overview:** **Integration Points:** **Security & Privacy:** ## 5. Risks & Roadmap **Phased Rollout:** MVP -> v1.1 -> v2.0 **Technical Risks:** ``` ## Quality gate - [ ] At least two clarifying questions were asked or assumptions are explicitly labeled. - [ ] Success criteria are measurable and include 3-5 KPIs. - [ ] User stories follow `As a [user], I want to [action] so that [benefit].`. - [ ] Acceptance criteria are testable done definitions. - [ ] Non-goals are present. - [ ] AI features include Tool Requirements and Evaluation Strategy. - [ ] Unknown constraints are marked `TBD`, not invented. - [ ] The final PRD follows the output template.