Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From pm-skills
Generates Product Requirements Documents covering problem summary, goals and metrics, solution outline, functional requirements, scope boundaries, technical considerations, dependencies, risks, and timeline for engineering handoffs on features, epics, or initiatives.
npx claudepluginhub product-on-purpose/pm-skills --plugin pm-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/pm-skills:deliver-prdThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
Generates a complete engineering-ready PRD with problem statement, user personas, MoSCoW features, success metrics, and implementation timeline.
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).
Create structured Product Requirements Documents (PRDs) that connect problem, users, solution, and success criteria. Use when turning discovery notes into engineering-ready documents.
Share bugs, ideas, or general feedback.
A Product Requirements Document is the primary specification artifact that communicates what to build and why. It bridges the gap between problem understanding and engineering implementation by providing clear requirements, success criteria, and scope boundaries. A good PRD enables engineering to build the right thing while maintaining flexibility on implementation details.
When asked to create a PRD, follow these steps:
Summarize the Problem Start with a brief recap of the problem being solved. Link to the problem statement if available. Ensure readers understand why this work matters before diving into what to build.
Define Goals and Success Metrics Articulate what success looks like. Include specific, measurable metrics with baselines and targets. These metrics should connect directly to the problem being solved.
Outline the Solution Describe the proposed solution at a high level. Focus on user-facing functionality and key capabilities. Include enough detail for stakeholders to evaluate the approach without over-specifying implementation.
Detail Functional Requirements Break down what the system must do. Use user stories or requirement statements. Each requirement should be testable . someone should be able to verify if it's met.
Define Scope Boundaries Explicitly state what's in scope, out of scope, and deferred to future iterations. Clear scope prevents scope creep and sets realistic expectations.
Address Technical Considerations Note any technical constraints, architectural decisions, or integration requirements. Don't design the system, but surface considerations engineering needs to know.
Identify Dependencies and Risks List external dependencies, assumptions, and risks that could impact delivery. Include mitigation strategies where applicable.
Propose Timeline and Milestones Outline key phases and checkpoints. This helps stakeholders understand the delivery plan without committing to specific dates prematurely.
Use the template in references/TEMPLATE.md to structure the output.
Before finalizing, verify:
See references/EXAMPLE.md for a completed example.