Small Talk vs Task Phase Detection Prompt

This prompt is a pre-processing gate for task-oriented assistants, copilots, and support bots that maintain internal state across conversation turns. Its job is to classify each user utterance as social (greetings, thanks, jokes, off-topic remarks) or task (commands, questions, workflow inputs) and then decide whether the assistant's operational state should advance, pause, or ignore the turn. Without this gate, a user saying 'thanks, that worked' can trigger the next step in a workflow, or a greeting can reset a partially completed form. The prompt is designed to be called before your main assistant logic, acting as a state-machine firewall.

Use this prompt when your application maintains any form of multi-turn state—open tickets, active workflows, pending slot-filling, or agent task queues—and you observe state corruption from non-operational turns. It is particularly valuable in customer support chatbots where users interleave politeness with problem descriptions, in sales copilots where relationship-building language should not advance a qualification checklist, and in any voice or text assistant where real human conversation patterns include social noise. The prompt outputs a structured decision (social or task) and a recommended state action (advance, pause, ignore), which your application layer uses to gate state transitions. Do not use this prompt for single-turn, stateless completions or for purely social chatbots where there is no operational state to protect.

This prompt is not a response generator. It does not produce user-facing text, answer questions, or execute tasks. It is a classification and decision component that belongs in your application's middleware, called synchronously before the main model invocation. The output should be parsed by your state manager, not shown to users. If your assistant needs to generate a social response (e.g., 'You're welcome!'), that should be handled by a separate response prompt after this classification confirms the turn is non-operational. Avoid the temptation to merge classification and response generation into one prompt; separation keeps the decision logic testable and prevents the model from accidentally advancing state while being polite.

This prompt template is designed to be placed before your main assistant prompt or used as a pre-processing classifier. It forces a structured decision about whether the current user turn advances a defined workflow or is a social, off-topic, or relationship-building utterance. The output is a machine-readable classification plus a boolean flag that downstream logic can use to decide whether to update task state, trigger a tool, or respond with a social script. Adapt the placeholders to match your specific task taxonomy, risk tolerance, and output schema requirements.

textCopy
You are a turn classifier for a task-oriented assistant. Your job is to analyze the current user turn and decide whether it represents task progress or small talk.

## TASK DEFINITION
[TASK_DESCRIPTION]

## CONVERSATION HISTORY
[CONVERSATION_HISTORY]

## CURRENT USER TURN
[USER_TURN]

## CLASSIFICATION RULES
1. A turn is TASK if it provides information, asks a question, or makes a request that directly advances the defined task.
2. A turn is SMALL_TALK if it is social, off-topic, relationship-building, or does not move the task forward.
3. Clarification questions about the task itself are TASK.
4. Social digressions that contain embedded task-relevant information should be classified as TASK.
5. Abrupt returns to task after social digression are TASK.
6. Gratitude, acknowledgments, and filler phrases without task content are SMALL_TALK.

## OUTPUT SCHEMA
Return ONLY valid JSON matching this schema:
{
  "turn_type": "TASK" | "SMALL_TALK",
  "confidence": 0.0-1.0,
  "advance_task_state": true | false,
  "rationale": "Brief explanation of the classification decision.",
  "task_relevant_content": "Extracted task-relevant content if turn_type is TASK, otherwise null."
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

To adapt this template, replace [TASK_DESCRIPTION] with a concise statement of what your assistant's task workflow entails. Populate [CONVERSATION_HISTORY] with the last N turns formatted consistently. Set [CONSTRAINTS] to include domain-specific rules, such as handling of PII, tone boundaries, or escalation triggers. Provide at least three [EXAMPLES] covering clear task turns, clear small talk, and boundary cases like relationship-building within task context. Wire the advance_task_state boolean directly into your application's state machine: when false, do not update task slots, do not call task tools, and route to a social response handler. When true, proceed with normal task execution. Test boundary cases aggressively—users who embed task information in social language, users who return to task mid-sentence after a digression, and turns that contain both gratitude and a follow-up question.

This prompt is a classification step, not a generation endpoint. It should sit inside a lightweight middleware function that runs before your main task-processing logic. The function receives the latest user turn plus a compact representation of the current conversation state (active task, phase, pending actions). It returns a structured decision that your application uses to either advance the task state machine or route the turn to a social-response handler. Do not use this prompt to generate the assistant's reply directly; its job is to produce a control signal.

Wire the prompt into a detect_turn_phase() function with these inputs: the raw user message, the current task_state object (containing active_task_id, current_phase, and pending_confirmations), and the last two assistant turns for context. The function should call the model with temperature=0 and response_format set to the JSON schema defined in the prompt template. Parse the response and validate that turn_type is one of task_progress, small_talk, relationship_building_in_task, or abrupt_return_to_task. If turn_type is task_progress, validate that should_advance_task_state is true and the task_phase_update field is populated. If turn_type is small_talk, validate that should_advance_task_state is false. Reject and retry once if the output fails schema validation or contains contradictory fields (e.g., small_talk with should_advance_task_state: true).

The two boundary cases—relationship_building_in_task and abrupt_return_to_task—require special handling in your harness. For relationship_building_in_task, your application should acknowledge the social content briefly, then continue the task flow without advancing the phase. For abrupt_return_to_task, your application should treat the turn as task_progress but log the phase discontinuity for review. Implement a simple state machine that tracks the last three turn_type classifications. If you see a pattern of small_talk → abrupt_return_to_task → task_progress, suppress any unnecessary confirmation prompts and resume the task directly. If you see relationship_building_in_task followed by small_talk with no task content, consider prompting the user to confirm they want to pause the task.

Log every classification result with the user message hash, the turn_type, the confidence score, and the rationale field. This log becomes your evaluation dataset for tuning the prompt later. Set up a weekly review of low-confidence classifications (confidence below 0.7) and any cases where the rationale mentions ambiguity between small_talk and relationship_building_in_task. These are your highest-signal samples for few-shot example improvement. If you're deploying in a regulated domain where task state changes have compliance implications, route all abrupt_return_to_task classifications to a human review queue before advancing the task state machine.