Prd

Skill ramanbamba/10x-pm/skills/prd

Prompts don't compound. Skills do. The open-source AI toolkit for product managers — 13 Claude Code skills + 3 red-team agents for the full PM workflow.

Install

npx -y skills add ramanbamba/10x-pm --skill prd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Draft a product requirements document (PRD) from a rough idea, feature request, or problem statement. Use when the user says "write a PRD", "spec this out", "draft requirements", "product spec", or shares a feature idea they want documented for engineering and design.

SKILL.md

3.3 KB, as published. Nobody here has run it

PRD Writer

Write PRDs the way strong PMs do: interrogate the idea first, then write the shortest document that lets a team build the right thing.

Before writing anything

Ask the user (in one batch, max 4 questions) whichever of these the request leaves unclear:

Who exactly is this for? Named segment or persona — "users" is not an answer. If they have usage data or research, ask for it.
What breaks if we don't build this? Forces the problem statement to be real. If nothing breaks, flag that before writing.
What's the smallest version that tests the core assumption? Separates v1 from the wishlist.
How will we know it worked, numerically, by when? If they don't know, propose 2–3 candidate metrics and let them pick.

If the user says "just write it," proceed with explicit stated assumptions in an Assumptions block at the top — never silently invent facts.

Workflow

Restate the problem in one sentence from the user's point of view (no solution language in it).
Draft the PRD using the output format below.
Write the Non-goals section with as much care as the goals — this is where scope creep dies.
Mark every claim not backed by user-provided evidence with [assumption].
Self-check against the quality bar. Fix violations before presenting.

Output format

# [Feature name] — PRD
**Status:** Draft · **Owner:** [name] · **Last updated:** [date]

## Problem
[2–4 sentences. Who hurts, how much, evidence. No solution words.]

## Evidence
[Bullets: data points, quotes, ticket volumes. Mark gaps honestly.]

## Goals & success metrics
| Goal | Metric | Target | By when |
|---|---|---|---|

## Non-goals
[What this explicitly does NOT do, and why. Minimum 3 items for any real feature.]

## Solution overview
[The approach in one paragraph, then key user flows as numbered steps.
Reference designs/wireframes if they exist; don't fake them if they don't.]

## Requirements
| # | Requirement | Priority (P0/P1/P2) | Notes |
|---|---|---|---|

## Open questions
[Numbered. Each with an owner and a needed-by date.]

## Risks & mitigations
[Top 3 only. Include at least one risk that isn't technical.]

## Assumptions
[Everything marked [assumption] above, gathered here for review.]

Quality bar — self-check before presenting

Problem statement contains no solution. "Users can't export data" is a problem; "we need an export button" is not.
Every success metric has a number and a date. "Improve engagement" fails; "lift D7 retention of segment X from 22% → 26% by end of Q3" passes.
Non-goals section exists and is specific. An empty or generic non-goals section means the scope conversation hasn't happened.
P0 list is buildable in one release. If everything is P0, nothing is — push back.
No invented data. Every number is either user-provided or marked [assumption].
Two pages max for the core document. If longer, move detail to an appendix.

After presenting the draft, offer to run the pre-mortem or customer-voice agent against it.