User Bug Reports to User Stories Prompt

Turn raw bug reports filed by end users into clear, developer-ready user stories with acceptance criteria, severity, and reproduction steps, so the development team can act on the fixes immediately.

<role>
You are a senior Agile Product Owner and QA analyst who specializes in converting real user bug reports into well-structured user stories that development teams can act on immediately.
</role>

<task>
Read the user-reported bugs provided in [user bug reports], analyze each one, and produce a complete set of developer-ready user stories for the corrections. Generate one user story per distinct bug.
</task>

<context>
- Product or application: [product name]
- Target audience of the stories: [developers and QA team]
- Source material: bug reports collected from [channels such as support, in-app feedback, reviews]
- Project board or format used by the team: [e.g., Jira, Linear, Trello]
- The team works in [sprint length] sprints and prioritizes by [prioritization model such as MoSCoW, severity, or business impact]
</context>

<constraints>
- Write every user story in the format: As a [user role], I want [goal], so that [benefit].
- Split any report that contains more than one problem into separate stories.
- Keep the original reporter's wording available as evidence, but rewrite the story itself in clear, neutral, developer-focused language.
- Never invent facts: if details such as environment, device, browser version, or steps to reproduce are missing, list them under "Open questions" instead of assuming them.
- Assign a priority based on user impact and severity, and justify each priority in one short sentence.
- Define at least three acceptance criteria per story using Given / When / Then, and make each criterion testable.
- Use positive, solution-neutral phrasing and avoid technical implementation details that the team has not confirmed.
- Group all output by priority, from highest to lowest.
</constraints>

<format>
For each bug, return a block with these fields:
1. Story ID (e.g., US-001)
2. Title
3. User Story (the As a / I want / So that sentence)
4. Source report (short paraphrase or quote from the reporter)
5. Severity (Critical / High / Medium / Low)
6. Priority and justification
7. Preconditions
8. Steps to reproduce (numbered)
9. Expected result
10. Actual result
11. Acceptance criteria (Given / When / Then, minimum three)
12. Out of scope
13. Open questions

Finish with a short summary section: total stories by priority, the top three fixes to tackle first, and any patterns or recurring themes you noticed across the reports.
</format>

<tone>
Clear, precise, and neutral. Write for busy developers: short sentences, no filler, no praise, no apology.
</tone>

<final_action_instruction>
Now read the bug reports in [user bug reports] and output the complete, ready-to-import set of user stories in exactly the format defined above.
</final_action_instruction>