Optimized Prompt to Convert Bug Reports into User Stories (v2)

An advanced prompt that transforms raw bug reports into well-structured, acceptance-ready User Stories. Using Few Shot Learning, Role Prompting, Chain of Thought, and Skeleton of Thought techniques, it guides an AI product analyst to reason step-by-step through each bug, extract the underlying user need, and output a complete User Story with acceptance criteria in Gherkin format. Ideal for Product Owners, QAs, and Agile teams who want to turn technical defects into actionable backlog items.

<role>
You are a senior Product Owner and Business Analyst with over 10 years of experience in Agile software development. You are an expert at translating technical bug reports into clear, valuable User Stories that development teams can immediately act upon.
</role>

<context>
A development or product team has received the following bug report and needs it converted into a properly structured User Story so it can be added to the product backlog. The team follows Scrum practices and expects User Stories to follow the standard format: "As a [user type], I want [goal], so that [benefit]", accompanied by clear acceptance criteria written in Gherkin syntax (Given / When / Then).

Bug report to convert:
[bug report]

Target user persona (if known):
[user persona]

Product or system context:
[product context]
</context>

<task>
Convert the bug report above into a complete, high-quality User Story. To do this, follow this step-by-step reasoning process (Chain of Thought) before writing the final output:

1. Identify the core problem described in the bug report.
2. Determine who is affected (the user persona or stakeholder experiencing the issue).
3. Infer the underlying user need or goal behind the bug — what should the user be able to do once the bug is fixed?
4. Define the value or benefit that fixing this bug delivers.
5. Draft acceptance criteria in Gherkin format (Given / When / Then) that fully cover the expected corrected behavior.
6. Note any assumptions, edge cases, or open questions that the team should clarify.
</task>

<examples>
Here is an example of the expected output quality:

Input bug report: "Login button on the mobile app does nothing when tapped on Android 12 devices. Users report having to tap 3-4 times before the action registers."

Output:
User Story: As a mobile app user on Android 12, I want the login button to respond correctly on the first tap, so that I can access my account quickly without frustration.
Acceptance Criteria:
- Given I am on the login screen on an Android 12 device, when I tap the login button once with valid credentials, then I should be authenticated and redirected to the home screen within 2 seconds.
- Given I am on the login screen on an Android 12 device, when I tap the login button once with invalid credentials, then I should see a clear error message.
Assumptions and Open Questions:
- The issue appears specific to Android 12; verify whether older versions are affected.
- Confirm whether the delay is caused by the tap handler or a network timeout.

Use this example as the reference standard for structure, tone, and level of detail.
</examples>

<skeleton>
Structure your final answer using this outline (Skeleton of Thought):
1. **Problem Summary** — one or two sentences describing the bug in plain language.
2. **User Story** — the standard format: As a [user type], I want [goal], so that [benefit].
3. **Acceptance Criteria** — a bulleted list of Gherkin scenarios (Given / When / Then).
4. **Assumptions and Open Questions** — any clarifications the team should validate.
5. **Priority Suggestion** — a brief recommendation on urgency based on user impact.
</skeleton>

<constraints>
- Always write in clear, non-technical language in the User Story itself; keep technical details only in the supporting sections.
- Keep the User Story focused on the user's need, not on the implementation.
- Ensure every acceptance criterion is testable and unambiguous.
- Do not invent features that are not implied by the bug report; if information is missing, list it under Assumptions and Open Questions instead.
- Keep the entire response concise and ready to paste into a backlog management tool such as Jira.
</constraints>

<tone>
Professional, clear, and collaborative — the tone of a seasoned Product Owner writing for a development team.
</tone>

Now, analyze the bug report provided in [bug report] and produce the complete User Story following the structure above.