CSV Field Quote Escaping Repair Prompt

This prompt is for data engineers and pipeline operators who receive model-generated CSV content that is structurally malformed at the field level. The specific job-to-be-done is repairing rows where embedded commas, double quotes, or newline characters inside unquoted or improperly quoted fields have broken the column boundaries, causing downstream parsers to fail or silently corrupt data. The ideal user is someone integrating an LLM into an ETL, reporting, or data export workflow who needs a reliable post-generation repair step that produces RFC 4180-compliant output before the CSV hits a database bulk-insert, a spreadsheet application, or an analytics pipeline.

Use this prompt when the model output is recognizable as CSV but fails validation due to field-level escaping errors—not when the output is entirely unstructured text, JSON, or a different format. The prompt requires the malformed CSV string as [INPUT] and an expected [COLUMN_COUNT] to anchor field boundary repair. It works best when the original intent of the data is preserved but the escaping is broken; it is not a substitute for a CSV generation prompt that should have produced valid output in the first place. Do not use this prompt for repairing delimiter collisions (e.g., tabs vs. commas), encoding issues, or header-row misalignment—those are separate repair workflows. This prompt also assumes the input is a single CSV document, not a streaming chunk or a multi-file archive.

Before wiring this into production, confirm that the failure is truly a quote-escaping problem and not a deeper semantic corruption where field values themselves are garbled. The prompt includes a harness requirement for row-count and column-count validation after repair, and you should pair it with a strict RFC 4180 parser as a post-repair gate. If the CSV contains regulated data (PII, financial records, clinical information), add a human review step before the repaired output is committed to any system of record. For high-throughput pipelines, consider batching malformed rows and applying this prompt only to the subset that fails initial parsing, rather than re-processing every row.

This prompt template is designed to be dropped into a post-generation repair loop. It receives a single malformed CSV row and a header line, and it returns a repaired row that conforms to RFC 4180. Use it when a model has generated CSV content that breaks downstream parsers due to embedded delimiters or quote characters. The prompt is stateless and idempotent—each call repairs exactly one row.

textCopy
You are a precise CSV repair engine. Your only job is to fix a single malformed CSV row so that it conforms to RFC 4180.

## INPUT
- Header row: [HEADER_ROW]
- Malformed data row: [DATA_ROW]
- Delimiter character: [DELIMITER]

## RULES
1. The header row defines the expected number of fields. The repaired data row must have exactly that many fields.
2. If a field contains the delimiter, a double-quote, or a newline, the entire field must be wrapped in double quotes.
3. Any double-quote character inside a field must be escaped by doubling it ("" ).
4. Do not add, remove, or reorder fields. Do not change the delimiter.
5. Do not trim or modify field values except to apply the escaping rules above.
6. If the input row is already valid, return it unchanged.

## OUTPUT
Return ONLY the repaired CSV row as a single line of plain text. No markdown fences, no explanations, no surrounding text.

## EXAMPLE
Header: id,name,description
Input: 1,Smith "Junior", "embedded, comma"
Output: 1,"Smith ""Junior""","embedded, comma"

Adapt the template by replacing the placeholders with values from your application context. [HEADER_ROW] should be the comma-separated (or otherwise delimited) header line that defines the schema. [DATA_ROW] is the single malformed row to repair. [DELIMITER] is typically a comma, but can be a tab, pipe, or semicolon for TSV or other delimited formats. For high-risk data pipelines, always validate the repaired output against the expected field count before ingestion. If the model returns a row with the wrong number of fields, log the failure and escalate for human review rather than silently accepting a corrupted record.

The CSV repair prompt is designed to be a post-processing step in a data ingestion pipeline, not a standalone interactive tool. It should be invoked after a model generates raw CSV content that fails a structural validation check. The typical integration point is inside an ETL worker or an API gateway that receives model output, attempts to parse it with a standard RFC 4180 parser, and on failure, sends the raw string to the repair prompt before retrying ingestion. This keeps the repair logic isolated from the primary generation path and avoids adding latency to successful requests.

Wire the prompt into a repair loop with a hard retry limit. The recommended flow: (1) Receive model output string. (2) Attempt csv.reader parse with strict=True. (3) On csv.Error, capture the raw string and the parser error message. (4) Send both to the repair prompt as [RAW_CSV] and [PARSE_ERROR]. (5) Validate the repaired output by parsing it again. (6) If parsing succeeds, return the repaired CSV; if it fails, retry up to 2 more times with the new error message. (7) If all retries are exhausted, log the original output, all repair attempts, and the final error, then route to a human review queue or dead-letter store. Never silently drop data. For model choice, prefer a model with strong code and format reasoning (e.g., gpt-4o, claude-3.5-sonnet). Set temperature=0 to minimize variation across repair attempts. Include a max_tokens value large enough to hold the entire repaired CSV plus overhead—calculate as len(raw_csv) * 1.5 as a safe floor.

Add validation checks after repair before the data enters any downstream system. At minimum: (a) the output must parse without error using the same strict CSV parser; (b) the number of rows must match the original (unless the prompt was explicitly allowed to drop irrecoverable rows); (c) every row must have the same number of fields as the header row; (d) no field should contain an unescaped double-quote or an unquoted comma or newline. For high-trust pipelines, add a field-count histogram comparison between the original and repaired output to detect silent data loss. Log every repair attempt with the original string, the error that triggered repair, the repaired string, and the validation result. This audit trail is essential for debugging model drift and for compliance in regulated data workflows.

Avoid wiring this prompt into synchronous user-facing flows where latency is critical—repair adds a full model round-trip. Instead, use it asynchronously: queue failed CSV payloads, repair them in a background worker, and notify downstream systems when clean data is available. Also avoid using this prompt on CSV that is structurally valid but semantically wrong (e.g., wrong column order, incorrect data types). That belongs in a separate schema-mismatch repair workflow. Finally, never pass repaired CSV directly into SQL INSERT statements or shell commands without parameterized queries or proper shell escaping—the repair prompt fixes CSV escaping, not SQL injection or command injection risks.