Concurrency Bug Triage and Routing Prompt

This prompt is designed for on-call engineers, SREs, and triage teams who receive raw bug reports describing suspected concurrency issues. Concurrency bugs arrive through multiple channels: user reports of data corruption, automated alerts for deadlocks, support tickets describing intermittent failures, or logs showing race conditions. These reports are often unstructured, missing critical reproduction details, and routed to the wrong team on first pass. This prompt transforms that chaos into a structured triage ticket that classifies the bug type, extracts symptoms, identifies the likely owning component, and justifies routing.

Use this prompt when you need to standardize concurrency bug intake and reduce misrouted tickets. The ideal input is a raw bug report containing any combination of user descriptions, stack traces, log excerpts, timestamps, and observed symptoms. The prompt works best when the report includes at least one concrete symptom—such as a deadlock error message, a data inconsistency example, or a timing-dependent failure description. Reports that include thread dumps, goroutine stacks, or database transaction logs will produce significantly more accurate classifications and routing decisions. The prompt expects to produce a structured JSON output that can be ingested directly by ticketing systems like Jira, linear, or ServiceNow, with fields for severity, component ownership, reproduction steps, and routing justification.

Do not use this prompt for general crash reports, network timeouts, or bugs where concurrency is not the suspected root cause. If the report describes a deterministic null pointer exception, a configuration error, or a simple logic bug with no concurrent execution involved, this prompt will waste tokens and may produce misleading classifications. Similarly, avoid using this prompt for performance issues that are purely single-threaded bottlenecks without any shared state or synchronization concerns. For those cases, use a general bug triage prompt or a performance-specific analysis prompt instead. When in doubt, check whether the report mentions multiple threads, goroutines, async tasks, locks, transactions, or timing-dependent behavior—if none of these signals are present, route the report through a different triage path.

This is the core prompt you will send to the model for every incoming concurrency bug report. It is designed to be stateless and idempotent: given the same raw report, it should produce the same structured triage ticket. The prompt forces the model to separate symptoms from speculation, classify the concurrency primitive involved, and justify its routing decision with explicit evidence from the input. Before copying this into your production triage workflow, ensure you have defined your team routing map, severity matrix, and the schema your ticketing system expects.

textCopy
You are an expert on-call triage engineer specializing in concurrency and distributed systems bugs.

Your task is to analyze an incoming bug report, extract structured information, classify the concurrency defect, and route it to the correct team.

## INPUT
Bug Report:
[BUG_REPORT]

## TEAM ROUTING MAP
[TEAM_ROUTING_MAP]

## SEVERITY MATRIX
[SEVERITY_MATRIX]

## INSTRUCTIONS
1. Extract all described symptoms, error messages, stack traces, and reproduction steps from the bug report. Do not invent details not present in the input.
2. Classify the concurrency bug type from this closed list: `race_condition`, `deadlock`, `livelock`, `thread_safety_violation`, `goroutine_leak`, `channel_blocking`, `lock_contention`, `transaction_boundary_violation`, `non_atomic_compound_operation`, `memory_ordering_violation`, `thread_pool_exhaustion`, `asynchronous_race`, `other`.
3. Identify the most likely owning component and map it to a team using the TEAM ROUTING MAP. If the component is ambiguous, list the top two candidates with confidence scores.
4. Assign a severity level from the SEVERITY MATRIX based on data corruption risk, production exposure, and reproducibility. Justify the severity with specific evidence from the report.
5. If reproduction steps are missing or incomplete, flag this explicitly and do not fabricate them.
6. If the report describes a symptom that could be caused by a non-concurrency issue (e.g., a plain logic error), note this as an alternative hypothesis.

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "triage_ticket": {
    "ticket_id": "string, generate a unique ID prefixed with CONC-",
    "source_report": "string, the original bug report text",
    "extracted_symptoms": ["string, list of observed symptoms"],
    "extracted_errors": ["string, list of error messages or stack traces"],
    "reproduction_steps": ["string, list of steps or null if missing"],
    "reproduction_completeness": "complete | incomplete | absent",
    "concurrency_bug_type": "string, from the closed classification list",
    "concurrency_primitive_suspected": "string, e.g., mutex, channel, atomic, lock, transaction, goroutine, thread_pool",
    "owning_component": "string, the most likely component",
    "routing_target_team": "string, the team from the routing map",
    "alternative_teams": [{"team": "string", "confidence": 0.0}],
    "severity": "string, from the severity matrix",
    "severity_justification": "string, evidence-based justification",
    "alternative_hypotheses": ["string, non-concurrency explanations if applicable"],
    "requires_immediate_escalation": true or false,
    "escalation_reason": "string or null"
  }
}

## CONSTRAINTS
- Do not include any text outside the JSON object.
- Use null for any field where information is absent, never omit fields.
- Confidence scores must be between 0.0 and 1.0.
- If the bug report is too vague to classify, set concurrency_bug_type to "other" and note the ambiguity in alternative_hypotheses.

To adapt this prompt for your environment, replace [TEAM_ROUTING_MAP] with a structured mapping of components, code paths, or services to your on-call teams. The [SEVERITY_MATRIX] should reflect your organization's actual incident severity definitions, including criteria for data corruption, customer impact, and reproducibility. If your ticketing system uses a different schema, modify the OUTPUT_SCHEMA block to match your API contract. Always validate the model's output against your schema before creating a ticket. For high-severity classifications, route the triage ticket to a human on-call for confirmation before paging the target team.

Integrating this prompt into a production triage pipeline requires treating it as a structured classification step, not a free-form chat. The prompt expects a raw bug report as [BUG_REPORT] and a [SERVICE_CATALOG] mapping components to owning teams. The output is a JSON object with fields like bug_classification, severity, owning_team, routing_justification, and reproduction_steps. Wire this prompt behind an API endpoint or a webhook receiver that ingests bug reports from Slack, email, or a ticketing system. Before calling the LLM, sanitize the input to strip PII and normalize whitespace, but preserve stack traces, timestamps, and log excerpts exactly as reported—these are critical signals for concurrency classification.

Validation must happen immediately after the model responds. Parse the JSON output and check that severity is one of the allowed enum values (SEV1 through SEV5), that owning_team matches an entry in your service catalog, and that reproduction_steps is a non-empty array. If validation fails, retry once with the same prompt but append the validation error message as a [PREVIOUS_ERROR] field. If the retry also fails, route the ticket to a human triage queue with the raw bug report and both failed attempts attached. For model choice, use a model with strong structured output support (e.g., GPT-4o, Claude 3.5 Sonnet) and set response_format to json_object or use tool-calling with a strict schema to enforce the output shape. Temperature should be set low (0.0–0.2) to maximize classification consistency across similar bug reports.

Human-in-the-loop checkpoints are non-negotiable for SEV1 and SEV2 classifications. Even if the model assigns a high-confidence critical severity, the ticket must be held for human approval before paging an on-call engineer. Implement this as a two-stage workflow: the prompt classifies and routes, but the actual notification action (PagerDuty, Opsgenie) is gated on a human clicking 'Confirm and Page.' For SEV3 and below, auto-routing to the suggested team's backlog is acceptable, but log the model's confidence and routing justification for audit. Track metrics like classification override rate, validation failure rate, and mean time from report to routed ticket. These metrics will tell you when the prompt needs retuning—for example, if a particular service team consistently overrides the model's severity calls, add few-shot examples for that team's bug patterns.

Finally, treat the [SERVICE_CATALOG] as a dynamic variable sourced from your live infrastructure registry, not a hardcoded list in the prompt. When services change ownership or new components are added, the prompt must reflect those changes immediately. Build a prompt assembly step that fetches the current catalog and injects it into the template before each invocation. Avoid the failure mode where a correctly classified bug is routed to a disbanded team because the catalog was stale. If your organization lacks a formal service catalog, start with a simple JSON file in version control and require that concurrency bug routing updates it within the same change management process.