Component Ownership Assignment Prompt for Bug Reports

This prompt is designed for automated bug triage pipelines that must map an unstructured bug report to a specific owning team or service component. The primary job-to-be-done is reducing mean time to assignment (MTTA) by replacing manual routing with a structured, evidence-backed classification step. The ideal user is a platform engineer, QA automation lead, or on-call rotation manager embedding this prompt into an intake webhook, support bot, or internal triage queue. It expects a bug report that contains at least a title and description, and it requires a maintained component catalog as input context—a structured list of teams, services, and their areas of responsibility. Without that catalog, the model cannot produce meaningful ownership assignments.

Use this prompt when your triage volume exceeds what a human can consistently route within SLA windows, or when you need a standardized routing rationale for audit trails. It is appropriate for bug reports that describe functional failures, error messages, UI defects, or performance degradations where the affected system surface is identifiable from the description. The prompt outputs a component label, a confidence score, and a routing rationale, making it suitable as a decision-support tool where a human still reviews low-confidence assignments, or as a fully automated router when confidence exceeds a defined threshold and the component catalog is stable. Do not use this prompt for security vulnerability reports that require confidential handling, for incidents already declared and managed in an incident response pipeline, or for feature requests disguised as bugs—those require different classification taxonomies and routing logic.

Before wiring this prompt into production, ensure your component catalog is versioned and that changes to team ownership trigger a catalog update. The prompt's effectiveness degrades when the catalog is stale or when bug reports describe cross-cutting concerns that span multiple components. In those cases, the confidence score will typically drop, and your harness should route to a triage lead or fallback queue. The next section provides the copy-ready template with placeholders for your catalog, input report, and output schema. Start by adapting the [COMPONENT_CATALOG] placeholder to match your organization's actual service and team map.

This prompt template is designed to be dropped into a routing engine that assigns component ownership to incoming bug reports. It expects a structured component catalog as input context and produces a component label, confidence score, and routing rationale. The template uses square-bracket placeholders that you must replace with your actual data before execution. The prompt enforces strict output formatting and requires the model to explain its reasoning, which is critical for audit trails and triage review.

textCopy
You are a bug report routing assistant. Your job is to read a bug report and assign it to the most likely owning component or team based on the provided component catalog.

## COMPONENT CATALOG
[COMPONENT_CATALOG]

## INPUT
Bug Report:
[BUG_REPORT]

## CONSTRAINTS
- Choose exactly one component from the catalog above.
- If the bug report does not clearly match any component, assign it to [DEFAULT_COMPONENT] and note the ambiguity.
- Do not invent components. Only use those listed in the catalog.
- If the report mentions multiple symptoms, prioritize the root cause area, not the symptom location.
- [ADDITIONAL_CONSTRAINTS]

## OUTPUT_SCHEMA
Return a single JSON object with these fields:
- "component": string (the assigned component name from the catalog)
- "confidence": number between 0.0 and 1.0
- "rationale": string (explain why this component was chosen, citing specific phrases from the bug report)
- "alternative_candidates": array of strings (up to 2 other possible components, or empty array)
- "missing_context": array of strings (any information that would increase confidence if available)

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK_LEVEL
[RISK_LEVEL]

To adapt this template, start by populating [COMPONENT_CATALOG] with a structured list of your services, teams, or modules. Each entry should include the component name, a brief description of its responsibility, and keywords or patterns commonly found in related bug reports. The [BUG_REPORT] placeholder receives the raw user-submitted text. For [DEFAULT_COMPONENT], choose a fallback team or triage queue that handles ambiguous cases—this prevents the model from hallucinating a component. The [ADDITIONAL_CONSTRAINTS] field lets you inject domain-specific rules, such as "if the word 'checkout' appears, prefer the Payments component." Include [FEW_SHOT_EXAMPLES] with 2-3 representative bug-to-component mappings to calibrate the model's behavior. Set [RISK_LEVEL] to "low", "medium", or "high" to adjust the confidence threshold and escalation behavior in your harness. After populating the template, validate outputs against a golden set of 20-30 manually routed bugs to measure assignment accuracy before deploying to production.

This prompt is designed to sit inside a routing engine that receives an unstructured bug report and a maintained component catalog, then returns a structured ownership decision before the ticket reaches a human triage queue. The implementation harness must treat the model's output as a candidate decision, not a final routing action. The prompt expects two required inputs: a [BUG_REPORT] containing the raw title and description, and a [COMPONENT_CATALOG] listing valid component names, descriptions, ownership teams, and example bug patterns. Without a well-maintained catalog, the model will hallucinate plausible-sounding component names that do not exist in your system, causing misroutes that are expensive to detect and correct downstream.

Wire the prompt into an application function that first validates the input catalog is non-empty and contains at least three components with descriptions. On receiving a bug report, construct the prompt by injecting the report text and the catalog as structured context. Call the model with a low temperature (0.0–0.2) to maximize deterministic routing. Parse the JSON output and validate three fields before any routing action: the component field must exactly match a component name from the provided catalog (case-insensitive comparison with normalization), the confidence field must be a float between 0.0 and 1.0, and the rationale field must be a non-empty string. If validation fails, retry once with the same prompt and an added [CONSTRAINT] noting the specific validation error. If the retry also fails, route to a human-staffed triage-uncertain queue and log the failure for catalog improvement. For high-confidence assignments (confidence ≥ 0.85), route directly to the owning team's backlog. For medium-confidence assignments (0.50–0.84), route to the team's triage column with a needs-review flag. For low-confidence assignments (< 0.50), route to a general triage queue and attach the model's top two candidate components as suggestions.

Log every routing decision with the original bug report, the catalog version used, the model's raw output, the validated fields, and the final routing destination. This audit trail is essential for measuring routing accuracy over time and identifying catalog gaps. Set up a weekly evaluation pipeline that samples 100 routed bugs, compares the model's assignment against the eventual human-corrected component, and computes precision and recall per component. Use these metrics to refine component descriptions, add missing example patterns, and detect catalog drift as your system architecture evolves. Avoid wiring this prompt directly into an auto-assignment action without the validation and confidence-gating steps described above, because a single misrouted critical bug sent to the wrong team's backlog can delay resolution by hours or days.