User stories

# User stories

Use when defining a new feature or enhancement, to turn a description into stories engineering can estimate and test.

## Definitions

Use these meanings consistently in every step.

- **Feature:** The feature record being broken down, or the feature whose record link the user pasted into the chat
- **User story:** One unit of value stated as a role, an action, and an outcome, small enough to build and test on its own
- **Persona:** A persona record in the workspace, used as the role in each story
- **Acceptance criteria:** The conditions that make a story complete, written so they can be judged without interpretation
- **Vertical slice:** A story that delivers usable behavior end to end, rather than a layer of the implementation

## Workflow

1. Read the feature, its description, its linked ideas, and any existing requirements. Linked ideas carry the customer language that makes stories concrete.
2. Identify the personas involved. Use persona records when they exist. When none exist, name the role in one line and mark it as an assumption.
3. Break the feature into vertical slices. Each story delivers behavior a person can use, not a layer such as the schema or the endpoint.
4. Write each story as "As a <persona>, I want <action> so that <outcome>." The outcome states the benefit, not a restatement of the action.
5. Write acceptance criteria for each story. Cover the primary path, the boundaries, and the permission levels that apply.
6. Sequence the stories. Name which ones are prerequisites for others.
7. Flag anything the feature does not answer, and mark assumptions rather than resolving them silently

## Rules

- If the feature is missing or too thin to break down, ask short follow-up questions before drafting
- Every story is independently valuable. A story that cannot ship on its own is a task, and should be folded into the story it serves.
- The "so that" clause states a benefit. If it restates the action, the story needs rework.
- Acceptance criteria are testable. Avoid "works well" and "is intuitive."
- Reference the feature and any linked ideas by reference number and name
- Do not create requirement records. Present the stories and let the user apply them.
- Headers use sentence case. No em dashes, en dashes, or curly quotes.

## Output

```
## Stories  
### <story title>  
As a <persona>, I want <action> so that <outcome>.  
  
\*\*Acceptance criteria\*\*  
- <condition>  
  
\*\*Depends on:\*\* <story or none>  
  
## Sequence  
1. <story title, and why it comes first>  
  
## Open questions  
- <what the feature does not answer>
```

## Quality checks

- Every story is a vertical slice that could ship on its own
- No "so that" clause restates its action
- Every acceptance criterion can be judged without interpretation
- Dependencies between stories are stated rather than implied by order