| name | prd-generation |
| description | Generates professional Product Requirements Documents (PRDs) following industry-standard methodologies. This skill activates when the user asks to write PRD, create a product requirements document, draft product requirements, do product planning, do feature planning, write a product spec, or create a product document. It synthesizes best practices from the Google PRD framework, the Amazon Working Backwards methodology, and the Stripe Product Spec approach to produce comprehensive, actionable PRDs tailored to the user's project.
|
| instructions | Generate PRDs by combining the structured rigor of Google PRD templates, the customer-centric narrative of Amazon Working Backwards, and the engineering-precision of Stripe Product Specs. Follow the five-step workflow defined in this skill, reference the template at references/template.md, and validate output against the checklist at references/checklist.md.
|
PRD Generation Skill
What Is a PRD?
A Product Requirements Document (PRD) is the central artifact that bridges product strategy and engineering execution. It captures the why, what, and how of a product initiative so that every stakeholder -- from designers and engineers to leadership and QA -- operates from a single source of truth. A well-written PRD reduces ambiguity, prevents scope creep, and provides a measurable framework against which the team can evaluate success.
Within the product development lifecycle a PRD typically sits between the discovery phase (where problems are identified and validated) and the design/engineering phase (where solutions are built). It is not a static document; it evolves through drafts, reviews, and revisions as the team's understanding deepens. This skill treats the PRD as a living document and structures it accordingly.
Five-Step Workflow
Every PRD generated by this skill follows a disciplined five-step process. Each step must be completed before moving to the next.
Step 1 -- Understand Context
Before writing a single line, scan the project to build situational awareness.
@../shared/project-context.md
Execute the Project Context Protocol (PC.1 through PC.3) to determine:
- Project structure and existing documentation (PC.1)
- Tech stack and framework (PC.2)
- Project profile (PC.3) — Web API, CLI Tool, Frontend, etc.
Additionally:
4. Scan the docs/ directory (if it exists) to find prior PRDs, technical designs, or ADRs. Understanding what has already been decided prevents contradictions and duplicated effort.
5. Identify domain language and team conventions so the PRD speaks the same language as the codebase.
This scanning step ensures the generated PRD is grounded in the actual project rather than generic boilerplate. The detected project profile informs which sections of the PRD need the most detail (e.g., a CLI tool needs different success metrics than a Web API).
Step 2 -- Clarify Questions
After scanning, present the user with targeted clarifying questions. Good questions surface missing context that cannot be inferred from the codebase. Typical areas to probe include:
- The target user segment and their primary pain points.
- Business objectives and how success will be measured.
- Known constraints (timeline, budget, regulatory, technical debt).
- Stakeholders who must review or approve the PRD.
- Dependencies on other teams, services, or third-party systems.
Do not proceed to structuring until the user has answered enough questions to fill the core sections of the template.
Step 3 -- Structure Design
Using the answers from Step 2 and the context from Step 1, decide which sections of the template are relevant and how deep each section needs to be. Not every PRD requires every section at maximum depth. A small feature enhancement may need a lighter treatment than a net-new product launch. Map the user's input to the template sections defined in references/template.md and plan the Mermaid diagrams that will be included.
Step 4 -- Content Generation
Write the PRD by filling in each section of the template. Follow the writing guidelines and standards defined in the reference files below. Generate all Mermaid diagrams inline. Assign requirement IDs, priorities, and success metrics as you go.
- Writing Guidelines: @./writing-guidelines.md
- Standards: @./standards.md
Step 5 -- Quality Check
Validate the completed PRD against every item in references/checklist.md. Fix any issues before presenting the final document to the user. Summarize the checklist results so the user can see what passed and whether any items were intentionally skipped (with justification).
Reference Files
This skill relies on two reference files stored alongside it.
references/template.md -- The full PRD template with placeholder text for every section. The generated PRD is built by filling in this template.references/checklist.md -- A quality checklist organized into four categories (Completeness, Quality, Consistency, Format). The checklist is used during Step 5 to validate the finished document.
Always read both files before generating a PRD so that any updates to the template or checklist are picked up automatically.
Output Location
The finished PRD is written to:
docs/<feature-name>/prd.md
where <feature-name> is a lowercase, hyphen-separated slug derived from the feature name (for example, docs/user-onboarding/prd.md or docs/payment-retry-logic/prd.md). If the docs/<feature-name>/ directory does not exist, create it. If a file with the same name already exists, confirm with the user before overwriting.
