User story prompt (copy-paste, with acceptance criteria)

A free, copy-paste user story prompt that turns a feature into well-formed user stories with acceptance criteria — paste it into a sfora post or hand it to your agent.

By Thijs Verreck · Published Jul 20, 2026

Here is a copy-paste user story prompt you can use right now. Paste it into a sfora post, or hand it to your AI agent, describe a feature in a sentence or two, and you get back well-formed user stories — each in the "as a, I want, so that" shape, each with acceptance criteria you can actually test. The output is a markdown file on your board, ready to turn into tasks.

This is one of the prompts in our AI prompts guide. It pairs naturally with the PRD prompt — stories are the section a PRD lives or dies on — and with the product spec prompt. For the background on writing requirements with AI, see the AI PRDs guide.

The prompt

Copy this block, paste it where you draft, and replace the bracketed parts.

User story prompt
You are helping me break a feature into user stories with acceptance criteria.

Here is the feature:

- **Feature:** <one or two sentences on what we are building>
- **Roles involved:** <who uses it — e.g. member, admin, agent>
- **Constraints:** <anything that limits scope — permissions, platform, edge cases>

Write the output as a markdown list of user stories. For each story:

1. Write it as: **As a <role>, I want to <action> so that <outcome>.**
2. Keep it small — one role, one action, one reason. If a story has two actions,
   split it into two stories.
3. Under each story, add an **Acceptance criteria** list of 3–5 checks. Write
   each one so it is clearly pass or fail. Given-when-then is fine: "Given X,
   when I do Y, then Z."
4. Include the boring but important cases: empty state, error state, and
   permissions.

Rules:
- No vague criteria. "It should be intuitive" is banned. Every criterion must be
  something a person or an agent could verify.
- Order the stories so the smallest, most essential one comes first.
- If a story is out of scope for a first version, put it under a **Later**
  heading instead of dropping it.
- Do not invent requirements I did not describe. If something is unclear, add a
  `<!-- QUESTION -->` note.
Run it:paste into a sfora postorhand it to your agent · CLI + MCP

Running it in sfora

You do not have to leave your workspace to use this. In sfora, a post is a markdown file, so the stories land in the same place as the tasks they become.

There are two ways to run it:

  • Paste it into a post. Open a new post, paste the block, describe your feature, and hand it to the agent in that thread. It replies with the stories and criteria, right there.
  • Hand it to your agent over the CLI. If you drive an agent like Claude Code, Cursor, or the sfora CLI over MCP, give it the same prompt and point it at the board. It writes the stories as a file, and from there each story can become a task.

Either way, the result is a real markdown file on your board — one a person can edit and an agent can pick up.

What the output looks like

Give the prompt a feature and a couple of roles, and you get back something like this:

## Stories: task due dates

### As a member, I want to set a due date on a task so that I know when it is expected.

**Acceptance criteria**
- Given an open task, when I click the due-date field, then a date picker opens.
- Given I pick a date, when I close the picker, then the date shows on the task.
- Given a task with no due date, then the field reads "No due date" and is not an error.
- Given I lack edit permission on the task, then the due-date field is read-only.

### As a member, I want to see overdue tasks stand out so that I notice them.

**Acceptance criteria**
- Given a task whose due date is in the past and is not done, then its date shows in red.
- Given a task that is done, then a past due date does not show as overdue.
- Given a task due today, then the date reads "Today" rather than the full date.

### Later

### As a member, I want a reminder before a task is due so that I don't forget.
<!-- QUESTION: in-app, email, or push? Out of scope for v1. -->

See what it did: split one feature into small, buildable stories, wrote criteria you can check off, covered the empty and permission cases, and parked the reminder idea under Later instead of quietly expanding scope. That is the prompt doing the tedious part so you can decide what actually ships.

Turning stories into tasks

Well-formed stories are already most of a task list. Once the prompt gives you the stories, the acceptance criteria become the definition of done:

  • Each story is a candidate task. Small stories map cleanly to small tasks.
  • The criteria are the checklist. Drop them into the task and you know exactly when it is finished.
  • The <!-- QUESTION --> notes are decisions to make. Resolve them before you start building, not halfway through.

This is also what makes stories readable by an AI agent. When a coding agent picks up a task, the acceptance criteria tell it what "done" means without a conversation — which is why writing them as pass-or-fail checks matters more than ever.

How to get sharper stories

The prompt's output tracks the quality of your input. To get better stories:

  • Name the real roles. "Member, admin, and agent" gives the AI something to work with. "The user" flattens everything into one story.
  • State the constraints up front. Permissions and platform limits shape the criteria. If you leave them out, the AI writes a happy-path story and misses the edge that bites you.
  • Keep the feature to a sentence. A tight feature description produces tight stories. A paragraph of context produces a sprawl you have to trim.

Where sfora fits

sfora is a project workspace where humans and AI agents are members of the same team, and everything — tasks, docs, posts — is a markdown file. That is what makes this prompt more than a chat trick.

When you run the user story prompt in sfora, the stories are a real file on your board. A person edits them and turns each into a task; an agent that is a member of the same workspace can read the same file, pick up a task, and build against the acceptance criteria you wrote. The stories are not a copy pasted out of a chatbot — they are the instructions the work runs on.

Want the doc these stories live inside? Use the PRD prompt to draft the full spec, and browse the full set in the AI prompts guide.

Frequently asked questions

What is a good user story format?
The classic format is "As a <role>, I want to <action> so that <outcome>." One role, one action, one reason. If a story needs three clauses, it is probably two stories. Keep them small enough to build and test on their own.
How do you write acceptance criteria for a user story?
Write each criterion as a pass or fail check. "The save button is disabled until a title is entered" is testable. "Saving should feel smooth" is not. Given-when-then works well: given a state, when I do something, then this happens. Aim for three to five per story.
Can AI write user stories from a feature description?
Yes, and it is one of the things AI is best at. Give it the feature, the roles involved, and any constraints, and it will split the work into small stories and draft acceptance criteria — including edge cases you would have missed. You still trim and decide scope.

Build it in sfora

From PRD to shipped, in one place. Your agents work the board over the CLI and MCP; you steer. Every task, post, and doc is a markdown file.