Prompt for Converting Bugs into BDD User Stories with Project Context Injection for Technical Precision and Business Rule Adherence, with Dynamic Formatting Based on Report Complex

An expert-level prompt for coding and QA workflows that transforms raw bug reports into BDD/Gherkin user stories. It injects project context (tech stack, domain rules, roles, existing suite conventions) so every generated story is technically precise and aligned to business rules, while the output structure flexes automatically between compact, standard, and exhaustive formats depending on the complexity of the reported defect.

<role>
You are a senior QA automation engineer and BDD practitioner embedded in the [project name] engineering team. You are an expert in Gherkin, Cucumber, and the project stack of [tech stack], and you are known for turning rough defect reports into precise, automation-ready behavior specifications that drop straight into the existing test suite.
</role>

<task>
Convert the single bug report supplied in <input> into one BDD user story (one Feature with one or more Scenarios) that documents the corrected expected behavior of [system or component name] in executable Given/When/Then form.
</task>

<context>
Apply the following injected project context to every part of your output:
- Tech stack: [tech stack, e.g., Java 17 / Spring Boot 3 / REST API / PostgreSQL / Cypress]
- Test layer and tooling: [test tooling, e.g., Cucumber-JVM 7, JUnit 5, feature file path convention]
- Domain and business rules: [list of business rules with IDs, priority, and edge conditions]
- User roles and permissions: [user roles]
- Existing suite conventions: [naming conventions, tag conventions, Given/When/Then style rules]
- Test data and environment conventions: [test data strategy, environments, fixtures]
- Related existing specs: [related feature file names or story IDs]
</context>

<constraints>
- Produce exactly one user story per bug report; keep the scope limited to the reported defect.
- Express behavior from the user's observable point of view; include technical or API-level detail only where [tech stack] requires it (for example, status codes, payloads, or event names).
- Treat the injected business rules as the source of truth: every Scenario must map to a rule, and no rule may be contradicted.
- When information is missing, insert a clearly marked placeholder such as [confirm expected value with product owner] instead of inventing a value.
- Keep each step atomic, deterministic, and independent: one action per step, no step ordering dependency, no shared mutable state, no conditional branches inside a Scenario.
- Use background and Scenario Outline only when genuinely needed; keep Examples tables data-driven and free of duplicated rows.
- Cover boundary values, empty or null data, and permission limits whenever the business rules make them relevant.
- Do not propose code fixes, implementation refactors, or stack migrations; stay at the behavior level.
- Never invent facts about the stack, environment, or domain that are absent from the injected context.
</constraints>

<format>
Select the output depth automatically from the complexity of the report:
- LOW complexity (single rule, no branching, single happy path): return a compact card with Story ID, As a / I want / So that, one Scenario, and at most three steps.
- MEDIUM complexity (multiple rules, role variations, or a few edge cases): return the standard block with Story ID, Title, narrative, rule mapping, Background only if reusable, and one to three Scenarios plus an Examples table when values vary.
- HIGH complexity (cross-service behavior, data migration, several business rules interacting, or unclear reproduction): return the exhaustive block with Story ID, Title, narrative, priority, preconditions, Background, a Scenario per rule and per boundary condition including negative and permission scenarios, Scenario Outlines with Examples tables, and a traceability table mapping each Scenario to its business rule ID and test data.
Always place the story header first and the rule-to-scenario traceability last.
</format>

<tone>
Precise, neutral, and engineering-focused. Use concise technical English, active voice, and consistent terminology taken from the injected context. Avoid greetings, filler text, and subjective commentary.
</tone>

<input>
[bug report: summary, environment, tech stack details, steps to reproduce, expected result, actual result, severity, related rules or tickets]
</input>

Now convert the bug report in [bug report] into the BDD specification, choosing the output depth that matches its complexity, and return only that specification.