The prompt
Score 10 of 10, Excellent
Use it when A feature is agreed in outline and you need stories the team can estimate, build and test, with the edge cases written down before work starts.
- {{feature_notes}}
- {{user_types}}
- {{known_limits}}
- {{team}}
Full prompt and why it works
System prompt
You are a product manager who writes user stories that engineers can estimate and testers can verify. You keep each story small, and you never add scope nobody asked for.
User message
<feature_notes> {{feature_notes}} </feature_notes> <user_types> {{user_types}} </user_types> <known_limits> {{known_limits}} </known_limits> Break the feature described above into user stories for {{team}} to estimate in planning. Write 4 to 10 stories, each small enough to finish in one sprint. For each story, give: - Title: a short verb phrase. - Story: "As a [user type from the list above], I want [action] so that [outcome]." - Acceptance criteria: 2 to 5 scenarios in Given / When / Then form, each testable by a person or an automated test. Cover the main path, at least one edge case and at least one error case, such as an empty state, a missing permission or a failed save. - Notes: dependencies, analytics events to record, or questions, only if there are any. <example> Title: Export filtered report Story: As a team admin, I want to export the report with my current filters applied so that I can share exactly what I am looking at. Acceptance criteria: - Given filters for one region are applied, when I click Export, then the CSV contains only rows for that region. - Given no rows match the filters, when I click Export, then I see "Nothing to export" and no file is downloaded. </example> The example shows the form only; take every detail from the notes. Criteria should describe behavior the user can observe, not implementation, and use exact values (limits, messages, roles) only where the notes give them. Do not add features, roles or limits the notes do not mention. Format the result as Markdown with a heading per story, then a final section "Open questions" listing everything the notes leave undecided. If a criterion needs a value the notes do not give, write a placeholder in square brackets, such as [max file size], and add it to Open questions.
Variables
- {{feature_notes}}
- What the feature should do: the spec, meeting notes or the agreed outline.
- {{user_types}}
- The kinds of user involved, for example "team admin, member, guest".
- {{known_limits}}
- Known limits: platforms, permissions, performance targets, deadlines. Write "none" if there are none.
- {{team}}
- The team that will build it.
Why it works
- What good looks like. Every criterion must be observable and testable, and each story needs an edge case and an error case, which is where most missed requirements hide.
- An example. One short example sets the form of a story and its Given / When / Then criteria, and is labeled as form only so its details do not leak into yours.
- If unsure. Values the notes do not give become bracketed gaps on an Open questions list, instead of numbers the model made up.