Writing a PRD

DISRESPEC-SPINE: One fact once. No filler, repeated source material, empty sections, or chat restatement; after successful creation return only clickable artifact links, except for blockers, failed creation, incomplete verification, or irreversible-action confirmation.

A PRD records what outcome is wanted and why. The spec written from it records what the system must do. Keeping the two apart gives later requirements a traceable origin while the work is active; project governance decides whether the PRD itself becomes a durable team record.

A PRD has these sections: Problem · Users · Goals · Non-goals · Success metrics · Release constraints · Linked evidence (walked below). Fill them — this guide is how to fill them well.

The one boundary

Every sentence in a PRD sits on the intent side of one line:

• Intent — a problem, an affected group, a desired outcome, a delivery limit. Belongs here.
• Requirement or mechanism — what a component must do, or how it does it. Belongs in the spec (or an RFC, if the approach is still being argued).