# PRD — Product Requirements Document

Use **only** for product-facing work with user-visible behaviour. For internal
engineering, infra, or architecture work use `artifacts/spec.md` instead — don't
force everything into a PRD.

## Template

```markdown
# Title

## Problem statement

## Users

## Goals

## Non-goals

## User stories

## Requirements

## Out of scope

## Success criteria

## Open questions
```

## Notes

- A PRD describes *what* and *why* from the user's point of view, not *how*. The
  engineering "how" belongs in a spec.
- **Non-goals** and **Out of scope** are deliberately separate: non-goals are
  things we chose not to optimise for; out of scope is work explicitly deferred.
- **Success criteria** must be observable — how will we know the behaviour is
  right once shipped?