authoring-user-stories

# Authoring User Stories

**Violating the letter of the rules is violating the spirit of the rules.**

## Overview

Transform feature descriptions into testable user stories with clear business value, prioritized by impact. Each story MUST be independently testable with measurable acceptance criteria.

This is a discipline-enforcing skill. The structured format exists to ensure stories are unambiguous, testable, and properly prioritized. Shortcuts create ambiguous requirements that cause implementation failures.

## When to Use

- Transforming feature descriptions into testable requirements
- Breaking down large features into prioritized, independent stories
- When acceptance scenarios need Given/When/Then structure
- Creating backlog items with clear verification criteria
- When stakeholders need to understand what "done" means

## When NOT to Use

- **Technical implementation tasks** - Use task decomposition instead
- **Bug reports** - Use issue templates with reproduction steps
- **When requirements are already in user story format** - Don't duplicate work
- **Architecture decisions** - Use `humaninloop:patterns-technical-decisions` instead
- **API contract design** - Use `humaninloop:patterns-api-contracts` instead

## User Story Format

Generate 2-5 user stories per feature using this exact structure:

```markdown
### User Story N - [Brief Title] (Priority: P#)

[Describe this user journey in plain language]

**Why this priority**: [Explain the value and priority level]

**Independent Test**: [How this can be tested standalone]

**Acceptance Scenarios**:
1. **Given** [state], **When** [action], **Then** [outcome]
2. **Given** [state], **When** [action], **Then** [outcome]
```

## Priority Definitions

| Priority | Meaning | Criteria |
|----------|---------|----------|
| **P1** | Core functionality | MVP requirement, blocks other features, must ship |
| **P2** | Important | Complete experience but can ship without initially |
| **P3** | Nice to have | Enhances e