create-prd

Overview of create-prd skill

The create-prd skill helps you turn a product idea, feature request, or rough stakeholder note into a structured Product Requirements Document. It is best for product managers, founders, engineers, and AI agents that need a reliable starting point for Requirements Planning rather than a freeform brainstorm. The core value of the create-prd skill is that it pushes you toward a complete PRD shape: problem, audience, success measures, constraints, and release planning.

What create-prd is for

Use create-prd when you need to define what should be built and why before work starts. It is a fit for feature specs, internal RFC-style docs, and PRDs that need enough detail to align engineering, design, and leadership. If your goal is only a short idea summary, this skill is more than you need.

What makes it different

The repository is built around a fixed 8-section PRD template, so the output is meant to be decision-ready rather than exploratory. That helps when stakeholders expect a document they can review, annotate, and implement from. For create-prd for Requirements Planning, the strength is structure: it reduces missing pieces and forces clearer assumptions.

When it is a good fit

Choose this skill if you already have some signal about the product direction and want the document to become more concrete. It is especially useful when inputs include research notes, customer feedback, URLs, or existing product context. It is less useful when the problem itself is still undefined and you need discovery instead of documentation.

How to Use create-prd skill

Install the skill

Use the repo’s install path for create-prd install:

npx skills add phuryn/pm-skills --skill create-prd

After install, confirm the skill folder is available in pm-execution/skills/create-prd and that your agent can load the skill from its local skills directory.

Give it a complete brief

The create-prd usage pattern works best when you provide the minimum inputs the PRD needs to be specific:

• what you want to build
• who it is for
• why now
• known constraints
• any source material, links, or research

A weak prompt like “write a PRD for onboarding” leaves too many blanks. A stronger prompt is: “Create a PRD for a self-serve onboarding flow for SMB admins. Use our interview notes, prioritize activation, and call out analytics, edge cases, and launch risks.” That gives the skill enough context to produce useful sections instead of generic prose.

Read the right files first

Start with SKILL.md, because that is the primary operating guide. If your environment exposes related guidance, also inspect README.md, AGENTS.md, metadata.json, and any rules/, resources/, references/, or scripts/ folders. In this repository, the support surface appears minimal, so the main value comes from understanding the template and adapting it to your own product context.

Work the output into your process

Use the first draft as a working PRD, not a final truth source. Review whether the problem statement, success metrics, and scope boundaries actually match the product decision you need to make. If the draft is too vague, feed back sharper constraints, user segments, or launch goals and ask for a revision focused on those gaps.

create-prd skill FAQ

Is create-prd better than a normal prompt?

Usually yes, if you need a repeatable PRD structure. A normal prompt can produce a decent draft, but create-prd reduces omissions by forcing a consistent planning framework. That matters when multiple people need to review the document or when you want the result to support execution, not just ideation.

Is the create-prd skill beginner-friendly?

Yes, if you can describe the feature in plain language. You do not need formal product-writing experience to use it, but better inputs produce much better outputs. Beginners often benefit most when they start with one clear objective and a few real constraints.

When should I not use it?

Do not use create-prd if you only need a brief announcement, a backlog ticket, or a lightweight brainstorm. It is also not ideal when you have no product direction yet, because the template assumes you can answer basic planning questions. In those cases, discovery or research prompts are a better first step.

Does it fit broader product workflows?

Yes. The create-prd guide works well in workflows that involve design review, engineering scoping, or stakeholder sign-off. It is especially useful when you want an AI assistant to convert scattered notes into a document that can anchor Requirements Planning.

How to Improve create-prd skill

Improve the input, not just the prompt

The biggest quality lever is specificity. Give the skill actual decision inputs: target users, expected behavior, constraints, success criteria, and any known tradeoffs. If you have them, include customer quotes, support tickets, analytics notes, or competitive references so the PRD is grounded in evidence.

Tell it what kind of PRD you need

A PRD for an internal admin tool should not read like a consumer launch doc. State whether you want a concise spec, an exec-ready PRD, or a delivery-oriented planning document. This helps create-prd choose the right depth for sections like scope, stakeholders, and release planning.

Watch for the common failure modes

The most common weakness is generic content that sounds right but does not constrain implementation. Another failure mode is overconfident assumptions about users or metrics. If that happens, ask for a revision that separates facts, assumptions, and open questions, then tighten the scope around what is actually known.

Iterate with targeted revisions

After the first draft, improve one section at a time rather than asking for a full rewrite. For example: “Make the success metrics measurable,” “Add edge cases for enterprise admins,” or “Reduce scope for a two-week release.” That produces better output than broad feedback and keeps the create-prd skill aligned with the planning decision you are making.