Vague Bug Report Triage Clarification Prompt

This prompt is designed for issue triage systems that ingest bug reports from users, customers, or internal teams. Its job is to detect when a report is too vague to route to a development team and to generate a structured clarification request asking for the missing triage dimensions. Use this prompt when your system must prevent un-triaged bugs from reaching developers, when you need to enforce that severity, reproducibility, and affected component are specified before assignment, and when you want the clarification to be specific enough that the reporter can respond without understanding your internal routing logic.

The prompt assumes the incoming report is a single text block and that your system has a defined list of required triage fields and known components. Before wiring this into a production harness, you must define the exact triage schema your organization requires—typically including severity, reproducibility_steps, affected_component, observed_behavior, and expected_behavior. The prompt's value comes from its ability to map vague natural language onto these structured gaps without hallucinating values. Implement a pre-check in your application layer: if all required fields are already populated with high confidence, bypass this prompt entirely to save latency and cost. If any field is missing or has low confidence, route the report through this prompt and validate that the output contains a specific, actionable question for each missing dimension before sending the clarification to the reporter.

Do not use this prompt for well-formed bug reports that already contain the required fields, for feature requests, or for general support inquiries that do not require engineering triage. Using it on complete reports will generate unnecessary friction and delay. For feature requests, route to a separate intake prompt that captures product context. For general support inquiries, use a standard support triage classifier. The prompt is also not suitable for real-time chat interfaces where the user expects an immediate answer; it is designed for asynchronous ticketing workflows where a structured clarification round-trip is acceptable. If your system allows developers to receive un-triaged bugs, this prompt acts as a safety gate—ensure your routing logic enforces that no bug reaches a development queue until the clarification loop is resolved or a human triager explicitly overrides the gate.

This prompt template is designed to be the first processing step for any incoming bug report in your issue triage system. Its job is to assess whether a report contains the minimum information required for a developer to begin work—specifically, a clear description of the problem, a severity assessment, reproducible steps, and the affected component. If any of these core dimensions are missing, the prompt instructs the model to halt the routing process and generate a structured clarification request. This prevents un-triaged, vague reports from landing in a developer's queue, where they waste time and break sprint velocity.

codeCopy
You are an issue triage agent. Your task is to analyze the following bug report and determine if it contains enough information to be assigned to a development team. Do not guess missing information. Do not route the issue if it is underspecified.

# INPUT
Bug Report:
[BUG_REPORT_TEXT]

# REQUIRED TRIAGE DIMENSIONS
A routable bug report must clearly state:
1. **Observed Behavior:** What is the actual, incorrect behavior?
2. **Expected Behavior:** What should have happened instead?
3. **Reproducibility:** Are there steps to reproduce the issue? If not, is the issue intermittent, and what is the observed frequency?
4. **Severity:** What is the user impact? Classify as [SEVERITY_LEVEL_1], [SEVERITY_LEVEL_2], [SEVERITY_LEVEL_3], or [SEVERITY_LEVEL_4] based on the definitions in [SEVERITY_DEFINITION_DOC].
5. **Affected Component:** Which part of the system is impacted? Map to a component from this list: [COMPONENT_LIST].

# CONSTRAINTS
- If ALL five dimensions are present and clear, output a JSON object with `"action": "route"` and populate the `"triage_summary"` field.
- If ANY dimension is missing, ambiguous, or contradictory, output a JSON object with `"action": "clarify"` and generate a `"clarification_message"` that asks the reporter for the specific missing information. The message must be polite, specific, and reference the missing dimension(s) by name.
- Do not invent a severity, component, or reproduction step.
- If the report is not a bug (e.g., a feature request, a question), set `"action": "reclassify"` and explain why in `"reclassification_note"`.

# OUTPUT SCHEMA
{
  "action": "route" | "clarify" | "reclassify",
  "triage_summary": {
    "observed_behavior": "string | null",
    "expected_behavior": "string | null",
    "reproducibility": "string | null",
    "severity": "[SEVERITY_LEVEL] | null",
    "affected_component": "[COMPONENT] | null"
  },
  "clarification_message": "string | null",
  "reclassification_note": "string | null"
}

To adapt this template, replace the square-bracket placeholders with your organization's specific taxonomy. For [SEVERITY_LEVEL_1] through [SEVERITY_LEVEL_4], substitute your actual severity labels (e.g., P0-Critical, P3-Cosmetic). For [SEVERITY_DEFINITION_DOC], provide a link or inline the definitions so the model can apply them consistently. The [COMPONENT_LIST] should be a curated, stable list of your system's modules (e.g., auth-service, payment-gateway, user-profile-ui). Avoid open-ended component fields, as they lead to inconsistent routing. After integrating this prompt into your triage harness, implement a validation check that blocks any issue with "action": "route" from being assigned to a developer if the triage_summary contains null values. This is your primary safety net against prompt failure or model hallucination.

This prompt is designed to sit at the intake boundary of an issue triage system—after a bug report is submitted but before it is assigned to a development team. The harness should intercept any report that lacks severity, reproducibility steps, or an affected component, invoke the LLM with this prompt, and present the generated clarification questions back to the reporter. The system must block routing until the clarification is resolved or a human triager explicitly overrides the block. This prevents un-triaged bugs from landing in developer backlogs where they waste cycles and create noise.

Validation and gating logic is the most critical part of this harness. After the LLM returns a structured clarification, the harness should validate that: (1) the output identifies which triage dimensions are missing (severity, reproducibility, component, or environment), (2) the clarification questions are specific and answerable, and (3) the output does not attempt to guess or default the missing fields. A completeness validator should check that all required triage fields are populated before releasing the bug for routing. If the LLM fails to produce a valid clarification after a configured number of retries (we recommend 2), escalate to a human triage queue with the raw report and a note that automated clarification failed. Log every clarification request and resolution for auditability—this data is invaluable for measuring triage efficiency and identifying reporters who consistently submit vague bugs.

Model choice and latency are straightforward here because this is a synchronous, human-facing step. Use a fast model (GPT-4o-mini, Claude Haiku, or equivalent) with low temperature (0.0–0.2) to maximize consistent output structure. The prompt should be called immediately on submission, not batched, because the reporter is waiting. If the reporter abandons the clarification flow, the bug should remain in an un-triaged state and surface in a dashboard for manual triage. Do not wire this prompt into an autonomous agent loop that retries indefinitely or invents triage fields—the harness must enforce that missing information is requested from a human, not hallucinated. For teams using Jira, Linear, or GitHub Issues, the harness can be implemented as a webhook or automation rule that sets the issue status to needs_clarification and assigns it back to the reporter until the required fields are filled.