## User story **As a** <role> **I want to** <action> **So that** <benefit> ## Context <2–4 sentences explaining when/why this story matters. Reference the PRD section if relevant.> ## Definition of Done A short checklist of what "done" means for this story: - [ ] <Outcome 1> - [ ] <Outcome 2> - [ ] <Outcome 3> ## Acceptance Criteria ### AC1: <Happy path scenario name> ``` Given <initial state> And <additional condition> When <user action> Then <observable outcome> And <additional outcome> ``` ### AC2: <Edge case scenario name> ``` Given <initial state> When <user action> Then <observable outcome> ``` ### AC3: <Error case scenario name> ``` Given <initial state> When <action that triggers error> Then <error message / recovery behavior> ``` ### AC4: <Permission / access scenario name> ``` Given <user without permission X> When <they attempt action Y> Then <denied with reason> ``` ## Out of scope (this story) - <Thing explicitly NOT covered — to prevent scope creep> - <Thing explicitly NOT covered> ## Notes for engineering <Anything that helps eng pick this up — links to designs, similar features, gotchas. Still no code, but architectural pointers OK.> ## Open questions - <Question that needs answer before / during implementation> ``` --- ## Rules for filling this template 1. **One behavior per AC** — if you can't describe it in 1 Given/When/Then block, split into multiple ACs. 2. **At least 1 happy + 1 edge + 1 error case** — unless the story is genuinely trivial. 3. **Observable outcomes only** — "Then user sees X" or "Then system sends Y", not "Then internal state Z is updated". 4. **No UI element IDs** — say "Submit button", not `#btn-submit-form`. 5. **Estimate matches scope** — if estimate is L or XL, consider splitting. 6. **Depends_on only for hard blockers** — if story B is just nice to have B before this, don't list it.

# User Story Template (Compass) Use this template for any story generated by `/compass:story`. One file = one story. --- ```markdown --- id: S title: status: estimate: po: team: created: related_prd: related_epic: depends_on: [, ] --- # Story : ## User story **As a** <role> **I want to** <action> **So that** <benefit> ## Context <2–4 sentences explaining when/why this story matters. Reference the PRD section if relevant.> ## Definition of Done A short checklist of what "done" means for this story: - [ ] <Outcome 1> - [ ] <Outcome 2> - [ ] <Outcome 3> ## Acceptance Criteria ### AC1: <Happy path scenario name> ``` Given <initial state> And <additional condition> When <user action> Then <observable outcome> And <additional outcome> ``` ### AC2: <Edge case scenario name> ``` Given <initial state> When <user action> Then <observable outcome> ``` ### AC3: <Error case scenario name> ``` Given <initial state> When <action that triggers error> Then <error message / recovery behavior> ``` ### AC4: <Permission / access scenario name> ``` Given <user without permission X> When <they attempt action Y> Then <denied with reason> ``` ## Out of scope (this story) - <Thing explicitly NOT covered — to prevent scope creep> - <Thing explicitly NOT covered> ## Notes for engineering <Anything that helps eng pick this up — links to designs, similar features, gotchas. Still no code, but architectural pointers OK.> ## Open questions - <Question that needs answer before / during implementation> ``` --- ## Rules for filling this template 1. **One behavior per AC** — if you can't describe it in 1 Given/When/Then block, split into multiple ACs. 2. **At least 1 happy + 1 edge + 1 error case** — unless the story is genuinely trivial. 3. **Observable outcomes only** — "Then user sees X" or "Then system sends Y", not "Then internal state Z is updated". 4. **No UI element IDs** — say "Submit button", not `#btn-submit-form`. 5. **Estimate matches scope** — if estimate is L or XL, consider splitting. 6. **Depends_on only for hard blockers** — if story B is just nice to have B before this, don't list it.