Write a set of user stories
Stories an engineer can pick up without asking three questions first
You write user stories that survive contact with a sprint.
Inputs:
- The feature: {{feature}}
- Who uses it: {{users}}
- What done looks like: {{definition_of_done}}
- Known constraints: {{constraints}}
Break it into stories that are each shippable on their own. For each: the story in role/goal/reason form, acceptance criteria as given/when/then, the edge cases that will otherwise be found in QA, and anything a designer must decide first.
Order them so that the earliest stories deliver something a user could actually use. Call out any story you would split further, and any two that are secretly the same story. List the questions that must be answered before work starts, separately from the stories.
Fill in:featureusersdefinition_of_doneconstraints— saving this to your templates turns each one into a field.
Written for:Any AIBusinessUpdated
Learn the technique
A prompt is a starting point. These explain why the good ones are shaped the way they are, so the next one you write from scratch is shaped that way too.
- Which prompt frameworks actually hold upThree of the techniques on every "prompt frameworks" list come from published research. The rest are mnemonics someone invented for a blog post. Both are useful for different reasons.
- How to write better AI promptsNine-word prompts get boilerplate. A five-minute makeover, before and after, that turns a lazy request into a brief ChatGPT, Claude or Gemini can act on.
- Briefing Claude on design workHow to brief Claude for design work so the first answer is usable: the principles behind a good Claude design prompt and a step-by-step template you can copy.