Feature Request Domain Categorization Prompt

Product teams and AI platform engineers use this prompt to route unstructured feature requests to the correct product area, distinguish new features from improvements and bug fixes, and detect cross-domain implications. The prompt is designed for classification and routing middleware where downstream tool access, context retrieval, and team assignment depend on accurate domain mapping. It accepts raw user text—from a support ticket, a sales call summary, or a feedback widget—and returns a structured classification payload that a routing engine can act on without further human parsing.

Use this prompt when you need a deterministic, auditable classification that feeds into product backlogs, roadmap tools, or triage queues. The ideal implementation wraps the prompt in a thin API or queue-worker harness that validates the output schema, logs the classification decision, and routes the payload to the correct product manager or engineering team. This prompt is built for backend middleware, not for direct user interaction. It expects a defined product area taxonomy, clear rules for distinguishing request types, and a known set of cross-domain signals to check. Without these inputs, the model will guess, and guessing breaks downstream routing.

Do not use this prompt for real-time customer-facing chatbots, legal or compliance document review, or any workflow where misclassification creates regulatory exposure without a human review step. It is also a poor fit for open-ended ideation sessions where the goal is creative exploration rather than structured triage. If your taxonomy changes frequently, pair this prompt with a versioned taxonomy reference and a regression test suite that re-evaluates classification accuracy against a golden set of labeled requests. The next section provides the copy-ready prompt template you can adapt to your product domains.

The following prompt template is designed to be copied directly into your AI harness. It maps unstructured feature requests to a defined product domain taxonomy, distinguishes new features from improvements and bug fixes, and flags requests with cross-domain implications. All placeholders use square brackets and must be replaced with your specific taxonomy, constraints, and output requirements before use.

textCopy
You are a product triage assistant. Your job is to categorize incoming feature requests into the correct product domain and evaluate their scope.

## TAXONOMY
Use ONLY the following product domains:
[DOMAIN_LIST]

## INPUT
Feature request: [FEATURE_REQUEST_TEXT]
Submitter context (optional): [SUBMITTER_CONTEXT]

## INSTRUCTIONS
1. Classify the request into exactly ONE primary domain from the taxonomy above.
2. Determine the request type: "new_feature", "improvement", or "bug_fix".
3. Identify any secondary domains that are implicated by this request (cross-domain implications).
4. Assign a confidence score from 0.0 to 1.0 for your primary domain classification.
5. If confidence is below [CONFIDENCE_THRESHOLD], set primary_domain to "needs_clarification".
6. If the request does not fit any domain, set primary_domain to "out_of_scope".

## CONSTRAINTS
- Do not invent domains outside the taxonomy.
- If the request mentions multiple domains, choose the most specific one as primary.
- Distinguish improvements (enhancing existing functionality) from new features (net-new capability).
- Bug fixes describe broken behavior; improvements describe working behavior that could be better.
- Flag cross-domain implications even when confidence in the primary domain is high.

## OUTPUT_SCHEMA
Return ONLY valid JSON with this structure:
{
  "primary_domain": "string",
  "request_type": "new_feature | improvement | bug_fix",
  "confidence": 0.0-1.0,
  "cross_domain_implications": ["domain_a", "domain_b"],
  "reasoning": "Brief explanation of classification decision"
}

To adapt this template, replace [DOMAIN_LIST] with your actual product domain taxonomy as a structured list. Set [CONFIDENCE_THRESHOLD] to a value appropriate for your routing logic—0.7 is a common starting point for auto-routing, while 0.5 may be acceptable if human review follows. The [FEATURE_REQUEST_TEXT] placeholder should receive the raw user input, and [SUBMITTER_CONTEXT] can carry metadata such as user role, account tier, or prior request history. Before deploying, run this prompt against a golden dataset of at least 50 labeled examples and measure precision and recall per domain. Pay special attention to the boundary between improvements and bug fixes, as this distinction is the most common source of misclassification in production.

This prompt is designed to be a single step inside a larger classification pipeline. The application layer is responsible for providing the [PRODUCT_DOMAIN_TAXONOMY] and [REQUEST_DEFINITIONS] context, calling the model, validating the structured output, and deciding what happens next based on the confidence score and domain assignment. Do not treat this prompt as a standalone chatbot interaction; it must be wrapped in application logic that enforces the output schema and handles failures gracefully.

Start by loading the taxonomy and definitions from a configuration store or database at runtime, not hardcoded in the prompt. The [PRODUCT_DOMAIN_TAXONOMY] should be a JSON array of domain objects with id, name, and description fields. The [REQUEST_DEFINITIONS] should include clear criteria for distinguishing new features from improvements and bug fixes. Before calling the model, validate that the taxonomy has no duplicate domain names and that every domain has a non-empty description. After receiving the model response, parse the JSON output and run these validation checks: (1) primary_domain must match exactly one domain ID from the provided taxonomy, (2) confidence_score must be a float between 0.0 and 1.0, (3) request_type must be one of new_feature, improvement, or bug_fix, and (4) cross_domain_implications must be an array of valid domain IDs or empty. If validation fails, retry once with the error message appended to the prompt as additional [CONSTRAINTS] context. If the retry also fails, route the input to a human review queue with the raw model output and validation errors attached.

For model choice, use a model with strong structured output support and low latency, such as GPT-4o or Claude 3.5 Sonnet, since this is a synchronous classification step that blocks downstream routing. Set temperature to 0 to maximize deterministic behavior. Log every classification event with the input text, assigned domain, confidence score, request type, model version, and latency. This log becomes your audit trail for measuring domain drift, confidence calibration, and taxonomy coverage gaps over time. If confidence_score falls below a configurable threshold (start with 0.7 and tune based on production data), route to human review rather than auto-dispatching. For high-volume systems, consider caching classifications for identical or near-identical inputs using a semantic deduplication layer to reduce model calls and cost.

The most common production failure mode is taxonomy mismatch: the model assigns a domain that sounds plausible but doesn't exist in your actual taxonomy, or it hallucinates a domain name. The validation step catches this, but you should also monitor for inputs that consistently produce low confidence scores—these signal gaps in your taxonomy that need new domains or clearer descriptions. Another failure mode is misclassifying bug reports as feature requests when the user describes desired behavior that already exists but isn't working. Mitigate this by including strong counterexamples in the [REQUEST_DEFINITIONS] that illustrate the boundary between 'this should work differently' (improvement) and 'this is broken' (bug). Finally, never use this prompt's output to automatically commit changes to a product backlog or roadmap tool without human approval. The classification should trigger routing and context assembly, not autonomous prioritization decisions.