prd-generator

name

prd-generator

description

Generate a Product Requirements Document (PRD) as a markdown file. Use this skill whenever the user asks for a PRD, product spec, product requirements doc, feature brief, or wants to "write up" / "draft" / "spec out" a feature or product. Trigger even when the user doesn't say the literal word "PRD" — phrases like "draft a spec for X", "write requirements for the new onboarding flow", or "I need a doc that explains what we're building and why" all qualify.

PRD Generator

Produce a well-structured Product Requirements Document as a markdown file. A good PRD answers three questions for any reader who picks it up cold: what are we building, who is it for, and how will we know it worked? Everything else in the document supports those three answers.

When this skill triggers

Use this skill for any request that boils down to "write a PRD" or "spec out this feature." Common phrasings:

• "Write a PRD for…"
• "Draft a product spec for…"
• "I need requirements for…"
• "Can you write up the new ?"
• "Spec out the onboarding flow"
• "Create a feature brief"

If the user is asking for a technical design doc (architecture, system design, RFC) instead of a product doc, this skill is the wrong fit — defer to a technical-design workflow.

Workflow

1. Gather context

Before writing, work out whether you have enough to produce a useful PRD. Look first at what the user has already given you in the conversation (linked tickets, pasted notes, prior messages, files in the working directory). Pull in any obvious context — for example, if they mention a Jira ticket, check whether you have an Atlassian tool available and skim it.

You need enough information to fill in, at minimum:

• Problem / opportunity — what's broken or missing today
• Target users — who experiences the problem
• Goals — what success looks like at a high level
• Scope — roughly what's in and out

If any of those four are genuinely thin (not just unstated — actually unclear from context), ask the user. Keep it to a short, focused round of questions — three or four at most — rather than a long interview. Tell the user upfront: "I want to ask a few questions before I draft this so the PRD isn't generic — feel free to answer briefly and I'll fill in the rest."

When context is rich, skip the interview and proceed directly to the draft. A PRD generated from a paragraph-long description is more useful to the user than one that took ten back-and-forth questions to produce.

2. Confirm the output path

Ask where the file should be written if the user hasn't specified. The default path is plans/<slug>/prd.md — this lives inside a per-feature directory so downstream skills (tech-design, task-dag, task-specs) can write siblings into the same folder. A short prompt is fine — e.g., "Where should I save the PRD? Default is plans/<slug>/prd.md so the rest of the planning pipeline can hang off the same directory — happy to put it elsewhere if you prefer." If the user gives a directory only, generate a kebab-case slug from the feature name (e.g., plans/team-invitations/prd.md). Honor any explicit path the user provides.

3. Write the PRD

Use the default structure below unless the context strongly suggests a different shape. For example: a tiny bug-adjacent feature might not need a non-goals section; a platform-level initiative might warrant a rollout plan and dependencies section. Adapt thoughtfully — don't pad sections that have nothing meaningful to say, and don't omit sections just because they'd take effort to fill in.

Default PRD structure

# <Feature / Product Name>

**Author:** <if known, else omit>
**Status:** Draft
**Last updated:** <YYYY-MM-DD>

## Summary
2–4 sentences. What is this, who is it for, why now. A reader should be able to stop here and still understand the gist.

## Problem
What's broken, missing, or painful today. Include user-visible symptoms and, where possible, evidence (data, quotes, support tickets, prior incidents). Avoid jumping to solutions.

## Target users
Who experiences the problem. Be specific — segment by role, plan tier, or use case if it matters. If the feature touches multiple personas, list each and what they need.

## Goals
What success looks like. Phrase as outcomes, not features. 3–5 bullets is usually right.

## Non-goals
What this is explicitly **not** trying to do. This section is load-bearing — it's how readers learn what's been scoped out and why.

## Requirements
What the product must do. Group logically (e.g., by user flow, by surface area). For each requirement, capture enough detail that a designer or engineer could ask a sharp clarifying question — not full implementation detail, but enough that the intent is unambiguous. Mark P0 / P1 / P2 if priority matters.

## User experience
Walk through the key user flows in prose or numbered steps. If you have wireframes or mockups, link them. Call out edge cases and empty/error states.

## Success metrics
How we'll know it worked. Each metric should be measurable and have a target or direction. Prefer leading indicators (engagement, completion rate) plus lagging indicators (retention, revenue) where relevant.

## Open questions
Things you don't know yet. Owning the open questions is more credible than papering over them — list them honestly with a proposed path to resolution.

## Risks and mitigations
What could go wrong, and what we'd do about it. Cover technical, user-experience, and business risks where applicable.

## Appendix
Anything that supports the PRD but doesn't belong in the main flow: prior art, related docs, raw research, glossary.

Adapting the structure

Sections to add when the context warrants:

• Dependencies — for cross-team work; list the teams/systems involved and what you need from each
• Rollout plan — when launch is non-trivial (flag gating, phased rollout, migration)
• Pricing / packaging — when the feature affects what customers pay for
• Localization / compliance / accessibility — when those are first-class requirements
• Open design questions — separate from open product questions, when there are real UX decisions outstanding

Sections to omit when they'd be empty:

• Non-goals — fine to drop for very small features, but think hard before you do; an absent non-goals section often hides scope creep
• Risks — drop only when the feature is genuinely low-risk
• Appendix — drop if there's nothing to put there

4. Write the file and surface it

Write to the agreed path using the standard file-writing tools. After writing, tell the user where it lives in one sentence — "Wrote the PRD to plans/team-invitations/prd.md." — and offer a brief summary of what's in it (one or two sentences). If you had to make notable judgment calls (e.g., assumed a specific user segment, made up a metric target), flag them so the user can correct them.

Quality bar

A PRD is a thinking artifact, not a form. The goal is to produce a document that:

• A reader unfamiliar with the work can pick up and understand without further context
• Forces the team to make scope decisions explicit instead of leaving them ambiguous
• Surfaces what's unknown rather than hiding it
• Reads like a human wrote it — concrete, specific, with opinions

Things to avoid:

• Generic boilerplate that could describe any feature ("This feature will improve the user experience")
• Vague requirements ("The system should be fast")
• Success metrics without targets ("Increase engagement" with no number or direction)
• Pretending to know things you don't — open questions are a feature, not a bug
• Implementation detail (database schemas, API contracts) — those belong in a technical design doc, not a PRD

When you draft, write each section as if you were the product manager being graded on it. If a section has nothing meaningful to say, that's a signal to either dig harder for content or to question whether the section belongs.