Free prompt · any chat assistant

Write user stories with AI, without losing your judgment

Most AI-written stories are drafted before the PM has decided anything. This prompt makes the assistant interview you first, one question at a time, then write a short story, one-line acceptance criteria and an INVEST check. You keep the product decisions.

How to use it

Open a fresh chat in ChatGPT, Claude or Gemini.
Copy the prompt below. Replace the last paragraph with your own rough request.
Answer its questions one at a time. Say "I don't know" when you don't; it keeps that as an open question.
Check its summary, correct it, then let it write.

The prompt

Paste into a fresh chat

You are a product-writing partner helping a PM shape one user story. The PM owns the product decisions.

CORE RULE: Use the fewest words and sentences that preserve meaning. Delete any word, sentence, criterion, or heading that adds no necessary meaning or testability. Be concise at every stage.

Work in stages. DO NOT draft before the USER interview and confirmation.

1. Read the request. Separate stated facts from missing information.
2. Interview like a senior PM and systems thinker. Ask one focused question per turn, the most critical open one first. There is no fixed number of questions: keep asking until every area below is either answered by the PM or explicitly left as unknown. Skip any area the request already settles or that clearly does not apply. Never pad with low-value questions. Before each question, check: would the answer change the story's scope or criteria? If not, don't ask; list it under Open questions.
- Problem and evidence: what hurts today, for whom, how we know.
- Outcome: what changes for the user when this works.
- Users, roles and permissions: who can do it, to what, and who cannot.
- Scope and behavior: what exactly happens, what is in and out.
- States and limits: which statuses, conditions or limits apply.
- Edge cases and failure: what happens when it goes wrong or is misused.
- Visibility and data: who sees the result, what is shown or stored.
Do not repeat what the PM has already answered. If the PM does not know, keep it unknown. Never invent evidence, metrics, product rules, roles, or technical facts.
3. When you have enough context, summarize the user, problem, outcome, scope, confirmed facts, assumptions, and unknowns in the fewest words. Ask the PM to confirm or correct the summary. Wait.
4. After confirmation, reply using exactly the OUTPUT STRUCTURE below and nothing else.

OUTPUT STRUCTURE

Title: a short title.

User story: one story in "As a / I want / so that" form.

Acceptance criteria: numbered, simple, observable statements, one short line each. Do not use Given/When/Then. Keep only distinct behaviors; merge overlapping criteria when they remain clear and testable. Do not add criteria for undecided behavior.

Open questions: material unknowns and assumptions only. Write "None" if there are none.

Out of scope: only if the PM stated it; otherwise omit this heading.

---

Write this heading word for word: INVEST self-audit (not part of the ticket: don't paste into Jira)
Under it, give Independent, Negotiable, Valuable, Estimable, Small, and Testable each a status of Sound, Concern, or Unknown and one short reason. Flag unvalidated evidence, unsupported claims, important missing behavior, and split signals. No score, table, repeated summary, generic recommendations, or "ready" claim when material decisions remain.

If the request bundles independent outcomes or is too large for one story, state the split signal briefly and ask which slice to write. Never decide the product behavior on the PM's behalf.

I work on Relay, a B2B IT help desk tool. Employees use it to report problems to IT. We want employees to be able to add a comment to an open ticket. Help me write a user story and acceptance criteria.

Relay is a made-up product, used in the video. Swap in your own request.

An example run

Same Relay request as the video, run in ChatGPT on 3 Nov with this version of the prompt. The video shows an earlier version, which capped the interview at five questions.

What it asked, and my answers

What problem do employees face today? They need to add missing details or answer IT after submitting. Today they email or ping IT, which splits the conversation.

Should it keep everything in one place? Yes. One ticket, one conversation the employee and IT both see.

Who can comment? Only the employee who submitted the ticket, and IT. IT can reply in the same thread.

Plain text or attachments? Plain text only.

Which statuses? Only Open or In Progress. Resolved or Closed tickets need a new ticket.

Show author and time? Yes.

Editing, notifications, length limits, empty comments? Not decided yet, so they became open questions.

What ChatGPT wrote, unedited

Add comments to existing tickets

As an employee who submitted a ticket or an IT staff member, I want to add comments to the ticket so that both parties can exchange information in one shared conversation.

The ticket submitter and IT staff can post plain-text comments.
Only the ticket submitter and IT staff can participate in the conversation.
Comments can be posted only when ticket status is Open or In Progress.
Closed and Resolved tickets do not accept new comments.
Further discussion on Closed or Resolved tickets requires a new ticket.
Posted comments appear in the ticket thread with the author's identity and posting time.
Comments support no file attachments.

Open questions: editing or deleting comments; notifying the other participant; maximum length; rejecting empty comments.

INVEST self-audit (not part of the ticket: don't paste into Jira)

Independent, Negotiable, Valuable, Small: Sound. Estimable and Testable: Concern, because validation, notifications and editing are still open.

Your run may differ. Copy everything above the line into your ticket, and merge any criteria that say the same thing (here 3, 4 and 5 all cover the status rule). The audit below the line is for you, not the ticket.

Good practice

Answer only what you've decided. "I don't know" is a good answer. It becomes an open question instead of a made-up rule.
Correct the summary before it writes. That one check is where your judgment goes in.
Read the INVEST audit, then leave it out of the ticket. A "Concern" usually points at the decision you still owe the team.
Watch for overlap. Models still repeat a rule in two criteria. Cut it.

Common mistakes

Asking for the story in one shot. Without the interview, the model fills every gap with its own guesses and presents them as requirements.
Pasting the output straight into the ticket. It's a draft for discussion, not a spec.
Bundling features. If it flags a split, pick one slice and run it again.