# Prd > Activate for: PRD, product requirements document, product requirements, full requirements, initiative doc, initiative requirements, platform change, new product, product launch, major release, quarterly initiative, program brief, product vision doc, comprehensive requirements, cross-functional alignment doc, launch plan requirements, multi-team initiative. NOT for: single-feature specifications (use official /write-spec), roadmap planning (use official /roadmap-update), sprint planning (use official /sprint-planning). - Skill: `panaversity/prd` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add panaversity/prd` - Raw SKILL.md: https://api.skillmd.com/api/skills/panaversity/prd/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Product & Planning - License: Apache-2.0 - Author: panaversity (https://skillmd.com/u/panaversity) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/panaversity/prd --- ## CONTEXT LOADING Before generating a PRD, load `product.local.md` for product context, personas, engineering team details, and stakeholder map. If not configured, ask the user for product name, personas, and engineering context. ## PRD WORKFLOW ### When to Write a PRD (vs. a Feature Spec) Write a SPEC when: One feature, one team, one-to-three sprints Write a PRD when: Multiple features, multiple teams, major platform change, new product area, or executive alignment required If unsure, ask the user: "Is this one feature for one team (use /write-spec) or a multi-team initiative (use /prd)?" ### PRD Sections -- Full Template SECTION 1: EXECUTIVE SUMMARY [3-4 sentences only] What: [What are we building -- in plain language] Why: [What commercial or user problem does it solve] When: [Target delivery -- quarter, not date unless confirmed] Win: [How we will know it worked -- headline metric] SECTION 2: BUSINESS CONTEXT Problem statement: [The specific user pain or business gap -- with evidence] Commercial evidence (use what is available): - Lost deals: "[N] deals cited [issue] as blocker in [period]" - Customer requests: "[N] requests logged; [source]" - Competitive gap: "[Competitor] offers [feature]; we do not" - Revenue opportunity: "[Estimate] ARR blocked or at risk" - Support cost: "[N] tickets / [hours] PM support time per [period]" Strategic fit: [How this initiative connects to the company/product strategy. One sentence. If you cannot write this sentence, the initiative may not belong in the roadmap.] Success metrics: Primary (measure at 6-12 months post-launch): [Specific, measurable outcome: not "improve NPS" but "enterprise NPS from 42 to 52 within 6 months of launch"] Secondary (measure at 30-90 days): [Leading indicators: adoption rate; support volume change; sales cycle impact] Failure threshold: [What outcome would cause us to reconsider or change direction? Define before launch, not after.] SECTION 3: USER REQUIREMENTS Primary persona: Name: [Persona name from product.local.md] Role: [Job title / function] Current state: [How they handle this today -- the workaround] Desired state: [What "10/10" looks like for them] Key user stories: [Top 3 as "As a... I want... So that..."] Secondary persona (if applicable): [Same structure -- brief] User journey map: Current state: [Step-by-step of how they do it today] Pain points: [Where the friction is in the current flow] Future state: [Step-by-step with the new product in place] SECTION 4: FUNCTIONAL REQUIREMENTS For each feature/capability in scope: Feature [N]: [Name] Priority: MUST / SHOULD / COULD (MoSCoW) Description: [What it does] Key flows: [Primary user flows] Dependencies: [Other features or teams this depends on] Spec ref: [Link to individual spec if exists] Rule: Every item labelled MUST must ship before launch. If more than 60% of items are labelled MUST, the scope is too large. SECTION 5: NON-FUNCTIONAL REQUIREMENTS Performance: [Page load time; API response time; export generation time -- with numbers] Reliability: [Uptime SLA; error rate tolerance; recovery time objective] Security: [Authentication requirements; data encryption; audit requirements; penetration testing if required] Compliance: [GDPR / CCPA data handling; SOC 2 implications; HIPAA if applicable; sector-specific regulations] Accessibility: [WCAG standard; keyboard navigation; screen reader requirements] Scalability: [Expected load at launch; growth assumptions; capacity planning notes] SECTION 6: TECHNICAL ARCHITECTURE NOTES [High-level approach -- not implementation detail] - Key technical decisions already made - Platform or infrastructure dependencies - Third-party integrations required - Data model changes (high level) - Migration requirements (existing users / data) - Feature flags required Note: This section is written by PM in collaboration with engineering. It must be reviewed and confirmed by the engineering lead before the PRD is marked as REVIEW-ready. SECTION 7: GO-TO-MARKET REQUIREMENTS Documentation: [Customer-facing docs required; doc owner; due date] Customer Success enablement: [What CS needs to know before launch; training requirements] Sales enablement: [What sales needs to demo/discuss this feature; talking points] Pricing: [Is this in the current plan? New tier? Add-on? Pricing team review needed?] Beta programme: [Which customers; how many; invite criteria; beta start date; GA date] Customer communication: [Announcement channel; timing; who sends it] SECTION 8: LAUNCH PLAN Phased rollout: Phase 1 -- Beta: [Audience; dates; success gates for Phase 2] Phase 2 -- GA: [Full availability; announcement plan] Rollback plan: [How to undo if critical bug discovered post-launch] Feature flags: [Required flags; rollout percentages; sunset plan] Monitoring: [What metrics are watched in the first 48 hours post-launch; who is on-call; escalation path] SECTION 9: DEPENDENCIES AND RISKS External dependencies: | Dependency | Owner | Status | Risk if delayed | |---|---|---|---| | [Third party / platform team] | [Name] | [On track / TBD] | [Impact] | Top risks: | Risk | Likelihood | Impact | Mitigation | |---|---|---|---| | [Risk description] | H/M/L | H/M/L | [Specific mitigation action] | SECTION 10: OPEN QUESTIONS [Numbered; owner; due date] All questions must be resolved before PRD moves to REFINED status. APPENDICES (include as available) A. Competitive analysis B. User research excerpts C. Technical discovery notes D. Prior art / related specs ### PRD Status Gates DRAFT: All sections present; some may be incomplete REVIEW: All sections complete; open questions have owners and dates; engineering lead has confirmed architecture notes REFINED: All open questions resolved; effort estimated by engineering; GTM requirements confirmed by CS/Sales APPROVED: CPO/CEO sign-off; ready for sprint planning SHIPPED: Feature live; success metrics being tracked ## COMPLEMENTARY WORKFLOWS This skill handles multi-team PRDs. For related PM workflows: - Single-feature specifications: use official `/write-spec` - Decomposing PRD into user stories: use `/stories` from this plugin - Roadmap placement: use official `/roadmap-update` - Sprint planning from PRD: use official `/sprint-planning` ## NEVER DO THESE - NEVER approve a PRD for sprint planning without engineering lead sign-off on the architecture notes section - NEVER mark a PRD REVIEW-ready with empty sections -- a gap in the PRD is a gap in the product thinking - NEVER define success metrics after launch -- they must be in the PRD before the first sprint starts - NEVER omit the failure threshold -- knowing when to change direction is as important as knowing when to celebrate - NEVER list a MUST requirement you would actually ship without -- if you would ship without it, it is a SHOULD - NEVER use "a user" as the persona -- always reference named personas from product.local.md ALL OUTPUTS REQUIRE REVIEW BY THE PM AND ENGINEERING LEAD BEFORE APPROVAL.