Minimal Reproduction Steps Synthesis Prompt

QA engineers and triage leads frequently receive multiple reports describing the same underlying defect: a verbose user complaint in a support ticket, a terse log snippet from an SRE, a screenshot from a product manager, and a partially filled-out bug report from a colleague. Each source contains overlapping, incomplete, and sometimes contradictory information. Manually reconciling these into a single, pruned reproduction procedure wastes time and risks missing critical preconditions or introducing phantom steps that don't actually trigger the defect. This prompt is designed for exactly that situation: when you have two or more bug report sources describing the same symptom and you need one testable, minimal reproduction path that an engineer can execute without further clarification.

The ideal user is a QA engineer, SDET, or triage lead who already has multiple sources open and needs to collapse them into a single actionable defect record. The prompt expects you to provide the raw source texts, any known environment context, and the desired output schema. It will produce a synthesized reproduction procedure with pruned redundant variables, isolated required preconditions, a step-by-step sequence, and a confidence score that tells you whether the output is ready for triage or needs further investigation. The confidence score is critical: it prevents you from shipping a reproduction procedure that silently depends on an unverified assumption from one of the sources.

Do not use this prompt when you have only a single bug report source. In that case, use a single-source extraction prompt such as the Bug Report to Structured Defect Prompt Template or the User Report to Triage-Ready Defect Prompt. Do not use this prompt when the sources describe different defects—synthesis assumes a shared underlying symptom, and forcing unrelated reports together will produce a nonsensical reproduction path. Do not use this prompt for security vulnerability reports where evidence preservation and responsible disclosure handling are paramount; use the Security Vulnerability Defect Report Prompt instead. Finally, if the sources contain contradictory environment details that cannot be resolved without access to the system under test, the prompt will flag low confidence and you should pause synthesis until the contradictions are resolved through direct investigation.

This section provides the core prompt template for synthesizing minimal reproduction steps from multiple bug report sources. The template is designed to be copied directly into your AI harness, with square-bracket placeholders that you replace before sending to the model. Each placeholder represents a required input, constraint, or output specification that controls the synthesis behavior. The prompt instructs the model to prune redundant steps, eliminate unnecessary variables, isolate preconditions, and produce a confidence assessment for each reproduction step.

textCopy
You are a QA engineer synthesizing multiple bug report sources into a single minimal reproduction procedure.

## INPUT SOURCES
[Bug reports, log snippets, user descriptions, screenshots, or other evidence provided as structured or unstructured text]

## CONSTRAINTS
- Produce the fewest steps that reliably reproduce the defect.
- Eliminate any variable, precondition, or action not required for reproduction.
- If a step's necessity is uncertain, flag it with a confidence level.
- Do not invent steps not supported by the input sources.
- If the sources conflict, note the conflict and choose the most reliable source with justification.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "defect_summary": "One-sentence description of the defect",
  "preconditions": [
    {
      "condition": "Required state or setup",
      "source": "Which input source supports this precondition",
      "confidence": "high|medium|low"
    }
  ],
  "reproduction_steps": [
    {
      "step_number": 1,
      "action": "Precise action to perform",
      "expected_result": "What should happen if the defect is present",
      "source": "Which input source supports this step",
      "confidence": "high|medium|low",
      "variable_elimination_note": "Why this step is necessary and what was eliminated"
    }
  ],
  "isolated_variables": [
    {
      "variable": "Variable confirmed as required for reproduction",
      "evidence": "How isolation was confirmed"
    }
  ],
  "eliminated_variables": [
    {
      "variable": "Variable tested and found unnecessary",
      "rationale": "Why it was eliminated"
    }
  ],
  "conflicts": [
    {
      "description": "Conflict between sources",
      "resolution": "How the conflict was resolved",
      "chosen_source": "Which source was prioritized"
    }
  ],
  "overall_confidence": "high|medium|low",
  "missing_information": ["List of details needed to improve reproduction reliability"],
  "clarification_questions": ["Questions to ask the reporter if confidence is low"]
}

## EXAMPLES
[Optional: 1-2 few-shot examples showing input sources and expected output]

## RISK_LEVEL
[low|medium|high - controls how conservative the synthesis should be. High risk requires flagging more uncertainty and requesting human review before accepting the output.]

To adapt this template, replace each placeholder with concrete values before sending to the model. The [INPUT] placeholder accepts any combination of bug reports, log excerpts, user descriptions, or screenshot annotations. The [EXAMPLES] placeholder is optional but strongly recommended for production use—include one or two few-shot examples that demonstrate the expected output shape for your specific application domain. The [RISK_LEVEL] placeholder controls the model's conservatism: set to high for safety-critical or revenue-impacting defects where every step must be verified, or low for internal tools where speed matters more than exhaustive validation. After the model returns output, validate the JSON structure against the schema, check that every step cites a source, and flag any step with low confidence for human review before using it in a test run.

This prompt is designed to be called programmatically within a defect triage pipeline, not as a one-off chat interaction. The primary integration point is after multiple bug reports, log snippets, or user complaints about the same symptom have been collected and linked. Your application should gather these sources into a single [INPUT] payload, structured as a list of objects with source_type (e.g., bug_report, user_email, crash_log), content, and timestamp. The prompt then synthesizes these into a single minimal reproduction procedure, eliminating redundant or irrelevant variables. The output is a structured JSON object containing reproduction_steps, isolated_preconditions, eliminated_variables with justifications, and a confidence_assessment.

To wire this into an application, wrap the prompt call in a function that enforces a strict JSON output schema. Use the model's native JSON mode or structured output feature (e.g., response_format in OpenAI, tool use with a defined schema in Anthropic's API) to guarantee the output shape. After receiving the response, run a validation layer that checks: (1) reproduction_steps is a non-empty array with sequential, imperative steps; (2) each step references only preconditions listed in isolated_preconditions; (3) eliminated_variables includes a reason for each removed element; and (4) confidence_assessment.score is between 0 and 1. If validation fails, retry once with the validation errors appended to the [CONSTRAINTS] field. If the retry also fails, escalate the synthesis to a human QA engineer via a review queue, attaching the original sources and the failed output.

For logging and observability, store the full prompt payload, model response, validation results, and any retry attempts in a structured log. Tag each synthesis with a correlation ID that links back to the source bug reports. This trace is critical for auditing why a reproduction procedure was pruned a certain way and for improving the prompt over time. Avoid using this prompt for safety-critical or security vulnerability reproduction without mandatory human review, as the model may incorrectly eliminate a variable that is essential to triggering a dangerous state. In such cases, set [RISK_LEVEL] to high and route the output to a senior engineer for approval before the reproduction steps are published or automated.