Truncated List Item Completion Prompt Template

This prompt template is designed for a single, high-stakes job: recovering an enumerated list that was cut off mid-item by a token limit, streaming interruption, or model early-stopping. The ideal user is a production engineer or API developer operating a summarization, extraction, or list-generation pipeline where a partial output is worse than no output. You have a truncated string containing a numbered or bulleted list, and you need the model to intelligently complete the final truncated item and then continue generating any remaining items that were never started. This is not a general-purpose list generator; it assumes you already have a partial, well-formatted list and need surgical repair, not a rewrite.

Use this prompt when the truncation point is inside a list item's content, not between items. The model must detect the item boundary, infer the incomplete item's intent from its partial text, complete it in the same style and format, and then continue with subsequent items if the original list was clearly meant to be longer. This requires the model to understand the list's schema—whether items are sentences, paragraphs, JSON objects, or code blocks—and to preserve that schema exactly. The prompt is most effective when you provide the full original task context (e.g., 'Summarize the following document into 5 key points') alongside the partial output, so the model knows the intended scope and can decide whether more items are needed. Do not use this prompt for lists truncated cleanly between items; that's a simpler continuation task. Do not use it when the truncation point is ambiguous or the list format is inconsistent.

Before wiring this into a production harness, define clear failure modes and evaluation criteria. The primary failure mode is the model hallucinating a completion that contradicts the partial item's visible text or inventing list items that weren't implied by the original task. A secondary failure is format drift—the completed item or new items using a different numbering style, indentation, or delimiter than the original list. Your eval harness should check: (1) the repaired item's first N characters match the truncated input exactly, (2) the completed item is semantically coherent with the visible fragment, (3) all items follow the same format pattern, and (4) the total item count is reasonable given the original task. For high-risk domains like legal or clinical summarization, always route repaired outputs for human review before they reach downstream systems or users.

This template is designed for production pipelines that recover from truncated enumerated outputs. It provides a structured instruction set that can be copied directly into your application, with placeholders for the specific inputs, context, and constraints of your use case. The prompt is engineered to detect the boundary of the last complete item, finish that item if it was cut off, and then continue generating any remaining items that were expected but not yet produced.

textCopy
SYSTEM: You are a precise output repair agent. Your task is to recover a truncated enumerated list. You will receive a partial list that was cut off mid-generation. Your job is to:
1. Identify the last complete list item.
2. If the text ends with a partially written item, complete that item in a way consistent with the preceding items' style, depth, and format.
3. Continue generating any remaining list items that were expected but not yet written, based on the original task context.
4. Preserve the exact enumeration style (numbers, bullets, letters), indentation, and markdown formatting of the original list.
5. Do not repeat any items that were already complete. Do not add a preamble or commentary. Output only the continuation, starting from the truncated item.

[ORIGINAL_TASK_CONTEXT]
[PARTIAL_OUTPUT]
[EXPECTED_TOTAL_ITEMS]
[OUTPUT_FORMAT_NOTES]

To adapt this template, replace each square-bracket placeholder with the specific information for your recovery scenario. [ORIGINAL_TASK_CONTEXT] should contain the original prompt or instruction that produced the list, so the model understands the intended scope and style. [PARTIAL_OUTPUT] is the exact truncated text you received. [EXPECTED_TOTAL_ITEMS] can be a specific number (e.g., '10 items total') or a description (e.g., 'one item per quarter of 2024'). [OUTPUT_FORMAT_NOTES] should describe the list format, such as 'numbered list with bolded item titles and two-sentence descriptions.' After inserting your values, test the prompt with known truncation cases and validate that the continuation stitches seamlessly without duplicating the last complete item or altering its content.

Integrating the Truncated List Item Completion prompt into an application requires a harness that can detect truncation, extract the partial list, manage the completion request, and validate the reassembled output. The core loop begins with a truncation detector—a lightweight function that inspects the model's raw response for a finish_reason of length or max_tokens and confirms that the final line is an incomplete list item (e.g., a bullet point ending mid-sentence, a numbered item without a closing newline, or a JSON array missing its closing bracket). If the detector fires, the harness extracts the last complete item boundary, captures the partial item text, and passes both into the prompt template as [PARTIAL_ITEM] and [COMPLETED_ITEMS]. The model choice matters here: use a model with a context window large enough to hold the original prompt, the partial output, and the completion request without triggering another truncation. For long lists, consider a model with at least a 32K token context window or implement a chunked continuation strategy.

The harness must enforce format consistency between the original output and the completion. Before requesting continuation, capture the list's structural signature: the delimiter style (markdown bullets, numbered items, JSON array elements), the indentation level, the average item length, and any inline formatting conventions. Pass these as explicit constraints in [FORMAT_RULES] within the prompt template. After receiving the completion, run a reassembly validator that: (1) strips any duplicated content at the boundary where the original output ended and the continuation begins, (2) verifies that the completed item and any new items match the captured format signature, (3) checks that the total item count is consistent with any stated list length or expected range, and (4) confirms the final output is parseable as a complete list (valid JSON array, consistent markdown list, etc.). If validation fails, increment a retry counter and re-invoke the prompt with the specific validation error included as [PREVIOUS_ERROR]. Cap retries at 3 attempts before escalating to a human reviewer or logging the partial output for manual repair.

For production observability, instrument the harness with structured logging at each stage: truncation detection (with the finish reason and character position of the cut), prompt assembly (with token counts for the completion request), model invocation (with latency and model identifier), reassembly validation (with pass/fail status and specific rule violations), and final output delivery. Tag each event with a correlation ID that links the original generation, the truncation event, and the repair attempt. This trace data is essential for diagnosing systemic issues—if a particular list type or content domain triggers frequent truncations, you may need to adjust max_tokens upstream, switch to a streaming architecture with chunked assembly, or pre-process inputs to reduce output length. Store the raw truncated output, the completion prompt, and the repaired output in a versioned log for post-mortem analysis and prompt regression testing. Avoid silently delivering repaired outputs without audit trails, especially in customer-facing or compliance-sensitive workflows where list completeness directly impacts user trust or regulatory obligations.