Structured Ticket Generation Prompt from User Reports

This prompt is designed for the support-to-engineering handoff: converting unstructured customer emails, chat transcripts, or voice-to-text reports into internal bug tickets that developers can act on immediately. It extracts the core symptom, reproduction steps, environment details, user impact, and acceptance criteria from raw user language. Use this when your support team spends more time rewriting tickets than resolving issues, or when inconsistent ticket quality causes engineering rework.

This prompt assumes you already have a user report and a target ticket schema. It does not classify severity, detect duplicates, or route to teams. Pair it with the severity classification, duplicate detection, and routing prompts in this pillar for a complete triage pipeline. The prompt works best with reports that contain at least a symptom description and some environment context—it will flag missing critical fields rather than hallucinate them, but it cannot invent reproduction steps that were never provided.

Do not use this prompt for live chat where the agent needs to ask clarifying questions interactively—that requires a different conversation-state-aware prompt. Avoid it for reports containing multiple unrelated bugs; split those into separate inputs first. If your user reports are already structured (e.g., form submissions with typed fields), you likely need a simpler mapping layer rather than this extraction prompt. For regulated environments where ticket content must be auditable, ensure you log the raw input alongside the generated ticket and implement human review before the ticket reaches an engineering queue.

This prompt template is the core instruction set for your AI harness. It takes raw user reports—emails, chat transcripts, or support form submissions—and extracts the signal needed for engineering triage. The prompt enforces a strict output schema, requires explicit 'unknown' markers for missing information, and separates user-reported facts from model-inferred impact. Before integrating, review the placeholders and ensure your application layer supplies the required context variables.

textCopy
You are a technical triage assistant converting unstructured user reports into structured internal bug tickets. Your output must be valid JSON conforming to the schema below. Do not invent details not present in the report. Use the exact string 'UNKNOWN' for any required field where the report provides no information.

## INPUT
[USER_REPORT]

## CONTEXT
Current Product Version: [PRODUCT_VERSION]
Deployment Environment: [DEPLOYMENT_ENVIRONMENT]
Component Catalog: [COMPONENT_CATALOG]
Severity Rubric: [SEVERITY_RUBRIC]

## OUTPUT SCHEMA
{
  "ticket": {
    "title": "string (concise summary of the core symptom, max 100 chars)",
    "description": "string (clear technical description of the observed behavior, preserving all user-provided technical details)",
    "reproduction_steps": [
      {
        "step_number": "integer",
        "action": "string",
        "expected_result": "string",
        "actual_result": "string"
      }
    ],
    "environment": {
      "os": "string | UNKNOWN",
      "browser": "string | UNKNOWN",
      "app_version": "string | UNKNOWN",
      "device": "string | UNKNOWN"
    },
    "severity": {
      "level": "string (must match one of the levels in the provided Severity Rubric)",
      "justification": "string (explain why this severity was chosen based on the rubric definitions and the report's evidence)"
    },
    "component": {
      "name": "string (must match an entry in the provided Component Catalog)",
      "confidence": "number (0.0 to 1.0)"
    },
    "impact_assessment": {
      "affected_user_segment": "string | UNKNOWN",
      "blocks_critical_workflow": "boolean",
      "revenue_risk_note": "string | UNKNOWN"
    },
    "acceptance_criteria": [
      "string (a verifiable condition that must be true for the fix to be accepted)"
    ]
  }
}

## CONSTRAINTS
- Do not fabricate reproduction steps. If the user describes them, extract and number them. If not, return an empty array.
- For the 'component' field, select the single best match from the Component Catalog. Set confidence below 0.5 if the mapping is ambiguous.
- The 'impact_assessment' fields are inferences. Base them strictly on the user's description of their role and workflow. Do not assume enterprise impact for a personal-use report.
- Generate at least one acceptance criterion that directly verifies the reported failure mode.

To adapt this template, replace the square-bracket placeholders with data from your application context. [USER_REPORT] should contain the full raw text. [COMPONENT_CATALOG] should be a structured list of your system's services or modules, such as ['auth-service', 'payment-gateway', 'user-profile', 'dashboard-ui']. [SEVERITY_RUBRIC] must define your organization's severity levels with clear criteria (e.g., 'S1: System down, all users blocked'). If your application does not have a formal rubric, provide a simple three-tier definition inline. The [PRODUCT_VERSION] and [DEPLOYMENT_ENVIRONMENT] fields anchor the report to a specific release, which is critical for regression detection. After pasting the prompt, validate that your harness parses the JSON output and checks every field against the schema before creating a ticket in your issue tracker.

This prompt is designed to sit inside an API handler that receives raw user reports—email bodies, chat transcripts, or web form submissions—and returns a structured ticket payload. The harness is responsible for preparing the input, calling the LLM, validating the output, and deciding whether to auto-create the ticket or queue it for human review. The prompt itself handles the transformation logic, but the surrounding code must enforce the contract: the output must match the expected schema, contain no hallucinated fields, and preserve critical user context that a developer will need to reproduce the issue.

Start by constructing the prompt payload with the required placeholders. The [INPUT] field receives the raw user report text, cleaned of signatures and disclaimers but otherwise unmodified. The [OUTPUT_SCHEMA] field should contain the exact JSON schema you expect, including required fields (title, description, reproduction_steps, environment, severity, impact_statement, acceptance_criteria) and enum constraints for severity levels (S1 through S4). The [CONSTRAINTS] field should specify that the model must not invent details not present in the report, must mark missing information as "unknown" rather than guessing, and must preserve the user's original language for symptom descriptions. If your system maintains a component catalog or team routing map, pass it as [CONTEXT] so the model can suggest ownership. Call the LLM with a low temperature (0.0–0.2) to maximize schema consistency, and set response_format to JSON mode if your provider supports it. On receiving the response, validate it immediately: check that all required fields are present, severity is a valid enum value, reproduction steps are an array of strings, and no field contains placeholder text like "N/A" or "todo". If validation fails, retry once with the validation errors appended to the prompt as additional constraints—this often resolves minor format drift. If the second attempt also fails, route the ticket to a human triage queue with the raw report and both failed attempts attached.

For high-risk deployments where tickets may trigger pager alerts or customer-facing SLAs, add a confidence gate. After validation passes, run a secondary eval prompt that scores the output on three axes: completeness (are all reportable symptoms captured?), faithfulness (are any details invented?), and actionability (can a developer start debugging from this ticket?). If any score falls below your threshold, flag the ticket for human review. Log every LLM call with the input report, the generated ticket, validation results, and the final routing decision. This audit trail is essential for debugging prompt drift and for demonstrating triage consistency to compliance reviewers. Avoid wiring this prompt directly to automatic ticket creation in your issue tracker without a review gate unless you have calibrated the eval thresholds against at least 100 real user reports and confirmed that the false-positive rate for auto-creation is acceptable for your team's response SLAs.