How to use the create-prd agent skill to write a PRD

What the create-prd skill makes the agent do

The skill tells the agent to act as an experienced product manager and write a lean PRD: about one to two pages, or roughly 600 to 1,000 words. The lean version is the default. A fuller spec is written only when you ask for one.

The document follows an 8-section template: Summary, Contacts, Background, Objective, Market Segment(s), Value Proposition(s), Solution and Release. Market Segments and Value Propositions are always included. Each value proposition uses a 6-part template (Who, Why, What before, How, What after, Alternatives).

Before writing, the skill asks you for missing key facts such as the problem, the target users and how success will be measured. It can research the market, competitors and alternatives on the web. Anything it could not confirm is marked as an assumption rather than stated as fact.

• Summary, Contacts, Background, Objective
• Market Segment(s) and Value Proposition(s), using the 6-part template
• Solution (UX, key features, technology, assumptions and open questions)
• Release: what is in the first version, what comes later, and what is not being done

Install the create-prd skill

Download the ZIP for the skill from this page. The skill is made of a single file, SKILL.md. To install it for Claude Code, unzip it into your personal skills folder ~/.claude/skills/, or into a project's .claude/skills/ folder if you want it only for that project.

To use it in the Claude apps instead, upload the skill under Settings → Capabilities → Skills.

• Personal install: unzip into ~/.claude/skills/
• Project install: unzip into the project's .claude/skills/ folder
• Claude apps: Settings → Capabilities → Skills, then upload

Trigger the skill with natural requests

You do not need a special command. Describe the task in plain words. The skill's description lists the situations it is meant for: writing a PRD, documenting product requirements, preparing a feature spec, or reviewing an existing PRD.

Give the agent the product or feature, the problem it solves and who it is for. If you have notes or files, attach or name them so the agent can read them first.

• "Write a PRD for a feature that lets our clients export invoices as CSV."
• "Draft a feature spec for onboarding reminders aimed at small team admins."
• "Review this existing PRD and tell me what is missing and what I could cut."
• "Document the product requirements for our new mobile checkout flow."

What to expect from the output

The agent first asks up to three short questions if the problem, target users or success measure is missing. Answer them, or tell the agent to go ahead, in which case the gaps are marked as assumptions.

The skill asks for the output to be saved as a markdown file named PRD-[product-name].md. In its reply, the agent also lists what it left out on purpose, such as a competitive analysis or a detailed rollout plan, so you can ask for any of it.

When you review an existing PRD, the skill returns the gaps first and then the cuts.

• Clarifying questions come before the PRD if key facts are missing
• The PRD is saved as PRD-[product-name].md
• Assumptions are listed in section 7.4 and marked clearly

What the skill needs and safety notes

The listing shows no required tools or packages. The skill does not run scripts. It does use the network, because it can search the web for market, competitor and regulatory information when that helps the PRD.

Treat the research as a starting point. The skill gives product-planning guidance and does not check facts against authoritative sources, so verify any market figure or claim before you circulate the document.

• Runs scripts: no
• Uses network: yes, for web research
• Requires: nothing listed

Tips for better PRDs

Give the agent real evidence. A number or a named user group produces a sharper document than an adjective. The skill's notes say the same thing.

Check that the value proposition and the solution match. The Solution should deliver the How in each value proposition, and the Key Results should measure the What after. If they do not line up, fix that first.

Ask for the detailed version only when the lean one is not enough to decide.

• Focus the first version on two or three segments at most
• Name non-goals: say what the first version will not do
• Ask the agent to mark assumptions so the team can validate them