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.