Conversation Repair Prompt for Forgotten Questions

This prompt is designed for a specific production failure mode: the assistant's tracking middleware has flagged an unanswered user question from a prior turn, but the conversation has since moved on. The job-to-be-done is to generate a single repair turn that acknowledges the oversight, provides the answer or re-queues the question, and rebuilds user trust without derailing the current topic. The ideal user is an AI engineer or product developer integrating this prompt into a stateful chat system where a separate 'pending question tracker' component already exists and can inject the [UNANSWERED_QUESTION] and its [ORIGINAL_TURN_CONTEXT] into the prompt assembly step.

You should use this prompt when your system has high-confidence detection of a dropped question and the current turn is a natural pause point—such as after the assistant has finished responding to the immediate topic. Do not use this prompt if the unanswered question is ambiguous, if the user is mid-correction, or if the conversation is in a high-urgency flow where an interruption would be disruptive. The prompt requires the following inputs to be wired in: [CURRENT_CONVERSATION_SUMMARY], [UNANSWERED_QUESTION], [ORIGINAL_TURN_CONTEXT], and [CURRENT_USER_MESSAGE]. Without these, the model cannot calibrate whether the repair turn is timely or tone-deaf. The output is a single assistant message, not a state mutation; your application layer must update the pending-question tracker after a successful or failed repair.

This prompt is not a substitute for a tracking system. It assumes the detection work is already done. It also does not handle multiple simultaneous dropped questions—if your tracker surfaces more than one, you should prioritize by severity or blocking status before calling this prompt. For high-stakes domains such as healthcare or finance, the generated repair message must be routed through a human review queue before being sent to the user. The next step after reading this section is to review the prompt template and adapt the [CONSTRAINTS] block to match your product's tone policy and apology guidelines.

This template is the core instruction set for a conversation repair model. It is designed to be invoked by an upstream state management system that has already detected a dropped question and identified the specific turn where it was asked. The prompt's job is not to detect the dropped question—that is handled by a separate detection prompt—but to generate a single, honest, and concise repair message that acknowledges the oversight, provides the answer or re-queues the question, and rebuilds user trust without over-apologizing. The template uses square-bracket placeholders for all dynamic inputs, making it ready for programmatic assembly in a production harness.

textCopy
You are a conversation repair assistant. Your only job is to generate a single repair message when the system detects that a user's question was dropped earlier in the conversation.

## CONTEXT
- Current conversation transcript: [CONVERSATION_TRANSCRIPT]
- Turn number where the dropped question was asked: [DROPPED_TURN_NUMBER]
- The exact dropped question text: [DROPPED_QUESTION]
- Reason the question was dropped (if known): [DROP_REASON]
- Current conversation topic: [CURRENT_TOPIC]
- User sentiment signal (if available): [USER_SENTIMENT]

## CONSTRAINTS
- Acknowledge the oversight exactly once. Do not over-apologize or use groveling language.
- If you can answer the question now, do so directly before reconnecting to the current topic.
- If you cannot answer the question, state that clearly and ask if the user still needs it resolved.
- Do not fabricate an answer. If the answer is not in the transcript or your knowledge, say so.
- Bridge naturally back to the current conversation topic after addressing the dropped question.
- Keep the repair message under [MAX_REPAIR_TOKENS] tokens.
- Do not introduce new topics or questions unrelated to the dropped question.

## OUTPUT FORMAT
Return a JSON object with the following schema:
{
  "repair_message": "string (the full repair turn text)",
  "question_addressed": boolean,
  "answer_provided": boolean,
  "requires_user_input": boolean,
  "bridge_to_current_topic": boolean
}

## EXAMPLES
Example 1 (answer available):
Input: Dropped question was "What's the refund window?" from turn 4. Current topic is shipping options.
Output: {
  "repair_message": "Earlier you asked about our refund window—sorry I missed that. Our standard refund window is 30 days from delivery. To circle back to shipping, would you like standard or expedited?",
  "question_addressed": true,
  "answer_provided": true,
  "requires_user_input": false,
  "bridge_to_current_topic": true
}

Example 2 (answer unavailable):
Input: Dropped question was "Can you check my account balance?" from turn 2. System note: no account access tool available.
Output: {
  "repair_message": "I realize I didn't address your question about checking your account balance earlier. I don't have access to account balances in this chat, but I can connect you with someone who does if you still need that. In the meantime, we were discussing your recent order—shall I continue with that?",
  "question_addressed": true,
  "answer_provided": false,
  "requires_user_input": true,
  "bridge_to_current_topic": true
}

Now generate the repair message for the dropped question described in the context above.

Adapt this template by adjusting the [CONSTRAINTS] section to match your product's tone guidelines and compliance requirements. For regulated domains, add explicit instructions about when the repair must escalate to a human agent rather than attempting an answer. The output schema fields—especially answer_provided and requires_user_input—are designed to feed into downstream routing logic, so preserve them even if you extend the schema with additional fields. Before deploying, run this prompt against a golden set of dropped-question scenarios that includes cases where the answer is available, unavailable, partially available, and where the user has already moved on. Measure both the repair message quality and the accuracy of the boolean flags.

The Conversation Repair Prompt is designed to be invoked programmatically by a state management middleware layer, not by the user directly. Your application should maintain a structured tracking object of all user questions and their resolution status across turns. When the tracking system detects an unanswered question that has aged past a configurable threshold (e.g., 3 turns or 90 seconds of silence), it should inject the repair prompt into the model's context with the current conversation history and the specific dropped question. The prompt should be treated as a high-priority system instruction that overrides the normal conversational flow, forcing the assistant to acknowledge and address the oversight before continuing.

Wire the prompt into your application with these concrete components: Input assembly requires the full conversation transcript up to the current turn, the specific unanswered question text, the turn number where it was originally asked, and a severity score from your tracking system. Model selection should favor models with strong instruction-following and tone control—GPT-4o or Claude 3.5 Sonnet are appropriate defaults. Output validation must check that the response contains an explicit acknowledgment of the dropped question, does not over-apologize (use a regex or LLM-as-judge to flag excessive apology language like multiple 'sorry' instances or self-deprecating phrases), and either answers the question or re-queues it with a clear next step. Retry logic should attempt one repair if validation fails, then escalate to a human agent with the full context if the second attempt also fails. Logging must capture the repair trigger reason, the generated response, validation results, and whether the user accepted or rejected the repair in the subsequent turn.

For high-stakes domains like healthcare or finance, add a human review gate before the repair message is sent to the user. Route the proposed repair to a review queue where a human can approve, edit, or reject it within a timeout window. If the timeout expires, default to a safe fallback that simply re-queues the question without attempting an answer. Avoid deploying this prompt in fully autonomous mode for any workflow where a dropped question could have safety, compliance, or financial consequences. The repair prompt is a recovery mechanism, not a substitute for robust question tracking—invest in your detection layer first, and use this prompt only when detection confidence is high enough to justify an interruption.