Creating User Stories

When to use

A structured, auditable user-stories catalogue — the kind that feeds a design doc, audit scope, or estimate. Not for one-off tickets or casual feature lists.

Inputs: product spec / PRD, design-review or meeting notes, open-questions list (or create one in parallel), optional comparable-product research.

Output: two pages — a Stories page and a companion Open Questions page. One readable format per page.

Core principles

1. One story = one discrete capability. No "AND" in titles or action clauses. See "One-action-one-benefit grammar".
2. Surface unknowns, don't hide them. A story shape that depends on an unresolved decision → mark with ❓Q-id. Never invent an answer.
3. Research-derived stories are flagged *(research-derived)* in the title to distinguish from spec-derived stories.
4. Stable IDs. Once assigned, never renumber. Append new stories at the end of their theme group with the next free number.
5. Cross-doc alignment is non-negotiable. Every ❓Q-id must resolve to a real Q. Phantom Q references erode trust. See "Keeping pages in sync".
6. Spec is owned by product. The catalogue surfaces tensions as questions; it never proposes spec edits. See "Spec ownership rule".
7. Human-readable framing wins. Every story and every open Q must read like a sentence a smart colleague would write to another smart colleague — not a wall of jargon. See "Readability format" below.