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.
Generates comprehensive Product Requirements Documents by analyzing project context and following industry-standard frameworks.
npx claudepluginhub tercel/spec-forgeThis skill inherits all available tools. When active, it can use any tool Claude has access to.
references/checklist.mdreferences/generation-instructions.mdreferences/template.mdA 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.
Every PRD generated by this skill follows a disciplined five-step process. Each step must be completed before moving to the next.
Before writing a single line, scan the project to build situational awareness.
**/*.md, **/package.json, **/pyproject.toml, or language-specific manifests to map the landscape.docs/ directory (if it exists) to find prior PRDs, technical designs, or ADRs. Understanding what has already been decided prevents contradictions and duplicated effort.This automated scanning step ensures the generated PRD is grounded in the actual project rather than generic boilerplate.
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:
Do not proceed to structuring until the user has answered enough questions to fill the core sections of the template.
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.
Write the PRD by filling in each section of the template. Follow the writing guidelines described below. Generate all Mermaid diagrams inline. Assign requirement IDs, priorities, and success metrics as you go.
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).
The PRD template contains twenty sections. The following guidelines apply when writing each one.
Document Information and Revision History. Fill in all metadata fields. Use the current date. Set the initial version to 0.1 and the status to Draft. The revision history table must have at least one entry corresponding to the initial draft.
Executive Summary. Write two to four sentences that a busy executive can read in under thirty seconds. State the problem, the proposed solution, and the expected impact. Avoid jargon.
Product Overview and Background. Provide enough context so that a new team member can understand why this initiative exists. Reference prior PRDs or design documents when they exist in the repository.
Market Research and Analysis. This section proves that the product addresses a real market opportunity, not an imagined one. Include market sizing (TAM/SAM/SOM) with cited sources — never fabricate market data. Map the competitive landscape with at least two competitors, honestly acknowledging their strengths. Clearly articulate what differentiates this product. Include industry trends that support the initiative's timing. This section should answer: "Is there a real market for this?"
Value Proposition and Validation. This is the anti-pseudo-requirement section. State the value proposition in one sentence. Then provide hard evidence of real demand from at least three sources: user interviews, survey data, support ticket patterns, usage analytics, beta test results, or revenue impact estimates. Include a "What happens if we don't build this?" subsection that quantifies the cost of inaction. If sufficient evidence does not exist, the PRD should honestly flag this and recommend a validation phase before committing engineering resources.
Feasibility Analysis. Assess technical feasibility (technology readiness, infrastructure, POC status), business feasibility (revenue model, ROI, strategic alignment), and resource feasibility (team availability, skills, budget, timeline). Conclude with a clear GO / CONDITIONAL GO / NO-GO verdict. A well-reasoned NO-GO saves more resources than a poorly justified GO. Do not rubber-stamp everything as GO.
Problem Statement. Structure this section around three lenses: the current situation, the pain points users experience, and the opportunity that addressing those pain points unlocks. Use data or user quotes when available.
Goals and Non-Goals. Goals must be specific, measurable, and time-bound. Non-goals are equally important; they tell the team what is explicitly out of scope so energy is not wasted on tangential work.
User Personas. Define at least two personas in table format. Each persona should have a name, role, demographic summary, core needs, and pain points. Personas must be referenced later in user stories.
User Stories and Acceptance Criteria. Every user story follows the canonical format: "As a [user type], I want [action] so that [benefit]." Each story must have at least two acceptance criteria written as testable conditions.
Functional Requirements Overview. List requirements in a table. Each row gets a unique ID following the naming convention described below, a short feature name, a description, a priority, and a status.
Success Metrics. Every metric must have a target value and a measurement method. Include the current baseline when known. Tie metrics back to the goals defined earlier.
Timeline, Milestones, and Risk Assessment. Use Mermaid Gantt charts for the timeline. Risks go in a matrix with likelihood, impact, mitigation strategy, and an owner.
Dependencies, Open Questions, and Appendix. Capture anything that blocks progress, anything still unresolved, and any supplementary material such as raw research data, detailed competitive analysis spreadsheets, or wireframe links.
Mermaid diagrams make the PRD scannable and visually informative. This skill uses three types of diagrams.
User Journey Flowcharts. Use graph TD or graph LR to show the step-by-step path a user takes through the feature. Include decision nodes for branching logic and clearly label happy-path versus error-path flows.
Feature Architecture Diagrams. Use graph TD to show the high-level component relationships: which services, APIs, data stores, and external systems interact. This is not a detailed system design; it is a conceptual map that helps non-engineers understand the moving parts.
Gantt Charts for Timelines. Use gantt to lay out phases, milestones, and dependencies over time. Include sections for design, development, testing, and launch. Mark critical-path items.
All Mermaid code blocks must use the ```mermaid fence so they render correctly in GitHub, GitLab, and most Markdown viewers.
Every requirement, risk, and trackable item in the PRD receives a unique identifier following this pattern:
PRD-<MODULE>-<NNN>
AUTH, PAY, DASH, NOTIF, ONBRD.Examples: PRD-AUTH-001, PRD-PAY-012, PRD-DASH-003.
This convention ensures IDs are grep-friendly, sort-friendly, and unambiguous across multiple PRDs in the same repository.
Requirements are prioritized using a three-tier system.
When assigning priorities, tie each decision back to the goals defined earlier in the document. If a requirement does not clearly support a stated goal, question whether it belongs in this PRD at all.
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.
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.