From product-skills
Writes structured, evidence-based PRDs with measurable goals, prioritized requirements, success metrics, and scope boundaries. Use for PRD, product spec, or feature requirements requests.
npx claudepluginhub assimovt/productskills --plugin product-skillsThis skill uses the workspace's default tool permissions.
Write PRDs that are evidence-first, concise, and scannable. A PRD is a thinking tool — if it's longer than 1200 words, the author hasn't thought hard enough. Brief specs are more likely to be read, more likely to be followed, and more likely to ship on time.
Generates a concise 1-2 page structured PRD from product ideas or feature descriptions, resolving ambiguities and enforcing decisions for engineering teams.
Generates Product Requirements Documents (PRDs) with user stories, success metrics, scope, technical considerations, and risks for product features.
Generates structured Product Requirements Documents (PRDs) using proven PM template. Useful for creating, drafting, or helping with PRDs, product specs, feature specs, or product docs.
Share bugs, ideas, or general feedback.
Write PRDs that are evidence-first, concise, and scannable. A PRD is a thinking tool — if it's longer than 1200 words, the author hasn't thought hard enough. Brief specs are more likely to be read, more likely to be followed, and more likely to ship on time.
Follow this structure. Every section is mandatory unless marked optional.
Lead with customer evidence. Quotes, data, support tickets, observed behavior. If you have no evidence, say so explicitly — that's an opinion-driven PRD and should be flagged.
Example:
"3 of 5 interviewed customers abandon onboarding at the team invite step. Average time spent: 47 seconds before closing the tab."
NOT: "Users find onboarding confusing."
Measurable outcomes, not outputs. Each goal has a number attached.
Who specifically benefits. Be narrow. "Series A startup founders doing PM work before their first PM hire" — not "product managers."
Use P0/P1/P2 with clear definitions:
Each requirement is one sentence. If a requirement needs a paragraph to explain, it's too big — break it down.
Numbers. Always numbers. "Reduce X from Y to Z within W weeks."
ALWAYS pair each metric with a counter-metric to prevent gaming:
What you are deliberately NOT building and why. This section prevents scope creep and signals that you've thought about boundaries.
Unresolved decisions that need input. Each question names who should answer it and by when.
Bad P0 requirement:
"The system should handle authentication in a secure and user-friendly manner, supporting multiple providers and edge cases."
Good P0 requirement:
"P0: User can sign up and log in with email + password. Google OAuth is P1."
One sentence. Clear scope. Priority forces a decision.
Built on Linear's "short specs > exhaustive docs" philosophy. Skills from productskills.