Skip to main content
A PRD (Product Requirements Document) is the root of a plan. Created with:
which writes docs/prd/my-initiative/prd.md (plus an empty features/ directory) with the frontmatter filled in:

​
Body sections

The CLI scaffolds a minimal body — ## Purpose and Goals and ## Features — and the rest is prose you add. A strong PRD typically carries:
  • Purpose and Goals — the problem and the outcomes that mark it done.
  • Key Decisions — choices made up front, with the reasoning (so a future session doesn’t re-litigate them).
  • User Stories — who benefits and how, in as-a/I-want form.
  • Release Criteria — the testable bar for calling the PRD shipped.
  • Testing Strategy — how the work will be verified, including which parts have no test surface (and therefore run with RED skipped).
  • Features — a linked list of the feature files.
  • Out of Scope — deliberate exclusions, named so they read as decisions.

​
Status lifecycle

status: moves not_started → in_progress (first feature underway) → completed (every feature completed). The PRD’s status is yours to update in the frontmatter as features land; re-sync afterwards:
Each feature lives in its own file under features/ — their shape is next.