Session Closeout Checklist Prompt for Unresolved Work

This prompt is designed for AI assistants and copilots that must confirm all work is resolved before a session ends. It generates a user-facing checklist of every detected open item, asks for explicit disposition on each, and refuses to close the session if items remain unresolved. Use this when session closeout carries operational risk: dropped support tickets, incomplete handoffs, or compliance gaps. This prompt belongs in the final stage of a conversation lifecycle, after the assistant has attempted to answer questions and complete tasks, but before the session state is archived or transferred. It is not a general summarizer or a task tracker; it is a safety gate that prevents premature session termination.

The ideal user is an engineering lead or product manager building a production assistant where session termination triggers downstream workflows—ticket closure, handoff to human agents, or compliance archiving. The required context includes a structured list of open items (questions, tasks, commitments) that the system has tracked across turns. Without this tracking data, the prompt cannot perform its core function. Do not use this prompt for casual chat sessions, stateless Q&A, or workflows where session termination has no operational consequence. It is also inappropriate for real-time safety-critical systems where a refusal to close could block emergency escalations.

Before implementing, ensure your application layer maintains an explicit open-item state object. The prompt consumes this state and enforces resolution, but it does not detect open items from raw transcripts—that detection should happen upstream using dedicated tracking prompts or state management middleware. Wire this prompt as the final gate in your session termination flow, with a hard block on closure if the model returns unresolved items. Always log the checklist output and user dispositions for auditability. If your use case involves regulated domains, pair this prompt with human review for any item marked as deferred or escalated.

This template is the core instruction set for generating a session closeout checklist. It forces the model to inventory every open question, deferred task, and unfulfilled commitment before allowing a session to end. The prompt is designed to be copied directly into your prompt management layer, with square-bracket placeholders that your application must populate from the current conversation state, user profile, and risk policy before each inference call.

textCopy
You are a session closeout auditor for [ASSISTANT_NAME], a [ASSISTANT_ROLE] assistant. Your job is to prevent sessions from ending with unresolved work.

## CONTEXT
- Current conversation transcript: [CONVERSATION_TRANSCRIPT]
- Open items tracked by the system: [TRACKED_OPEN_ITEMS]
- User's closeout request: [USER_CLOSEOUT_MESSAGE]
- Session duration: [SESSION_DURATION]
- Risk level for this domain: [RISK_LEVEL]

## TASK
Generate a structured closeout checklist for the user. The checklist must include:
1. Every question the user asked that was not fully answered.
2. Every task the assistant committed to complete that remains undone.
3. Every action item the user requested that has no confirmed resolution.
4. Every approval or decision that is still pending.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "session_summary": "One-sentence summary of what the session covered.",
  "total_open_items": <integer>,
  "items": [
    {
      "id": "item-<unique-integer>",
      "type": "unanswered_question | unfulfilled_commitment | pending_action | pending_approval",
      "description": "What the user asked for or what was promised.",
      "source_turn_reference": "Quote or paraphrase from the transcript showing where this originated.",
      "severity": "blocking | high | medium | low",
      "recommended_disposition": "answer_now | schedule_followup | transfer_to_human | confirm_no_longer_needed",
      "blocking_closeout": <true | false>
    }
  ],
  "closeout_blocked": <true | false>,
  "blocking_reason": "If closeout is blocked, explain why in one sentence. Otherwise null.",
  "safe_closeout_message": "If closeout is allowed, provide the message to show the user. Otherwise null.",
  "required_user_confirmations": [
    "List of explicit confirmations the user must provide before the session can close."
  ]
}

## RULES
- Do not invent items. Only include items with clear evidence in the transcript or tracked state.
- A rhetorical question or a question the user answered themselves is not an open item.
- If the assistant said 'I'll follow up' or 'I'll check on that,' it is an unfulfilled commitment.
- If [RISK_LEVEL] is 'high' or 'critical,' treat any unconfirmed resolution as blocking.
- If closeout is blocked, the safe_closeout_message must be null.
- If no open items exist, set total_open_items to 0, items to [], closeout_blocked to false, and provide a safe_closeout_message.
- Do not include items the user explicitly said they no longer need.

## CONSTRAINTS
- [CONSTRAINTS]

To adapt this template, replace each placeholder with live data from your application. [CONVERSATION_TRANSCRIPT] should contain the full turn history, not a summary. [TRACKED_OPEN_ITEMS] should come from your state management layer—if you don't have one, omit this field and rely on transcript analysis alone, but expect lower recall on implicit commitments. [CONSTRAINTS] is where you inject domain-specific rules, such as 'financial advice sessions cannot close with unanswered risk questions' or 'healthcare sessions require explicit disposition on every medication-related question.' For high-risk domains, always set [RISK_LEVEL] to 'high' or 'critical' to force blocking behavior on unresolved items. Test this prompt against transcripts with known dropped questions and verify that the output flags every one before you ship.

The Session Closeout Checklist prompt is designed to be the final gate before a session is terminated in a support, task, or copilot application. It should be invoked when the system detects a user intent to end the session, or when a session timeout is approaching. The prompt requires a structured list of all unresolved items from the conversation state as input. Do not call this prompt without first running a pending-item detection step; feeding it an empty or stale list will produce a false sense of closure. The prompt's primary job is to generate a user-facing checklist and enforce a refusal if the user attempts to close without explicit disposition on every item.

Wire this prompt into your application as a pre-closeout hook. The application must maintain a canonical list of unresolved items—questions, tasks, commitments, approvals—keyed by a stable ID. When a closeout event fires, serialize that list into the [UNRESOLVED_ITEMS] placeholder as a structured JSON array. The model will return a JSON response containing a checklist array and a closeout_permitted boolean. Your application must parse this response and enforce the refusal: if closeout_permitted is false, block the session close and display the generated checklist to the user. If true, proceed with closeout but log the final disposition of every item. Implement a retry loop with a maximum of 2 attempts if the output fails JSON schema validation; after that, escalate to a human reviewer rather than silently closing. Use a model with strong instruction-following and JSON mode enabled (e.g., GPT-4o, Claude 3.5 Sonnet) to minimize malformed refusals.

For high-stakes domains like healthcare, finance, or legal support, add a human-in-the-loop step after the checklist is generated but before the session is closed. The application should present the checklist and the model's proposed dispositions to a supervisor for sign-off. Log the full prompt, response, and human decision in an audit trail that includes timestamps, item IDs, and the identity of the reviewer. Avoid the failure mode where the model marks an item as 'resolved' based on weak evidence; your validation layer should cross-check each resolved item against the conversation transcript using a secondary verification prompt or deterministic rule. The most common production failure is the model generating a permissive closeout_permitted: true when items are only partially addressed—mitigate this by setting a high bar in the [CONSTRAINTS] block and testing with edge cases where the user provides vague confirmations like 'yeah that's fine' without actually resolving the underlying issue.