Bug Report to Structured Defect Prompt Template

This prompt is designed for QA engineers, support-to-engineering handoff teams, and triage leads who need to convert a raw, unstructured bug report into a structured, actionable defect record. The job-to-be-done is reducing the back-and-forth clarification that slows down defect triage by producing a complete, standardized defect description from the first pass. The ideal user has access to the original report, any attached screenshots or logs, and enough product knowledge to validate the model's inferences about severity and environment. The required context includes the raw bug report text, any available system environment details, and the target defect tracking system's field schema so the output can be mapped directly into Jira, Azure DevOps, or a similar tool.

Do not use this prompt when the bug report describes a security vulnerability that requires responsible disclosure handling, when the report contains personally identifiable information (PII) that cannot be sent to a model, or when the defect involves complex multi-service interactions that require architecture diagrams to understand. This prompt is also inappropriate for performance defects that need precise metric baselines or for intermittent issues where reproduction steps cannot be inferred from a single report. In those cases, use the specialized sibling prompts for security, performance, or flaky behavior defects instead. The prompt assumes the input is a single, coherent bug report; if you are synthesizing multiple reports into one defect, use the Minimal Reproduction Steps Synthesis prompt.

Before wiring this prompt into a production triage pipeline, establish a human review step for severity and priority classification. The model can propose these fields, but misclassification can route critical defects to the wrong SLA queue. Also validate that the generated reproduction steps can actually be followed by a tester unfamiliar with the issue—if the steps reference UI elements ambiguously, flag the defect for manual enrichment. The next section provides the copy-ready template you can adapt to your defect schema and severity taxonomy.

This template is the core instruction set you will send to the model. It is designed to be copied directly into your prompt management system, IDE, or orchestration code. Every variable is enclosed in square brackets and must be replaced at runtime by your application layer. The template forces the model to produce a predictable JSON output with fields essential for QA triage: title, severity, environment, reproduction steps, observed versus expected behavior, and an attachments summary. It also includes a self-evaluation block that asks the model to flag missing information and assess reproduction confidence before returning the final object.

textCopy
You are a QA defect triage assistant. Your task is to convert the raw bug report below into a structured defect record.

## INPUT
[Bug Report Text]

## CONSTRAINTS
- Do not invent details not present in the input. If information is missing, mark it as "UNKNOWN" and flag it in the `missing_information` field.
- Use the exact severity levels: BLOCKER, CRITICAL, MAJOR, MINOR, TRIVIAL.
- Reproduction steps must be numbered, atomic actions that a new team member could follow.
- The `observed_behavior` and `expected_behavior` fields must be direct quotes or tight paraphrases from the report when available.
- If the report includes references to screenshots, logs, or attachments, summarize them in the `attachments_summary` field.

## OUTPUT_SCHEMA
Return ONLY valid JSON matching this schema:
{
  "defect_id": "string (generate a unique ID with prefix BUG-)",
  "title": "string (concise, descriptive summary)",
  "severity": "BLOCKER | CRITICAL | MAJOR | MINOR | TRIVIAL",
  "environment": {
    "os": "string | UNKNOWN",
    "browser": "string | UNKNOWN",
    "device": "string | UNKNOWN",
    "app_version": "string | UNKNOWN",
    "additional_context": "string | UNKNOWN"
  },
  "reproduction_steps": [
    {
      "step_number": number,
      "action": "string",
      "expected_result": "string | UNKNOWN"
    }
  ],
  "observed_behavior": "string",
  "expected_behavior": "string",
  "attachments_summary": [
    {
      "reference": "string (filename or description from report)",
      "relevance": "string (what the attachment shows)"
    }
  ],
  "missing_information": ["string (list of fields or details not provided in the report)"],
  "reproduction_confidence": "HIGH | MEDIUM | LOW",
  "clarification_questions": ["string (questions to ask the reporter if confidence is LOW or MEDIUM)"],
  "triage_notes": "string (any additional observations for the triage team)"
}

## EVALUATION CRITERIA
Before returning the JSON, verify:
1. Every reproduction step is atomic and executable by a new team member.
2. Severity is justified by the observed impact described in the report.
3. All `UNKNOWN` fields are explicitly listed in `missing_information`.
4. `reproduction_confidence` reflects how complete the reproduction steps are.
5. No invented details appear outside of `triage_notes` (and those must be labeled as assumptions).

## RISK_LEVEL
[HIGH | MEDIUM | LOW]
- If HIGH: add a `human_review_required: true` field and flag any safety, security, or data-loss implications.
- If MEDIUM: add a `human_review_recommended: true` field and note areas needing verification.
- If LOW: proceed with automated triage.

To adapt this template, replace each bracketed placeholder with values from your application context. The [Bug Report Text] placeholder should receive the full, unedited text from the user's report, support ticket, or log snippet. The [RISK_LEVEL] placeholder should be set by your application logic based on the source of the report (e.g., production crash reports are HIGH, minor UI glitches from internal testing are LOW). If your defect tracking system uses different severity labels or environment fields, adjust the enum values and schema keys accordingly, but preserve the square-bracket placeholder pattern for any runtime-variable sections. The evaluation criteria block is designed to work as a self-check; if your model tends to skip it, move those checks into a separate validation prompt in your harness.

This prompt is designed to sit inside a defect intake pipeline—typically a webhook, support bot, or internal QA tool that receives raw bug reports and needs to produce a triage-ready defect record. The implementation harness should treat the LLM call as a transformation step, not a final destination. After the model returns structured JSON, the application must validate the output against the expected schema, check for completeness flags, and decide whether the result is confident enough to auto-create a ticket or whether it should be routed to a human for review. The prompt template itself uses placeholders like [RAW_BUG_REPORT], [PRODUCT_CONTEXT], and [SEVERITY_GUIDELINES] that your application must populate from upstream sources before invoking the model.

Wiring the prompt into an application starts with a function that assembles the final prompt string by injecting the raw bug report text, any known product area or component context, and your organization's severity classification guidelines. Choose a model that reliably produces structured JSON—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro with response_format or tool-calling mode enabled. Set temperature low (0.0–0.2) to reduce creative drift in severity classification and reproduction step ordering. After receiving the model response, run a validation layer that checks: (1) all required fields are present and non-null, (2) severity and priority values match your allowed enum, (3) reproduction steps contain at least one actionable step with a concrete action verb, and (4) the observed-vs-expected behavior fields are distinct and non-trivial. If validation fails, retry once with the validation errors appended to the prompt as feedback. If the second attempt also fails, flag the record for human triage and log the raw input and partial output for later prompt debugging.

Logging and observability are critical because defect misclassification can delay critical fixes. Log the raw input, the assembled prompt, the model response, validation results, and the final action taken (auto-created, sent for review, or failed). Include a confidence field in your application schema—derived from validation pass/fail and any explicit uncertainty signals the model returns—so that downstream systems can route low-confidence records differently. For high-severity defects (P0/P1), consider requiring human approval regardless of validation confidence. The harness should also support deduplication checks: before creating a new defect, query your existing defect database for similar titles or stack traces and present potential duplicates alongside the new record. This prompt is not a replacement for your defect management system; it is a structured ingestion layer that reduces manual formatting work while keeping humans in control of triage decisions.