Duplicate Detection Prompt for Bug Databases

This prompt is designed for triage engineers, QA leads, and automated support pipelines that need to determine whether an incoming bug report describes an issue already tracked in the database. The core job is to compare a new, often unstructured report against a set of existing tickets and produce a ranked list of candidate duplicates with clear similarity reasoning. The ideal user is someone building or operating a bug triage system where duplicate noise wastes engineering time and inflates backlog metrics. Required context includes the full text of the incoming report and a search result set of candidate existing tickets, each with at least a title, description, and component tag. Without this context, the prompt cannot perform meaningful comparison.

This prompt should not be used as the sole decision-maker for merging tickets. It is a recommendation engine, not an auto-merge system. Do not use it when the candidate ticket set is empty, when the incoming report is a feature request rather than a defect, or when the cost of a false merge is catastrophic—such as in safety-critical or financially regulated systems where duplicate misclassification could hide a distinct high-severity issue. The prompt also fails when existing tickets lack sufficient detail; if your database is full of one-line titles with no reproduction steps, similarity scoring will be unreliable. In those cases, invest in upstream report quality before deploying this prompt.

Before implementing, define your operational thresholds. You need a minimum similarity score for flagging a candidate, a maximum number of candidates to return, and a clear policy on what happens when the top candidate scores above a configurable auto-merge threshold versus when it falls into an ambiguous review bucket. The prompt output should always route to a human reviewer when confidence is moderate, not just when it is low. Next, wire the prompt into a harness that measures recall against a golden set of known duplicates and precision against a set of distinct reports that should never be merged. If your precision drops below 90% or your recall below 85%, pause and tune the prompt, the candidate retrieval step, or the similarity threshold before scaling to production.

This template is designed to be dropped into a triage pipeline where an unstructured or semi-structured bug report must be checked against an existing database of open and recently closed tickets. The prompt instructs the model to act as a strict duplicate detector, not a general classifier. It requires the incoming report and a formatted list of candidate tickets as inputs, and it produces a ranked list of potential duplicates with explicit similarity reasoning. The square-bracket placeholders allow you to inject your own ticket schema, severity taxonomy, and risk tolerance without rewriting the core instruction.

codeCopy
You are a bug triage specialist. Your task is to compare the incoming bug report against a list of existing tickets and identify likely duplicates. A duplicate is a ticket that describes the same underlying defect, even if the wording, reproduction steps, or environment details differ.

## INPUT

### Incoming Bug Report
[INCOMING_REPORT]

### Existing Tickets
[EXISTING_TICKETS]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "duplicates": [
    {
      "ticket_id": "string",
      "similarity_score": 0.0-1.0,
      "reasoning": "string explaining what matches and what differs",
      "matched_fields": ["title", "description", "stack_trace", "component", "environment"],
      "key_differences": ["string describing notable differences"]
    }
  ],
  "no_duplicate_found": false,
  "confidence_note": "string summarizing overall confidence in the results"
}

## CONSTRAINTS
- Only flag a ticket as a duplicate if the underlying defect is the same, not just the same component or symptom category.
- If no ticket meets the threshold, set no_duplicate_found to true and return an empty duplicates array.
- similarity_score must reflect semantic overlap of the defect, not surface-level keyword matching. Use 0.85 or higher for near-certain duplicates, 0.70-0.84 for likely duplicates, and below 0.70 for possible but uncertain matches.
- Do not fabricate ticket IDs. Only reference IDs present in the existing tickets list.
- If the incoming report is too vague to compare, set confidence_note to "LOW" and explain what information is missing.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by defining your [INCOMING_REPORT] format. If your intake system already produces structured JSON, pass that directly. If reports arrive as freeform text, preprocess them with a structuring prompt first. For [EXISTING_TICKETS], provide a JSON array of ticket objects with at minimum id, title, description, and component fields. The [FEW_SHOT_EXAMPLES] placeholder should be replaced with 2-3 annotated examples showing correct duplicate and non-duplicate calls, especially edge cases where symptoms overlap but root causes differ. The [RISK_LEVEL] placeholder controls the model's caution: set to "HIGH" to require stronger evidence before merging tickets, or "STANDARD" for routine triage. Before deploying, run this prompt against a golden dataset of known duplicate pairs and non-duplicate pairs to calibrate your similarity threshold. If your use case involves regulated software or safety-critical systems, route all proposed merges to a human reviewer and log the full prompt-response pair for audit.

The duplicate detection prompt operates as a comparison and ranking step inside a larger triage pipeline. When a new bug report arrives, the harness retrieves a candidate set of open and recently closed tickets from the bug database—typically via keyword search, embedding similarity, or component-based filtering—and passes each candidate pair (incoming report + existing ticket) through the prompt. The prompt returns a similarity score, reasoning, and a recommended action. The harness then aggregates results, ranks candidates by score, and presents the top matches to a human reviewer or an automated merge rule. Do not use this prompt in isolation without a retrieval step; sending every open ticket to the model is cost-prohibitive and introduces noise that degrades ranking quality.

Retrieval and batching: Before calling the prompt, run a lightweight retrieval step to narrow the candidate pool. Use a hybrid approach: keyword match on title and error signature fields, plus vector similarity on the description embedding. Limit the candidate set to 10–20 tickets. For each candidate, construct a prompt call with [INCOMING_BUG] set to the structured fields of the new report and [EXISTING_TICKET] set to the candidate's title, description, and component. Run these calls in parallel if your model provider supports it, or batch them sequentially with a concurrency cap. Validation: After each response, validate that the output contains a numeric similarity_score between 0.0 and 1.0, a non-empty reasoning string, and a recommendation that matches one of the allowed enum values (merge, link, keep_separate). Reject and retry any response that fails schema validation. Log all raw responses and validation failures for offline recall analysis.

Merge safety and human review: Never auto-merge tickets based solely on the model's recommendation. For scores above a configurable threshold (start at 0.85), surface the candidate pair to a triage engineer with the model's reasoning and a one-click merge action. For scores between 0.65 and 0.85, present the match as a suggested link with a note to review. Below 0.65, suppress the match from the UI but log it for recall measurement. Evaluation harness: Maintain a labeled dataset of known duplicate pairs and known distinct pairs from your bug database history. After each prompt version change, run the prompt against this golden set and measure recall@k (did the true duplicate appear in the top k results?) and precision (what fraction of high-scoring matches were true duplicates?). Track these metrics over time and set a minimum recall threshold (e.g., 0.90) before promoting a new prompt version. Model choice: Use a model with strong comparison reasoning—GPT-4o or Claude 3.5 Sonnet work well. Avoid smaller models for this task; they tend to over-anchor on keyword overlap and miss semantic duplicates where the phrasing differs substantially.

What to avoid: Do not include closed tickets older than 90 days in the candidate set unless the incoming report explicitly references a regression of a previously fixed issue. Stale candidates increase false positives and waste review time. Do not use the prompt to compare more than two tickets at once; pairwise comparison produces more reliable similarity scores than multi-way ranking. Finally, do not skip the retrieval step—sending every open ticket to the model will blow your token budget and latency budget while producing worse results than a focused candidate set.