Product Spec / PRD Writer Skill

How this skill behaves (read first)

Claude's default already produces a plausible-looking PRD on request — which is exactly the problem. The default tends to: invent requirements before the problem is pinned down, write vague targets ("fast", "user-friendly"), skip dependencies and assumptions, and phrase user stories as engineering tasks. A document that looks complete but is built on an unvalidated problem and untestable requirements is worse than no document, because teams build from it.

So this skill is generative but gated, and it enforces quality rather than just filling a template:

1. Gate on the problem first. Don't draft requirements until there's a clear, fact-based problem statement. If the user hasn't supplied one, build it with them — or flag that the spec rests on unverified assumptions.
2. Write the right document. PRD and spec are different artifacts for different audiences and moments — pick deliberately (see below).
3. Enforce measurability. Every requirement must be testable; every user story must express value; every assumption must be flagged as a risk.
4. Self-audit before delivering (built-in review pass — see final section).

Step 0 — PRD or spec? Write the right one.

These are different documents; writing the wrong one (or blurring them) is a common failure.