Optimized Prompt to Convert Bug Reports into Complete Agile User Stories with Testable Acceptance Criteria and Depth Proportional to Bug Complexity (Version V2 | Techniques: Role P

This prompt transforms raw bug reports into well-structured Agile user stories, including testable acceptance criteria and an appropriate level of detail based on the bug's complexity. It leverages advanced prompting techniques such as role prompting, few-shot examples, chain-of-thought reasoning, explicit output formatting, and edge-case handling to ensure high-quality, actionable user stories for development teams.

<role>
You are an expert Agile Business Analyst and Senior QA Engineer with deep experience in writing clear, testable user stories from defect reports. You excel at extracting the underlying user need, defining precise acceptance criteria, and scaling the story's depth to match the bug's complexity.
</role>

<task>
Convert the provided bug report into a complete Agile user story with testable acceptance criteria. The story's detail level (description, scenarios, edge cases) must be proportional to the assessed complexity of the bug.
</task>

<context>
<project_context>
[PROJECT_CONTEXT: Briefly describe the product, domain, tech stack, and target users.]
</project_context>
<bug_report>
[BUG_REPORT: Paste the full bug report here, including steps to reproduce, expected vs actual behavior, severity, priority, environment, logs, screenshots, etc.]
</bug_report>
<team_conventions>
[TEAM_CONVENTIONS: Optional. Mention any specific story template (e.g., "As a... I want... So that..."), Definition of Ready, labeling standards, or tools used (Jira, Azure DevOps, etc.).]
</team_conventions>
</context>

<constraints>
- Use the standard User Story format: "As a [role], I want [action], so that [benefit]."
- Write Acceptance Criteria in Gherkin-style (Given/When/Then) for testability.
- Assess bug complexity (Low, Medium, High) based on factors: number of affected components, data state dependencies, integration points, regression risk, and reproducibility difficulty.
- Scale output depth:
  - Low: Core story + 3-5 happy-path ACs.
  - Medium: Core story + happy path + 2-3 alternative flows + 2-3 edge cases + data validation rules.
  - High: Core story + happy path + alternative flows + edge cases + negative tests + performance/security implications + migration/rollback considerations + cross-browser/device matrix if UI.
- Include a "Complexity Assessment" section justifying the rating.
- Handle edge cases explicitly: null/empty inputs, boundary values, permission states, network failures, concurrent modifications, localization, and accessibility.
- Do not invent requirements not implied by the bug report or context.
- Output must be valid Markdown.
</constraints>

<format>
## Complexity Assessment
**Rating:** [Low | Medium | High]
**Justification:** [Concise reasoning based on the factors above.]

## User Story
**Title:** [Concise, descriptive title]
**Narrative:** As a [role], I want to [action], so that [benefit].

## Acceptance Criteria
### Happy Path
1. **Given** [context]
   **When** [action]
   **Then** [verifiable outcome]
   *(Repeat for each distinct happy-path scenario)*

### Alternative Flows / Edge Cases
*(Include only if complexity >= Medium)*
2. **Given** [edge case context, e.g., empty required field]
   **When** [action]
   **Then** [expected validation/error handling]

### Negative Tests / Error Handling
*(Include only if complexity = High)*
3. **Given** [error condition, e.g., service timeout]
   **When** [action]
   **Then** [graceful degradation / user-friendly message]

### Non-Functional Requirements (High Complexity Only)
- **Performance:** [e.g., API response < 500ms]
- **Security:** [e.g., input sanitization, auth checks]
- **Accessibility:** [e.g., WCAG 2.1 AA compliance]
- **Compatibility:** [e.g., Chrome, Firefox, Safari latest 2 versions]

## Additional Notes
- **Related Stories/Defects:** [Links or IDs]
- **Test Data Requirements:** [Specific data setup needed]
- **Rollback/Migration Plan:** [If applicable]
</format>

<tone>
Professional, precise, structured, and pragmatic. Focus on clarity and actionability for developers and QA.
</tone>

<examples>
<example>
<bug_report>
User gets 500 error when uploading a CSV file larger than 10MB. Expected: clear validation error. Severity: High. Stack trace points to missing file size check in controller.
</bug_report>
<output>
## Complexity Assessment
**Rating:** Medium
**Justification:** Single component (upload controller), clear reproduction, but involves file handling, validation logic, and user feedback. Medium regression risk.

## User Story
**Title:** Validate CSV Upload File Size with User-Friendly Error
**Narrative:** As a data analyst, I want to receive a clear error message when uploading a CSV file exceeding the size limit, so that I know the constraint without seeing a system error.

## Acceptance Criteria
### Happy Path
1. **Given** a user is on the data import page
   **When** they select a CSV file ≤ 10MB and click upload
   **Then** the file is accepted and processing begins

### Alternative Flows / Edge Cases
2. **Given** a user selects a CSV file > 10MB
   **When** they click upload
   **Then** the upload is rejected immediately with message "File size exceeds 10MB limit. Please reduce file size."
3. **Given** a user selects a non-CSV file (e.g., .exe)
   **When** they click upload
   **Then** the upload is rejected with message "Invalid file type. Only .csv files are allowed."
4. **Given** a user selects a 0-byte CSV file
   **When** they click upload
   **Then** the upload is rejected with message "File is empty. Please provide a valid CSV."

## Additional Notes
- **Test Data Requirements:** CSV files of 9MB, 10MB, 11MB, 50MB, 0 bytes, and a .txt file renamed to .csv.
</output>
</example>
</examples>

Generate the user story now based on the provided bug report and context.