A User Story Acceptance Criteria Prompt That Locks Given-When-Then

A good user story acceptance criteria prompt does one unglamorous thing well: it returns the same shape every time. The standard "as a persona, wants a goal, for a reason" line on top, then acceptance criteria your QA lead can turn into test cases without rewriting them. Sounds simple. Most prompts don't manage it.

Paste "write a user story for password reset" into ChatGPT and you'll get something usable. Paste it forty times across a sprint backlog and you'll get forty slightly different formats. One story has Given-When-Then, the next has a bulleted checklist, a third buries the criteria in a paragraph. That drift is the real cost, and it's exactly what the listicles skip.

This walks through a reusable prompt that locks the structure, the model quirks that break it, and where it fits in an actual refinement workflow.

What you can do with this prompt

• Turn a one-line feature idea into a properly formed story with a persona and a benefit
• Generate acceptance criteria in Given-When-Then so each clause maps to a test
• Split a fat epic into thin, independently shippable stories
• Add edge-case criteria that engineers usually find in code review, earlier
• Keep every story in one format so the backlog reads consistently
• Hand QA criteria they can lift straight into a test plan

Why the same story comes back in three different shapes

Acceptance criteria are conditional logic written in English. "Given a logged-out user, when they submit a valid email, then a reset link is sent." That maps one-to-one onto a test. The trouble is that models treat format as a suggestion, not a rule, unless you make it one.

The fix is an output contract: a fixed block at the end of the prompt that says exactly what the response must contain and in what order. Without it, you're trusting the model to remember the shape. It won't, especially once the input gets long.

Anatomy of the prompt

Variables
  {{feature_brief}}   — the raw feature idea or ticket text
  {{persona}}         — who the story is for (e.g. "returning customer")
  {{criteria_format}} — "given-when-then" or "checklist"

Prompt
  Role: senior product owner writing refinement-ready stories.
  Task: turn {{feature_brief}} into one user story for {{persona}}.
  Self-check the story against INVEST; if it fails Small or
  Testable, split it and return the split instead.

Output contract (return exactly this, nothing else)
  Story: As a {{persona}}, I want <goal>, so that <benefit>.
  Acceptance criteria ({{criteria_format}}):
    - <clause 1>
    - <clause 2>
    - <clause 3+>
  Out of scope: <one line, or "none">

The {{criteria_format}} variable is the part most templates miss. Conditional stories want Given-When-Then. A copy change doesn't. One prompt should handle both instead of forcing every story into the same mold.

How models behave on this specific job

Here's the part the generic guides skip. Behavior on story writing, not on coding in general:

The takeaway isn't that one model wins. It's that GPT-4o needs the output contract on the final line of the prompt, while Claude tolerates it earlier. Pin whichever you standardize on, and keep an eye on invented criteria. Models will happily write a test for behavior nobody asked for.

1. Gather the brief

Drop the raw ticket or idea into {{feature_brief}}. Messy is fine. A half-sentence from a stakeholder works better than you'd think, because the prompt forces structure onto it.

2. Name the persona

Set {{persona}} to the actual user, not "user." "First-time buyer on mobile" produces sharper criteria than "customer." The benefit clause gets concrete when the persona does.

3. Pick the criteria format

given-when-then for anything with conditional behavior. checklist for flat changes. Don't default to Given-When-Then for a button color change; it reads as ceremony.

4. Run and read the split

If the model split the story, that's the prompt earning its keep. An epic that becomes three thin stories is three things you can actually estimate. Reading the split is faster than catching the same problem mid-sprint.

5. Sanity-check against reality

The model writes plausible criteria, not correct ones. It doesn't know your auth flow or your edge cases. Read every clause as a draft a teammate wrote, because in effect that's what it is.

Variables you'll set

An opinion worth holding

Stop asking the model to write "exhaustive" acceptance criteria. You'll get fifteen clauses, half of them restating the obvious, and refinement turns into a deletion exercise. Ask for the three to five criteria that would actually fail the story if they broke. Tight criteria that map to real tests beat an exhaustive list every time, and they cost fewer tokens. The padding isn't thoroughness. It's noise wearing a thoroughness costume.

A reusable prompt makes this enforceable. You write the contract once, set the cap, and every story respects it. That's the whole argument for a prompt pack over copy-pasting a fresh prompt each time: the rules live in one place, not in your memory.

Getting started

1. Copy the prompt skeleton above into your model of choice.
2. Fill {{feature_brief}} and {{persona}} with one real ticket.
3. Set {{criteria_format}} to match the story's complexity.
4. Run it, read the split if there was one, and edit the criteria for your actual system.
5. Save the filled prompt as your team's template so stories stop drifting in shape.
6. When you're refining a whole backlog, reach for a pack that carries the contract and the ticket-split logic for you, like the Connected Product Requirements Agent Pack.

Once your stories are clean, the next bottleneck is usually the backlog around them. The Backlog Cleanup Agent Pack flags duplicates and stale tickets with a keep/merge/archive verdict, which pairs naturally with sharper stories. For the document those stories roll up into, the writeup on a PRD prompt that holds its structure covers the section-level contract, and the Jira backlog cleanup prompt walks the grooming side.