Bug Report Ingestion and Structuring Prompt Template

This prompt is designed for the critical handoff point where unstructured user reports, support tickets, or QA notes enter the engineering workflow. Its job is to convert freeform text—often messy, emotional, or incomplete—into a consistent, machine-readable JSON bug ticket. The ideal user is a support engineer, QA analyst, or an automated intake pipeline that needs to transform 'the button is broken' into a structured object with an extracted title, a clear description, a classified severity, an assigned component, and ordered reproduction steps. This prompt belongs at the boundary between support intake and the engineering backlog, acting as a force multiplier that eliminates the manual, repetitive work of reformatting tickets.

Use this prompt when your intake pipeline receives a high volume of bug reports and you need a single, predictable output schema to feed into your issue tracker or triage automation. It requires the raw user report as the primary [INPUT], and it performs best when you also provide a [COMPONENT_CATALOG] and a [SEVERITY_RUBRIC] as [CONTEXT] to ground its classification decisions. The prompt is not a replacement for human judgment on critical systems; a human must always review the output for S1 or security-sensitive bugs. It also does not handle duplicate detection, routing decisions, or direct user replies—those are separate, specialized prompts in the bug report triage family that should be orchestrated in sequence.

Do not use this prompt when the input is already a structured ticket, when the report contains sensitive data that hasn't been redacted, or when the cost of a misclassification is unacceptable without a human-in-the-loop review. The prompt's value is in standardizing the intake format, not in making autonomous severity decisions for production incidents. Before deploying, you must pair it with a validation harness that checks for schema compliance, field completeness, and enum adherence. The next step after reading this section is to copy the prompt template, adapt the placeholders to your internal taxonomies, and run it against a golden dataset of 50 historical tickets to measure extraction accuracy before wiring it into a live pipeline.

This template is the core instruction set for ingesting freeform bug reports—from support emails, chat transcripts, or QA notes—and producing a strictly typed JSON object. It is designed to be placed in the system prompt of a model that has no memory of prior reports and no access to external tools unless you explicitly wire them in. The prompt enforces a specific output schema, requires explicit 'unknown' markers for missing information, and instructs the model to separate factual extraction from severity inference. Use this template as the starting point; you will adapt the placeholders and constraints to match your internal ticket schema, severity rubric, and component catalog.

textCopy
You are a bug report structuring assistant. Your only job is to read an unstructured bug report and produce a valid JSON object that conforms to the schema below. Do not add commentary, markdown fences, or extra text outside the JSON object.

## INPUT
[BUG_REPORT_TEXT]

## OUTPUT SCHEMA
Return a single JSON object with these exact keys:
- "title": A concise, one-sentence summary of the bug. Max 120 characters.
- "description": A clear restatement of the problem, preserving all technical details from the report. Do not interpret or diagnose.
- "severity": One of [SEVERITY_LEVELS]. Choose based on the impact described, not on the reporter's tone.
- "component": The most likely owning component from this list: [COMPONENT_CATALOG]. If uncertain, use "unknown".
- "reproduction_steps": An ordered list of steps to reproduce the bug, extracted or inferred from the report. Each step is a string. If no steps can be extracted, return an empty list.
- "environment": An object with keys for "os", "browser", "app_version", and "device". Extract these from the report. Use the string "unknown" for any field not mentioned.
- "attachments": A list of any referenced error logs, stack traces, or screenshot descriptions. Include the raw text if available.
- "completeness_score": An integer from 1 to 5 rating how much of the required triage information is present (5 = fully complete).
- "missing_fields": A list of strings naming any critical triage fields absent from the report (e.g., "steps to reproduce", "environment details").

## CONSTRAINTS
[CONSTRAINTS]
- Never invent details not present in the report.
- If severity cannot be determined, default to [DEFAULT_SEVERITY].
- For any field where information is missing, use the explicit sentinel "unknown" or an empty list as appropriate.
- If the report describes multiple bugs, extract only the primary issue and note the presence of additional issues in the description.
- Do not suggest fixes or root causes.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by replacing the square-bracket placeholders with your operational data. [SEVERITY_LEVELS] should be your exact enum values (e.g., S1, S2, S3, S4). [COMPONENT_CATALOG] must match the labels your routing system expects; stale or mismatched component names are a common failure point that breaks downstream automation. [DEFAULT_SEVERITY] is your safe fallback—typically the lowest severity that still triggers review. The [FEW_SHOT_EXAMPLES] placeholder is critical for schema compliance: include at least two examples showing a well-structured output and one showing how the model should handle a sparse, low-quality report with many "unknown" fields. If your triage pipeline has a strict JSON schema validator, paste that schema into [CONSTRAINTS] as an additional formatting rule. For high-severity bugs where misclassification could delay a critical fix, set [RISK_LEVEL] to "high" and add a note that severity S1 or S2 outputs must be flagged for immediate human review before the ticket is created.

Before deploying this prompt into your triage pipeline, run it against a golden set of 20-30 labeled bug reports and measure field-level accuracy, schema compliance rate, and severity agreement with human triagers. Pay special attention to completeness_score calibration: if the model consistently rates incomplete reports as 4 or 5, your missing-field detection will fail silently and engineers will receive tickets they cannot act on. Wire the output into a validation layer that checks for the "unknown" sentinel on required fields and routes incomplete tickets to a human triager or a follow-up prompt that asks the reporter for missing details. Do not use this prompt to auto-close or auto-resolve bugs without human confirmation.

The Bug Report Ingestion and Structuring prompt is designed to sit at the entry point of a triage pipeline—typically behind a support form, chatbot, or email-to-ticket gateway. The application layer should collect the raw user report, attach any available metadata (reporter identity, timestamp, channel), and pass it to the model with a strict JSON schema constraint. Because this prompt produces structured data that downstream routing and prioritization systems depend on, the harness must enforce schema compliance before the output reaches any other system. Treat the model's output as a draft that requires validation, not as a finished ticket.

Wire the prompt into an API endpoint or queue worker that calls the model with response_format set to json_schema (OpenAI) or the equivalent structured output mode for your provider. After receiving the response, run a validator that checks: (1) all required fields are present and non-null, (2) enum fields like severity contain only allowed values, (3) reproduction_steps is a non-empty array with each step containing both action and expected_result strings, and (4) the title is under 120 characters and contains the core symptom. If validation fails, retry once with the validation errors appended to the prompt as [CONSTRAINTS] feedback—but stop after two attempts and route to a human triage queue. Log every validation failure and retry for observability. For high-severity bugs (S1/S2), add a mandatory human review step before the ticket is created in the issue tracker.

Model choice matters here. Use a model with strong instruction-following and structured output support—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are good defaults. Avoid smaller or older models that drift on enum values or drop fields under varied phrasing. If you're processing high volumes, consider batching requests during off-peak hours, but never batch real-time user-facing intake where latency degrades the reporter experience. For on-premise or air-gapped deployments, test open-weight models like Llama 3.1 70B against your schema compliance eval before committing. The harness should also attach a unique ingestion_id to each request and store the raw prompt, model response, and validation result for audit and debugging. This trace data is essential when triage decisions are questioned or when the prompt template is updated and you need to compare behavior across versions.