Reproduction Step Extraction Prompt for Unstructured Reports

This prompt is designed for triage teams, QA engineers, and support-to-engineering pipelines that receive unstructured bug reports. Users describe symptoms in freeform text: 'the app crashed when I clicked save,' 'login is broken on my phone,' or 'the report shows wrong numbers after the update.' The prompt extracts these descriptions into numbered, ordered reproduction steps. Each step includes the action taken, the expected result, and the actual result observed. The output is structured enough to feed into a test case generator, a bug tracker, or a developer's investigation queue.

Use this prompt when the input is a single bug report and the output must be a sequence of testable steps. The ideal input is a paragraph or short transcript describing what the user did, what they expected, and what happened instead. The prompt works best when the report contains a clear temporal sequence of actions, even if the language is vague or non-technical. It is not designed for batch classification, severity assignment, or duplicate detection. Those are separate triage prompts with different output contracts. Do not use this prompt when the input is a stack trace without user actions, a feature request disguised as a bug, or a report so incomplete that no sequence can be inferred.

Before wiring this prompt into a production pipeline, ensure the upstream intake form or support channel captures enough narrative detail to make step extraction possible. If the input is a one-liner like 'it's broken,' the prompt will produce low-quality or hallucinated steps. Pair this prompt with a completeness check prompt to gate extraction on sufficient input. The output should be validated for step atomicity—each step must describe a single action—and testability before it reaches a developer's queue.

This prompt template is designed to be pasted directly into your system instructions or sent as a user message. It instructs the model to convert vague, freeform user descriptions into a numbered list of atomic, testable reproduction steps. Each step must include the action taken, the expected result, and the actual result observed. The prompt uses square-bracket placeholders that you must replace with real values before execution. The most critical placeholder is [BUG_REPORT], which should contain the raw, unstructured text of the user's issue. The [APPLICATION_CONTEXT] placeholder is where you provide essential domain knowledge, such as the application's name, its core features, and common user flows, which helps the model interpret ambiguous actions like 'I clicked the button.'

textCopy
You are a QA triage engineer. Your task is to extract a precise, ordered list of reproduction steps from an unstructured bug report.

**Input Report:**
[BUG_REPORT]

**Application Context:**
[APPLICATION_CONTEXT]

**Instructions:**
1. Read the entire report to understand the user's goal and the failure.
2. Identify every distinct action the user took, in chronological order.
3. For each action, determine the expected result (what the user thought would happen) and the actual result (what the user observed). If either is not stated, use "Not specified in report."
4. Number the steps sequentially. Each step must be atomic, describing a single action.
5. Ensure the final step clearly describes the failure state.

**Output Format:**
Return ONLY a valid JSON object with a single key "reproduction_steps". The value must be an array of objects, each with the keys "step_number" (integer), "action" (string), "expected_result" (string), and "actual_result" (string).

**Example:**
Input: "I tried to log in with my new password but it just kept spinning. I reset it yesterday."
Output:
{
  "reproduction_steps": [
    {
      "step_number": 1,
      "action": "Navigate to the login page.",
      "expected_result": "Login page loads successfully.",
      "actual_result": "Not specified in report."
    },
    {
      "step_number": 2,
      "action": "Enter email address and the new password reset yesterday.",
      "expected_result": "Successful authentication and redirect to the dashboard.",
      "actual_result": "The page shows a loading spinner indefinitely."
    }
  ]
}

After pasting the template, the primary adaptation is filling the placeholders with high-quality context. For [BUG_REPORT], ensure you include any attached error messages or screenshots as text descriptions. For [APPLICATION_CONTEXT], be specific: instead of 'e-commerce site,' describe 'a B2B wholesale ordering platform where users build carts from a product catalog and submit purchase orders.' This detail prevents the model from hallucinating standard e-commerce features like a shopping cart icon that may not exist in your application. If the bug report is extremely long, consider pre-processing it to remove irrelevant log lines before insertion. The output is strictly JSON, making it suitable for direct ingestion into a ticketing system's API. You should always validate the output against a JSON schema to ensure the array is present and each object contains the required string keys. For high-severity bugs, a human QA lead must review the extracted steps for accuracy before the ticket is assigned to an engineering team.

This prompt is designed to sit inside a bug triage pipeline that receives unstructured user reports and must produce structured, testable reproduction steps before the ticket reaches an engineering queue. The harness should call the model with the raw report text injected into the [BUG_REPORT] placeholder, along with any available [ENVIRONMENT_CONTEXT] such as OS, browser, or app version extracted from the report or user metadata. The [OUTPUT_SCHEMA] placeholder should be populated with a strict JSON schema that defines the expected structure: an array of step objects, each containing step_number (integer), action (string), expected_result (string), actual_result (string), and is_atomic (boolean). The [CONSTRAINTS] field should enforce that each step describes exactly one user action, that steps are ordered chronologically, and that expected vs. actual results are stated per step rather than aggregated at the end.

After the model returns its output, the harness must run a validation layer before the result enters any downstream system. First, parse the JSON and check schema compliance—reject any response missing required fields or containing malformed step objects. Second, apply atomicity checks: if a step's action field contains multiple verbs or conjunctions like 'and then', flag it for decomposition. Third, verify testability by confirming that each action describes a concrete user operation (click, type, navigate, select) rather than an abstract observation. If validation fails, the harness should retry the prompt once with the validation errors appended to the [CONSTRAINTS] field as explicit correction instructions. If the second attempt also fails validation, route the report to a human triage queue with the partial output and error annotations attached. Log every attempt—raw input, model response, validation results, and retry decisions—for prompt debugging and eval dataset construction.

For model choice, prefer a model with strong instruction-following and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro all perform well on this extraction task, but you should run a calibration eval against a golden dataset of 50 manually annotated bug reports before selecting a production model. Measure step-level precision and recall against human-labeled reproduction steps, and track the rate of validation failures that require human escalation. Set a monitoring threshold: if the human-escalation rate exceeds 15% of incoming reports, revisit the prompt template, the validation rules, or the model choice. Do not use this prompt for safety-critical bug reports where incorrect reproduction steps could mask a data-loss or security vulnerability—those reports should always start with human triage regardless of automation confidence.