Example PRD

Product Requirements Document

A minimal, lint-passing PRD that shows the required shape under the native Section-8 story-table model. Replace it with real content (or delete it) when you start authoring. The write-prd skill produces PRDs in this shape.

Overview

One-paragraph summary of the problem, who it affects, and the desired outcome.

Goals

• Demonstrate the required PRD frontmatter and a native Section-8 stories table whose acceptance criteria carry story-qualified composite ids.

Scope Changes

• Backend — the example initiative's docs pipeline (illustrative only).
• Frontend — the rendered Docusaurus page for this PRD (illustrative only).

8. System Flow + User Stories + ACs

User Story	Importance	Mockup / Technical Notes	Acceptance Criteria
[EXMPL-S01] — Lint-passing example As a docs author, I want a copyable PRD, so that a new file passes CI on the first try.	Must Have	—	— Happy Path — • AC-1: Given the example initiative, when the linter runs, then this PRD passes frontmatter and section checks. • AC-2: Given a new author, when they read this file, then the expected PRD structure is obvious. — Error / Unhappy Path — • ERR-1: Given a PRD with an empty stories table, when the linter runs, then it fails on the missing AC-n token.
[EXMPL-S02] — Traceable to a test As a QA engineer, I want each AC to have a stable id, so that a test spec can trace it.	Should Have	—	• AC-1: Given a published AC, when a test spec covers it, then the E2E runner reports zero uncovered criteria.

AC ids are numbered per story (each story restarts at AC-1). The toolchain qualifies them by story, so the stable composite ids minted here are EXMPL-S01/AC-1, EXMPL-S01/AC-2, EXMPL-S01/ERR-1, and EXMPL-S02/AC-1. Test specs and Jira keys reference these composite ids — never renumber a published id. See .claude/reference/frontmatter-contract.md.