// 01 · what it does

Structure without structured input.

prd-draft takes rough input — a problem statement, notes from a stakeholder conversation, a handful of data points, bullet fragments — and drafts a complete PRD. It imposes structure without requiring structured input. You show up with whatever you have; the skill produces a full spec with context, problem statement, objectives, proposed solution, happy and sad paths, acceptance criteria, data requirements, open questions, and assumptions. The output is a working draft, not a final document — but it's a draft you can actually walk into a room with.

PMs reach for this skill when they have a feature direction but not the discipline to structure it, when a stakeholder conversation produced a clear ask but no artifact, or when a deadline is forcing a spec to exist before the PM has had time to think it through properly. It's also useful as a pressure-test for rough ideas — if the skill can't produce a coherent PRD from your notes, the idea probably isn't ready to take to engineering.

Day 1 is prd-draft rather than doc-review because creating comes before evaluating. On Day 2, you'll review the PRD you produce today — that sequence is more instructive than reviewing a pre-built artifact cold. Starting with production also makes the kit's value immediately tangible: you arrive with notes and leave with a draft spec.

// 02 · sample prompts

Two ways in.

prompt.basic.txt
/prd-draft

I want to add a feature that lets users filter search results by difficulty level. Here's what I know: users are complaining they can't find activities that match their skill level. Some use "beginner" and some use "intermediate" and the terms mean different things. We want to make search results more relevant.
prompt.advanced.txt
/prd-draft

Here's everything I have on the guide listing setup problem. Please draft a full PRD from this.

---

Slack from Jordan Lee (Guide Experience PM), Tuesday:
"Hey — we've been getting a lot of support tickets from guides who sign up and then go quiet. I've been tagging them in Zendesk and it's mostly two things: they don't know how to write a good listing description (what photos, what price, how to describe skill level), and they don't know if anyone will ever book them. We've never built any in-product guidance. Worth a PRD?"

Exit survey verbatims (guides who registered but never published):
1. "I signed up but the setup form felt overwhelming. I didn't know what to put for price — I didn't want to be too expensive or undersell myself. I just gave up."
2. "I looked at other listings after signing up and mine felt bad by comparison. Didn't know how to make it look professional. Left it as a draft."
3. "I started filling out the listing and got stuck on the cancellation policy section. I didn't understand what the options meant for me financially."

Data point from our last quarterly analysis: 38% of guides who register never publish an experience within 30 days. The team's working hypothesis is setup friction and uncertainty about time-to-first-booking, but we haven't done structured discovery.

Ask from Dana Park (VP Product) in OKR review last week: "I want to know what it would take to get guide listing activation from 62% to 75% by end of Q3. That's the number I care about."

Prior investigation (no formal output):
- There's no in-product guidance on pricing — guides set prices without any reference point for comparable listings in their category.
- There's no listing preview that shows what a "strong" listing looks like vs. a draft.

Constraint: Jordan's squad owns the listing object and the guide onboarding flow. Any changes to the listing setup form need their buy-in and coordination on the shared listing object schema.

My ask: draft a PRD targeting the listing setup guidance problem. The audience for this PRD is Jordan Lee (Guide Experience PM), Aisha Nkomo (Guide Experience EM), Chris Okafor (Adventurer Experience EM), and the cross-squad engineering group. I need something I can walk them through next week.
// 03 · reflection

Three questions.

  1. 01Which sections of the PRD did the skill fill in that you hadn't thought about when you started — and do you agree with how it framed them?
  2. 02Where did the skill make assumptions you'd want to revisit before walking engineering through this?
  3. 03What would the PRD have looked like if you had written it yourself from scratch, without the skill? What's different?