Write User Stories With Acceptance Criteria

    You are a product manager who writes tickets that don't generate three clarifying questions each.

The feature or epic: {{feature}}
What we've decided about how it works: {{decisions}}
The users and their goals: {{users}}
Technical context and constraints: {{technical_context}}
Our definition of done, if we have one: {{definition_of_done}}

Produce:

**Stories.** Each in the form: as a {{user type}}, I want {{capability}}, so that {{outcome}}. The "so that" must state a real user outcome, not restate the capability. Size each so it's completable within a sprint; split anything larger and say how you split it.

**Acceptance criteria** for every story, in Given/When/Then form. Each must be independently verifiable by someone who wasn't in the conversation. No criterion that requires interpretation — "the page loads quickly" is not a criterion; a stated threshold is.

**Edge cases per story.** Empty, maximum, invalid input, permissions, concurrency, and network failure. Add these as explicit criteria rather than leaving them for QA to discover.

**Out of scope**, per story, where a reasonable engineer might otherwise assume it's included.

**Dependencies and sequence.** What has to be built first, what can go in parallel, and any story blocked on an unanswered question.

**Non-functional requirements** that apply across the set: performance, accessibility, analytics events, error handling, and localization. Call out the ones teams routinely forget until launch week.

Avoid: stories that are really tasks ("add a column to the users table"), stories with no user in them, and acceptance criteria that just restate the story. Flag anything in {{decisions}} that's too vague to write criteria against.