Feature Request vs Bug Report Intent Prompt

Product engineering teams receive a constant stream of user feedback through support tickets, chat, NPS surveys, and sales calls. Every piece of feedback that is misrouted to the wrong development pipeline creates rework, delays fixes, and erodes trust in the feedback loop. This prompt classifies unstructured user input into feature_request, bug_report, or ambiguous and extracts the structured details each pipeline needs. Use it as the first stage in a feedback triage system that writes directly to your issue tracker API.

The ideal input is a single, self-contained piece of user feedback with a clear subject. The prompt expects a [USER_FEEDBACK] string and an optional [PRODUCT_CONTEXT] describing the surface or feature area the user is referencing. It returns a strict JSON object with a classification field, a confidence score between 0.0 and 1.0, and an extracted_details object containing either reproduction steps for bugs or a feature description and use case for requests. Wire the output into a routing harness that creates a Linear ticket for bugs, a Productboard note for feature requests, and a triage queue item for ambiguous items.

Do not use this prompt when the input contains multiple unrelated requests, when the user is reporting a security vulnerability, or when the feedback is purely emotional without any actionable signal. In those cases, route to a multi-intent disambiguation prompt, a security incident workflow, or a sentiment analysis pipeline first. If the confidence score falls below your defined threshold (start at 0.70 and tune against production data), route to a human review queue rather than guessing. The cost of misclassification is not just a wrong label—it is a bug that goes unfixed or a feature request that clogs the triage backlog.

This prompt template is designed to be the core classification engine in a feedback triage pipeline. It takes raw, unstructured user text—from support tickets, in-app feedback widgets, or email—and forces a structured decision. The model is instructed to output a strict JSON schema, making the result directly consumable by an API that routes the payload to a product backlog tool (like Jira or Linear) or a bug tracker. The prompt includes explicit definitions for each class and a mandatory ambiguous category to prevent the model from guessing when evidence is insufficient.

markdownCopy
You are an expert product operations classifier. Your task is to analyze user feedback and determine whether it describes a feature request, a bug report, or is ambiguous. You must extract structured details to support downstream routing.

### INPUT
[USER_FEEDBACK]

### CLASSIFICATION TAXONOMY
- **feature_request**: The user is asking for new functionality, a change to existing behavior that is currently working as designed, or an improvement. The current system is not broken; the user wants it to do something new or different.
- **bug_report**: The user is reporting something that is broken, not working as documented, producing an error, or behaving in a way that is clearly unintended. The core of the report is a defect, not a desire for new capability.
- **ambiguous**: The feedback is too vague to classify, contains both a bug and a feature request with equal weight, or is not product feedback at all (e.g., general praise, a billing question, spam).

### EXTRACTION RULES
- For **feature_request**: Extract a concise `title`, a `description` of the desired functionality, and the `current_behavior` the user is experiencing.
- For **bug_report**: Extract a concise `title`, `steps_to_reproduce` as a list of strings, `expected_behavior`, and `actual_behavior`.
- For **ambiguous**: Provide a `reason` for the ambiguity and a `suggested_clarification_question` to ask the user.
- Always include a `confidence_score` between 0.0 and 1.0.

### CONSTRAINTS
- Do not invent details not present in the user feedback.
- If you cannot extract a field, use `null`.
- Output must be a single, valid JSON object matching the schema below. No other text.

### OUTPUT_SCHEMA
{
  "classification": "feature_request" | "bug_report" | "ambiguous",
  "confidence_score": <float 0.0-1.0>,
  "extracted_data": {
    "title": "<string | null>",
    "description": "<string | null>",
    "current_behavior": "<string | null>",
    "steps_to_reproduce": ["<string>", ...] | null,
    "expected_behavior": "<string | null>",
    "actual_behavior": "<string | null>",
    "reason": "<string | null>",
    "suggested_clarification_question": "<string | null>"
  }
}

To adapt this template, you must replace the [USER_FEEDBACK] placeholder with the raw text from your system. The taxonomy definitions are the most critical part to tune; adjust the descriptions of feature_request and bug_report to match your team's specific conventions. If your downstream system expects a different schema, modify the OUTPUT_SCHEMA block, but keep the instructions strict. For high-stakes routing where a misclassification could cause a critical bug to be ignored, implement a post-processing validation step that checks the confidence_score and routes anything below a threshold (e.g., 0.8) to a human review queue. Do not rely on the model's confidence score as a calibrated probability without running your own evaluation on a labeled dataset.

This prompt is designed to sit at the ingress point of a product feedback pipeline. In a typical implementation, user-submitted text from a widget, support chat, or email integration hits an API endpoint that injects the input into the [USER_FEEDBACK] placeholder. The model response is parsed as JSON and the classification field drives routing: bug_report triggers issue creation in a bug tracker (e.g., Jira, Linear, GitHub Issues), feature_request routes to a product backlog or ideas portal, and ambiguous queues the item for human triage. The reproduction_steps or feature_description fields are mapped directly into the corresponding tracker's description template, while confidence is logged for later analysis but should not block routing on its own unless it falls below a configured threshold.

Before the classification result touches any downstream API, validate the output against a strict schema. At minimum, confirm that classification is one of the three allowed enum values, that confidence is a float between 0.0 and 1.0, and that the appropriate description field is present and non-empty for the classified intent. If classification is bug_report but reproduction_steps is null or fewer than 20 characters, route to human review. The same applies if feature_request lacks a substantive feature_description. Implement a retry layer: if the model returns malformed JSON or fails schema validation, retry once with the same input and a stronger format instruction appended to the system message. If the second attempt fails, log the raw response and escalate to a dead-letter queue for manual inspection. Do not silently drop feedback because of a parse error.

Model choice matters here. A fast, cost-effective model like GPT-4o-mini, Claude 3.5 Haiku, or Gemini 1.5 Flash is sufficient for this classification task in most cases. Reserve larger models only if your eval suite shows systematic misclassification on ambiguous or edge-case inputs. Wire the prompt into an observability pipeline that logs the input, classification, confidence, and downstream routing target for every request. Set up a periodic eval run against a golden dataset of 200+ labeled examples that includes clear bugs, clear features, ambiguous reports, and adversarial samples (e.g., feature requests disguised as bugs). Monitor the misclassification rate by class, and trigger a prompt review if the bug_report false-positive rate exceeds 5%—misrouting a feature request as a bug wastes engineering time and erodes trust in the routing system.