Prompts for writing user stories
Prompts for turning feature ideas into Given-When-Then user stories.
A good user story is deceptively hard. It has to capture who wants something, what they want, and why, then nail down acceptance criteria precise enough that an engineer and a tester read them the same way. AI is well suited to this because it can take a loose feature idea and force it into the disciplined Given-When-Then shape that catches ambiguity before it reaches a sprint.
The prompts here cover the story and everything it connects to. "Write User Stories With Acceptance Criteria" turns feature ideas into clean stories with testable conditions. Around it sit the specs a story implies: a PRD prompt for the larger context, a REST API schema prompt and a database-schema prompt for the technical contract, and "Brainstorm Edge-Case Test Scenarios" for the conditions teams routinely forget. There's even a PR-description prompt for closing the loop when the work ships.
The pitfall is acceptance criteria that sound complete but aren't testable. The model will happily write "the system should be fast" if you let it. Push it for criteria a QA engineer could pass or fail without judgment calls.
What makes a good prompt for writing user stories
A strong user-story prompt insists on the user and the why, not just the feature. "Add a filter" is a task; "as a returning shopper, I want to filter by size so I stop seeing items I can't buy" is a story with a testable point. Give the model the persona and the motivation, and the acceptance criteria almost write themselves.
The best prompts also demand measurable, unambiguous acceptance criteria in Given-When-Then form and ask the model to surface edge cases and open questions. Vague criteria are where sprints go sideways. A prompt that forces every condition to be objectively pass-or-fail is what makes the story genuinely useful to the people building and testing it.
Get sharper results
- 01Always supply the user persona and their motivation. The "so that" clause is what keeps the story anchored to real value instead of drifting into a feature checklist.
- 02Demand acceptance criteria a tester could pass or fail without interpretation. If a criterion needs a judgment call, send it back for a measurable rewrite.
- 03Run the edge-case brainstorming prompt alongside the story prompt so the conditions everyone forgets get written down before, not after, they cause a bug.
- 04For anything with a technical contract, pair the story with the API or database schema prompt so the story and its implementation spec stay aligned.
Common questions
What format should AI use for acceptance criteria?
Given-When-Then is the workhorse: given some context, when an action happens, then a specific, observable outcome follows. The story prompts here default to it because it forces each criterion to be testable. Ask the model to flag any criterion it can't phrase that way, since those are usually hidden ambiguities.
Can AI write user stories for a feature it knows nothing about?
It can structure them, but it can't supply the domain truth. Feed it the persona, the motivation, and any business rules that apply, then let it handle the shaping and the Given-When-Then scaffolding. The more real context you provide, the less it has to guess and the fewer wrong assumptions you'll catch later.
How do I stop my user stories from missing edge cases?
Make edge-case discovery a separate step. After drafting the story, run the edge-case scenario prompt to enumerate boundaries, error states, and adversarial inputs the happy-path story overlooks. Folding those back into your acceptance criteria is the cheapest way to avoid shipping something untested.
Write User Stories With Acceptance Criteria
Turn feature ideas into clean user stories with Given-When-Then acceptance criteria.
Design a RESTful API Endpoint Schema
Design a complete REST API schema with request/response bodies, status codes, and error cases.
Write a Product Requirements Document (PRD)
Generate a complete PRD with goals, requirements, user stories, and open questions.
Write clear API reference docs straight from source code
Generates accurate API reference documentation from source code without inventing behavior, flagging ambiguities.
Turn a diff into a clear, reviewer-friendly PR description
Converts a diff and context into a structured, reviewer-friendly pull request description and title.
Design a normalized database schema from plain requirements
Turns plain-language requirements into a normalized relational schema with DDL, relationships, and trade-offs.
Brainstorm edge-case test scenarios before you write tests
Enumerates grouped edge-case and adversarial test scenarios for a feature so nothing gets shipped untested.