Bug Report Environment Details Extraction Prompt

This prompt is designed for QA engineers, support-to-engineering triage teams, and on-call developers who need to extract structured environment information from freeform bug reports. Users often describe their setup inconsistently: 'latest Chrome on Windows,' 'iPhone 15 with iOS 17.something,' or 'the app crashed on my laptop.' This prompt converts that noise into a predictable JSON block with explicit 'unknown' markers for missing fields, so downstream routing and reproduction logic never guesses. Use it when environment details are scattered across paragraphs, when you need to feed structured data into a ticketing system or test harness, or when you are building an automated triage pipeline that must decide whether a bug is platform-specific before a human looks at it.

The ideal input is a raw, unstructured bug report that may contain environment clues in the title, description, or attached log snippets. The prompt works best when you provide a clear [OUTPUT_SCHEMA] defining the exact fields you need (e.g., os, os_version, browser, browser_version, device_type, app_version). You should also supply [CONSTRAINTS] such as 'Mark any field not found in the text as "unknown"' and 'Do not infer versions from generic terms like "latest."' For high-stakes triage pipelines, pair this prompt with a validation step that checks extraction accuracy against a set of manually labeled reports and flags any output where critical fields remain unknown for human review.

Do not use this prompt when the bug report already contains a structured environment block from a form submission, as direct parsing is more reliable. Avoid it for reports where environment details are entirely absent and you need the model to ask clarifying questions rather than extract. This prompt is also not a replacement for client-side telemetry or automated environment capture; it is a normalization layer for human-written text. If your workflow requires legal or compliance-grade audit trails for environment data, ensure a human reviews any extraction where the confidence is not explicitly high, and log the raw input alongside the structured output.

This prompt template is designed to be pasted directly into your system instructions or as a user message in your triage pipeline. It instructs the model to parse a freeform bug report and extract key environment details—such as OS, browser, app version, and device—into a strict JSON schema. The critical design choice is the requirement for explicit unknown markers for any field not found in the source text, which prevents silent null failures and makes downstream validation deterministic.

textCopy
You are an expert bug triage assistant. Your task is to extract environment details from the following bug report and output them in a strict JSON format.

INPUT BUG REPORT:
[INPUT]

OUTPUT SCHEMA:
{
  "operating_system": "string | 'unknown'",
  "os_version": "string | 'unknown'",
  "browser": "string | 'unknown'",
  "browser_version": "string | 'unknown'",
  "application_version": "string | 'unknown'",
  "device_type": "'desktop' | 'mobile' | 'tablet' | 'unknown'",
  "device_model": "string | 'unknown'",
  "screen_resolution": "string | 'unknown'",
  "network_type": "string | 'unknown'"
}

CONSTRAINTS:
- Extract information only from the provided bug report text.
- If a field is not explicitly mentioned, set its value to the literal string "unknown".
- Do not infer or guess values based on common defaults.
- Normalize common abbreviations (e.g., "Win 11" -> "Windows 11").
- Output ONLY the valid JSON object. No markdown fences, no commentary.

To adapt this template, replace the [INPUT] placeholder with the raw bug report text. For production use, you should wrap this prompt in a validation harness that checks the output against the JSON schema and flags any field where the model hallucinated a value instead of using unknown. For high-stakes triage, add a human review step when the application_version or os_version fields are unknown for a critical bug, as these details are often essential for reproduction.

This prompt is designed to be called as a stateless extraction step inside a larger bug report ingestion pipeline. The typical flow is: receive an unstructured bug report via API, webhook, or support ticket → extract the freeform description field → call this prompt with the description as [BUG_DESCRIPTION] → validate the structured output → merge the environment block into the canonical ticket object before routing. The prompt should be treated as a pure function: same input produces the same structured extraction, with no side effects or state mutation. This makes it safe to retry, cache, or run in parallel across multiple reports.

Validation and retry logic is critical because missing or malformed environment fields break downstream routing and debugging. After the model returns the JSON environment block, run a schema validator that checks: (1) all required keys are present (os, os_version, browser, browser_version, app_version, device_type, device_model, screen_resolution, network_type, locale, timezone, additional_context), (2) no key has a null value—use the string 'unknown' as the explicit missing marker, (3) device_type is one of the allowed enum values (desktop, mobile, tablet, unknown), and (4) version strings match a reasonable pattern (e.g., major.minor.patch or major.minor). If validation fails, retry once with the same prompt plus the validation error message appended as [PREVIOUS_ERROR]. If the retry also fails, log the raw output and the validation failure for manual review, then fall back to a default environment block with all fields set to 'unknown' and a flag extraction_status: 'failed' so downstream systems know the data is unreliable.

Model selection and latency matter here because triage pipelines often process hundreds of reports per hour. For high-throughput scenarios, use a fast, cost-efficient model like GPT-4o-mini, Claude Haiku, or Gemini Flash. These models handle structured extraction reliably at low latency. Reserve larger models (GPT-4o, Claude Sonnet) for cases where the retry also fails or where the bug description is unusually ambiguous. Implement a circuit breaker: if extraction latency exceeds 2 seconds for more than 5% of requests in a rolling window, degrade to a regex-based fallback extractor that pulls version numbers and OS names with simple pattern matching. This keeps the pipeline moving even if the model endpoint is slow or unavailable.

Logging and observability should capture the prompt version, model used, input length, output JSON, validation status, and latency for every extraction call. Attach these logs to the bug report ID so triage leads can trace any misclassification back to the extraction step. Set up an accuracy monitor that samples 5% of extractions and compares them against manually labeled environment blocks. If the field-level accuracy drops below 90% for any single field, trigger an alert for prompt review. Common drift signals include new browser version formats, OS naming changes (e.g., 'macOS 15 Sequoia' vs 'macOS 15.0'), or user reports that describe environments in novel ways the prompt hasn't seen.

Human review integration is required when the extraction confidence is low. Add a confidence field to the output schema (not part of the environment block itself, but returned alongside it) that the model sets to high, medium, or low based on how many fields it had to mark as 'unknown' and how ambiguous the source text was. If confidence is low, route the ticket to a manual triage queue where a human can fill in the environment details before the bug reaches an engineering team. This prevents bad environment data from wasting developer time on unreproducible bugs. For regulated or high-severity bug workflows (e.g., security vulnerabilities, data loss), always require human confirmation of the extracted environment regardless of confidence score.

What to avoid: Do not call this prompt inside a user-facing chat interface where the reporter is waiting for a response. The extraction should happen asynchronously after the report is submitted. Do not use the extracted environment block to auto-close or auto-reject bugs—missing environment details are a signal to ask the reporter for more information, not to discard the report. Finally, do not skip validation even if the model output looks correct; schema drift is the most common failure mode in production extraction pipelines, and a single malformed field can break downstream JSON parsers or routing logic.