# User story

## User need

Name who benefits, what they need to be able to do, and the value they get. Don't name a technology you want to use.

As a **[specific user]**, I want **[small ability]** so that **[visible value]**.

## Context

Give only the facts needed to understand the problem right now. This teaches you to keep scope small and privacy tight.

[What problem exists now? Include only details that are safe to share.]

## Clarifying questions

Ask about anything unclear that could change the behavior, the limits, or what counts as done. Don't hide an assumption in the code.

1. [Question]
2. [Question]
3. [Question]

## Acceptance criteria

Acceptance criteria are the checklist that says when a story is done. Each item is an example you can see. Include one normal case and one edge or error case.

- [ ] Given **[starting state]**, when **[action]**, then **[visible result]**.
- [ ] Given **[edge or error state]**, when **[action]**, then **[visible result]**.
- [ ] [A security, privacy, accessibility, or speed rule that matters for this slice.]

## Non-goals

Say what this slice leaves out on purpose. That keeps "small" real during the Sprint (one week of planned work).

- [What this story does not include, on purpose.]

## Proof

Link the need to the reviewed change and its test or demo result.

- Issue:
- Pull request:
- Test/CI run:
- Demo, or your own short explanation:

---

## About this template

A user story describes one small thing a user needs, and how you will know it is done. Anyone should be able to read the filled-in story and test it without reading the code.

> **What this teaches:** I can turn a user need into one small, testable slice without deciding the code too early.

Before you write, guess the smallest visible thing the user needs. After you write, ask: would two different readers test the same behavior?

A GitHub Issue is a to-do card for one piece of work. Use this template in the Issue that the current block tells you to create in `java-gradebook-cli`. The block tells you the Issue's purpose and the private proof file before it asks you to write. Save the Issue, reopen it, and check that the story and the checklist are there before you create a branch.

**Explain it back:** Explain the value to the user and one reading of the story you rejected. Then explain how someone could check each checklist item without reading the code.

**Delete this whole section once you have filled the document in.** What is left should read as a finished document on its own.