Greeting vs Task Detection Prompt for Session Start

This prompt solves a narrow but high-stakes routing problem: the first user message of a session. A user who types 'hello' should not trigger a task workflow. A user who types 'I need to reset my password' should not receive a social greeting. And a user who types 'Hi, can you help me with my bill?' requires both acknowledgment and task routing. Misclassification at session start cascades into wrong system behavior, wasted tool calls, and broken user experience. Use this prompt when you need a deterministic classification of greeting, task, or mixed intent before your session router commits to a downstream workflow. It assumes the input is the first turn of a conversation and that no prior session context exists.

This prompt is designed for conversational AI engineers and platform builders who need a reliable, low-latency classification step at the ingress layer. The ideal deployment context is a session-initialization middleware where the output of this prompt directly controls which downstream workflow, agent, or response template is invoked. The prompt expects a single user message as input and returns a structured classification with a recommended system action. It is not designed for multi-turn conversations, ongoing dialogue management, or scenarios where user identity and history should influence routing. If your system already has conversation history, pair this with a follow-up vs new intent detector instead.

Do not use this prompt when the input could contain multiple distinct tasks that require parallel processing, when the user's identity or account tier should influence routing, or when the downstream workflow requires parameter extraction beyond simple intent classification. This prompt is a routing primitive, not a full intent parser. For compound requests, use a multi-intent disambiguation prompt. For workflows requiring extracted entities, chain this prompt's output to a dedicated extraction step. Always validate the output against your expected taxonomy before committing to a downstream action, and monitor for the most common failure mode: casual openers containing embedded tasks that get classified as pure greetings.

This prompt template is designed to be the first classification gate in a conversational AI session. It analyzes the initial user message and determines whether the user is simply greeting the system, immediately issuing a task, or blending social language with an actionable request. The output is a structured JSON object that downstream routing logic can use to decide whether to respond with a welcome message, proceed directly to task execution, or acknowledge the greeting before prompting for the task. The template uses square-bracket placeholders for all variable inputs, making it straightforward to integrate into any prompt assembly pipeline.

textCopy
System: You are a session-start intent classifier. Your only job is to analyze the first user message of a conversation and classify it as one of three types: greeting, task, or mixed. You must return a valid JSON object and nothing else.

[CONTEXT]

Classification Definitions:
- greeting: The user is only saying hello, starting a conversation, or making small talk with no actionable request. Examples: "Hi", "Hello there", "Good morning", "Hey, how are you?"
- task: The user is directly asking for something to be done, providing a command, or making a request with no social preamble. Examples: "What's the weather in Tokyo?", "Summarize this document", "Set a timer for 10 minutes"
- mixed: The user combines a social greeting with an actionable request in the same message. Examples: "Hi, can you help me write an email?", "Good morning! I need a report on Q3 sales"

[INPUT]
User Message: [USER_MESSAGE]

[OUTPUT_SCHEMA]
{
  "classification": "greeting" | "task" | "mixed",
  "confidence": 0.0-1.0,
  "rationale": "Brief explanation of the classification decision",
  "recommended_action": "respond_with_greeting" | "execute_task" | "acknowledge_and_prompt"
}

[CONSTRAINTS]
- Return ONLY the JSON object. No markdown fences, no surrounding text.
- If the message contains only a greeting word or phrase, classify as greeting.
- If the message contains only a task or question, classify as task.
- If the message contains both a greeting and a task, classify as mixed.
- If the message is ambiguous, classify as task and set confidence below 0.7.
- Never classify an empty or whitespace-only message as task; classify as greeting with low confidence.

To adapt this template for your application, replace the [USER_MESSAGE] placeholder with the actual first turn of the user session. The [CONTEXT] placeholder can be extended with domain-specific examples, such as common greetings in your application's language or typical task phrasings your system handles. If your system has a predefined set of task categories, you can add a [TASK_TAXONOMY] placeholder to help the model distinguish between greetings and domain-specific tasks. For high-stakes routing where misclassification could lead to a poor user experience, add a [RISK_LEVEL] parameter that adjusts the confidence threshold for the mixed classification, and ensure your harness logs the rationale field for debugging classification drift over time.

This prompt is designed to sit at the ingress point of a conversational AI system, immediately after a user sends their first message in a session. The implementation harness should treat this as a synchronous classification step that blocks downstream routing until a decision is returned. The prompt expects a single user message as input and produces a structured JSON classification. The harness must validate that the output conforms to the expected schema before allowing the session to proceed to either a greeting handler, a task handler, or a mixed-intent clarification flow. Because this classification controls which tools, models, and policies are loaded for the remainder of the session, a misclassification at this stage is expensive—it can route a task-bearing message to a casual chit-chat model that lacks tool access, or send a simple 'hello' through an expensive agent pipeline with unnecessary function calls.

Wire the prompt into your application as a pre-routing middleware function. On session start, extract the user's first message and inject it into the [USER_MESSAGE] placeholder. Set a strict timeout of 500-800ms for the classification call; if the model does not respond within that window, fall back to a conservative 'greeting' classification to avoid blocking the user experience. Validate the JSON response against the expected schema: classification must be one of greeting, task, or mixed; confidence must be a float between 0.0 and 1.0; recommended_action must be one of respond_with_greeting, route_to_task_handler, or clarify_and_route. If validation fails, log the raw response for debugging and retry once with a stricter prompt variant that emphasizes schema compliance. If the retry also fails, escalate to a human review queue and respond to the user with a generic 'How can I help you today?' message to avoid a dead session. For high-traffic systems, cache the classification result in the session object so downstream handlers can reference it without re-classifying.

Model choice matters here. Use a fast, cost-efficient model for this classification step—GPT-4o-mini, Claude Haiku, or a fine-tuned small classifier are appropriate. Do not route this prompt to a large reasoning model; the latency and cost are unjustified for a binary-to-ternary classification task. Implement logging that captures the user message, the classification output, the validation result, and the final routing decision in a structured format. This log becomes your evaluation dataset for measuring misclassification rates over time. Set up a weekly review of sessions where the classification was greeting but the user's second message contained a task—these are false negatives that indicate the prompt is missing task-bearing language disguised as social openers. Conversely, monitor sessions classified as task where the user responded with 'just saying hi'—these false positives waste compute and create awkward user experiences. Both failure modes should trigger a review of the prompt's examples and potentially an update to the few-shot demonstrations.