Escape Character Doubling Repair Prompt

This prompt is for integration engineers and platform developers who receive model outputs through serialization pipelines where escape sequences have been inadvertently doubled. The classic symptom is seeing \\n instead of \n, or \\" instead of \", after a model's raw output has passed through a logging framework, message queue, or API gateway that applies an extra layer of string escaping. The job-to-be-done is not to fix the pipeline itself—that is an infrastructure task—but to repair the already-corrupted payload so downstream parsers, databases, and user-facing surfaces receive correctly single-escaped text.

Use this prompt when you have confirmed that the corruption is specifically doubling of backslash-escape sequences, not missing escapes, encoding mismatches, or structural JSON breakage. The ideal user has already inspected the raw bytes and verified that \n appears as a literal backslash followed by n rather than as a newline control character. Do not use this prompt when the output contains unescaped control characters that need escaping added, when the payload is structurally invalid JSON requiring schema repair, or when the corruption involves Unicode escape sequence normalization (\u0041 vs A). Those failures belong to sibling playbooks in the Encoding, Whitespace, and Escape Character Sanitization group.

The prompt requires the corrupted string as its primary input, along with an explicit list of escape sequences to repair (typically \n, \t, \r, \", \\). You must also supply a constraint describing which literal backslashes to preserve—for example, Windows file paths like C:\\Users or regex patterns like \\d should not be collapsed. Before wiring this into an application, build a validation harness that checks the output against a set of known input-output pairs, including edge cases where a literal double-backslash is intentional. If the repaired output feeds into a security-sensitive parser, a SQL query builder, or a user-facing display, add a human review step or a secondary validation pass to confirm no over-correction occurred.

This prompt template is designed to be dropped into a post-processing pipeline where model outputs arrive with escape sequences that have been doubled by intermediate serialization (e.g., \\n instead of \n, \\" instead of \"). The template instructs the model to act as a precise repair function, collapsing double escapes back to single escapes while preserving intentional literal backslashes that the user actually wanted in the output. The placeholder structure lets you inject the corrupted string, specify which escape sequences to repair, and define the expected output format.

textCopy
You are an escape character repair function. Your only job is to fix double-escaped sequences in the provided text.

## INPUT
[INPUT]

## TARGET ESCAPE SEQUENCES
Repair only these escape sequences:
[TARGET_ESCAPES]

## REPAIR RULES
1. Replace every occurrence of a double-escaped sequence (e.g., `\\n`, `\\t`, `\\"`, `\\\\`) with its single-escaped equivalent (`\n`, `\t`, `\"`, `\\`).
2. Do NOT unescape sequences that are already single-escaped. A single backslash followed by a valid escape character is correct and must be left alone.
3. A literal backslash that the user intended to keep (e.g., a Windows file path like `C:\\Users`) will appear as `\\\\` after double-escaping. Repair it to `\\`, not to nothing.
4. Do not modify any other part of the text. Preserve all whitespace, line endings, and non-target characters exactly.
5. If the input contains no double-escaped sequences, return the input unchanged.

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT FORMAT
Return ONLY the repaired text. No explanations, no markdown fences, no commentary.

## EXAMPLES
[EXAMPLES]

To adapt this template, populate [TARGET_ESCAPES] with the specific sequences your pipeline corrupts—commonly \n, \t, \", \\, \r. If your system also mangles Unicode escapes (\\u0041), add them explicitly. The [CONSTRAINTS] placeholder can hold additional rules like 'preserve JSON structure' or 'do not touch content inside code blocks.' Use [EXAMPLES] to provide before/after pairs that demonstrate edge cases, especially the critical distinction between a double-escaped literal backslash (\\\\ → \\) and a double-escaped control character (\\n → \n). If the input is JSON, consider wrapping this prompt inside a harness that first validates structural integrity before attempting escape repair, since a structurally broken payload may need a different recovery path. For high-risk pipelines where data loss is unacceptable, always log the original corrupted string alongside the repaired output and implement a diff-based review step before the repaired text enters downstream systems.

The escape character doubling repair prompt is designed to sit in a post-processing pipeline, after the model generates output but before that output reaches a downstream parser, database, or API. The most common integration point is inside a serialization or logging layer where double-escaped sequences like \\n or \\t break JSON parsers, log formatters, or string comparison logic. Wire this prompt as a stateless transformation function that accepts a raw string and returns a repaired string. It should be called synchronously before any step that would reject or mangle the malformed output.

In practice, implement this as a dedicated repair step with a narrow contract. The function should accept a single [INPUT] string and return a repaired string. Before calling the model, validate that the input actually contains doubled escape sequences—if it doesn't, skip the repair to avoid unnecessary latency and cost. After receiving the model's output, run a validation check that confirms the output contains no remaining doubled backslash-escape patterns (e.g., \\\\ should reduce to \\ for a literal backslash, but \\n should become \n). For high-stakes pipelines, add a round-trip test: serialize and deserialize the repaired output through your target parser to confirm it survives without corruption. Log every repair attempt with the original and repaired strings, the model used, and whether validation passed. If validation fails, implement a retry loop with a maximum of 2 attempts, each time passing the previous failed output and the validation error back to the model as additional context. After 2 failures, escalate to a human-reviewed dead-letter queue rather than silently passing broken output downstream.

Model choice matters here. This is a deterministic, rule-adjacent task, so prefer fast, cheap models (e.g., GPT-4o-mini, Claude Haiku) over large reasoning models. The prompt does not require deep semantic understanding—it needs precise pattern matching and replacement. Set temperature=0 to maximize consistency. If your pipeline processes high volumes, consider batching multiple strings into a single prompt call with clear delimiters, but validate each repaired segment independently. Avoid using this prompt on binary data or non-string payloads. The biggest production risk is over-correction: the model might unescape intentional literal backslashes that should remain doubled. Mitigate this by including explicit examples of literal backslash preservation in your few-shot examples and by running the validation check described above. If your downstream system requires a specific escaping scheme (e.g., JSON string encoding, SQL literal escaping), chain this repair prompt with a subsequent normalization prompt rather than asking one prompt to handle both repair and re-escaping.