Bug Report Trend and Cluster Analysis Prompt

This prompt is designed for the weekly triage review, the release retrospective, or any moment when you need to answer the question: 'What is getting worse right now?' Instead of reading through hundreds of individual tickets, you provide a batch of bug report summaries and the model groups them into coherent themes, counts the frequency of each theme, and surfaces representative examples. The ideal user is an engineering manager, QA lead, or triage coordinator who already has structured or semi-structured bug data and needs to detect trends before they become systemic failures.

The prompt assumes you have already completed individual ticket triage, severity classification, and component assignment. It does not replace those workflows. It is a trend detection tool, not a diagnostic tool. Do not use this prompt when you need root cause analysis for a single bug, when you need to assign ownership for a new ticket, or when you are evaluating whether a specific fix resolved a specific issue. The prompt works best with batches of 20-200 bug summaries from a defined time window, such as the past week or the past sprint. Smaller batches may not reveal meaningful clusters; larger batches may require chunking or summarization before clustering.

Before using this prompt, ensure your bug summaries are consistent in format and contain at least a title, a symptom description, and a component or area label. Inconsistent or overly brief summaries will produce noisy clusters. After running the prompt, validate the output by spot-checking whether the representative examples genuinely belong to their assigned clusters and whether any known emerging issues are missing from the results. The next step is typically to route each identified cluster to the appropriate team for deeper investigation, not to treat the cluster output as a completed analysis.

This prompt template ingests a batch of bug reports collected over a defined time window and produces a structured cluster analysis. It groups reports by underlying theme, not surface keyword overlap, and assigns each cluster a label, frequency count, and representative example. Use it when you need to identify emerging failure patterns before they become widespread incidents. Do not use it for single-report triage or real-time alerting—this prompt is designed for periodic batch analysis of closed-window data.

textCopy
You are a bug report trend analyst. Your task is to review a batch of bug reports collected over a defined time window and identify emerging clusters of related issues.

## INPUT
[BATCH_OF_BUG_REPORTS]

## CONSTRAINTS
- Group reports by underlying root cause or failure theme, not by surface keywords or component tags alone.
- Each cluster must represent a distinct failure pattern. Avoid creating clusters that are minor variations of each other.
- A single bug report may belong to only one cluster. If a report spans multiple themes, assign it to the dominant theme.
- If a report does not fit any cluster, place it in an "Unclustered" category.
- Do not invent themes not supported by the reports.
- If the batch is too small or too homogeneous to form meaningful clusters, state that explicitly instead of forcing artificial groupings.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "analysis_window": {
    "start_date": "ISO date",
    "end_date": "ISO date",
    "total_reports": number,
    "total_clustered": number,
    "total_unclustered": number
  },
  "clusters": [
    {
      "cluster_id": "string",
      "cluster_label": "concise theme name summarizing the failure pattern",
      "frequency": number,
      "trend_direction": "rising" | "stable" | "declining",
      "representative_example": {
        "report_id": "string",
        "title": "string",
        "symptom_summary": "one-sentence description of the core symptom"
      },
      "supporting_report_ids": ["string", ...],
      "common_characteristics": ["observable pattern shared across cluster members", ...],
      "suggested_attention": "low" | "medium" | "high",
      "rationale": "brief explanation of why this cluster matters and what the trend direction implies"
    }
  ],
  "unclustered_report_ids": ["string", ...],
  "cross_cluster_observations": "optional summary of patterns that span multiple clusters or notable absences in the data"
}

## INSTRUCTIONS
1. Read all bug reports in the batch.
2. Identify recurring failure patterns, root causes, or symptom groups.
3. For each cluster, select the most illustrative report as the representative example.
4. Assess trend direction by comparing cluster frequency to what you would expect from a uniform distribution across the time window. If the batch includes timestamps, use temporal concentration as a signal.
5. Assign a suggested attention level based on frequency, trend direction, and severity signals present in the reports.
6. Return only the JSON object. Do not include commentary outside the JSON.

Adapt this template by replacing [BATCH_OF_BUG_REPORTS] with your actual report data, structured as an array of objects each containing at minimum an id, title, description, and created_at timestamp. If your bug tracker includes severity or component fields, include those as optional enrichment—the model will use them to improve cluster coherence but will not rely on them as the primary grouping signal. For time windows longer than two weeks, consider splitting the batch into smaller windows to avoid mixing stale and active trends. If your output consumer requires a different schema, modify OUTPUT_SCHEMA but preserve the cluster-level fields that enable downstream action: frequency, trend direction, and suggested attention.

This prompt is designed to run over a batch of bug reports, not a single ticket. The implementation harness should be built as a scheduled job (e.g., a weekly cron or a CI/CD pipeline trigger) that queries a bug database for all tickets created or updated within a specific time window, formats them into the [BUG_REPORTS] input block, and invokes the model. The output is a structured cluster map that must be validated before it is presented to engineering managers or used to auto-generate epic tickets.

The harness must enforce a strict input schema. Each bug report in the [BUG_REPORTS] array should be a pre-processed object containing id, title, description, component, and severity. Before calling the model, validate that the input array is not empty and that no report exceeds a per-item character limit (e.g., 2000 characters) to avoid context-window exhaustion. If the batch is too large, implement a sliding window or sampling strategy. The model should be called with response_format set to a JSON schema that defines the expected output: an array of Cluster objects, each with a theme string, frequency integer, report_ids array, and representative_example string. A retry layer is critical here; if the output fails JSON schema validation, retry up to two times with a stricter prompt that includes the validation error message.

Logging and observability are non-negotiable. Log the input batch ID, the time window, the number of reports processed, the raw model response, and the final validated output. This audit trail is essential for debugging cluster drift over time. For evaluation, maintain a golden dataset of manually clustered reports from a historical period. After each run, compare the model's clusters against the golden set using metrics like Normalized Mutual Information (NMI) or Adjusted Rand Index (ARI) to detect prompt degradation. If the score drops below a defined threshold (e.g., 0.7), block the automated pipeline and flag the run for human review. Do not allow unvalidated cluster outputs to automatically create Jira epics or assign team leads without a human-in-the-loop approval step for the first few runs.