CSV Repair Prompt After Malformed Output

This prompt is for pipeline operators and data engineers who have received a malformed CSV output from an upstream process, often an LLM generation step, and need to repair it programmatically before ingestion. It is designed for automated recovery loops where a validator has already rejected the initial output. The prompt instructs the model to act as a strict CSV repair engine, fixing delimiter inconsistencies, unbalanced quotes, missing headers, and ragged rows. It returns a repaired CSV body and a repair confidence score so your application can decide whether to ingest, retry, or escalate. Use this when you have a known target dialect and column count, and the damage is structural rather than semantic.

This approach is appropriate when the failure is mechanical—a stray newline inside a quoted field, a row with too many delimiters, or a header that doesn't match the expected column count. You must provide the model with the malformed CSV, the expected column count, and the target dialect (delimiter, quote character, escape rules). The model will attempt to reconstruct a valid CSV without altering the semantic content of the data. Do not use this prompt when the data itself is wrong—if the upstream model hallucinated values or fabricated records, structural repair will not fix those errors. Similarly, avoid this prompt when the malformation is so severe that the original row boundaries are unrecoverable; in those cases, retry the generation step with stricter formatting instructions instead.

Before wiring this into production, define clear thresholds for the repair confidence score. A score of 0.95 might mean auto-ingest, 0.80–0.95 might mean ingest with a warning flag, and below 0.80 might mean quarantine for human review. Always log the original malformed CSV, the repaired output, and the confidence score for auditability. If your pipeline processes regulated data (PII, financial records, clinical data), human review is mandatory for any repair below a confidence of 1.0. The next section provides the exact prompt template you can adapt and deploy.

This template is designed to be wired into a post-generation repair loop. When your initial CSV output fails validation—due to delimiter inconsistencies, unbalanced quotes, missing headers, or ragged rows—this prompt instructs the model to act as a strict repair agent. It receives the original generation instructions, the malformed output, and the specific validator error messages, then produces a corrected CSV. The prompt uses square-bracket placeholders so you can inject dynamic context at runtime without modifying the core instruction.

textCopy
You are a CSV repair agent. Your only job is to fix malformed CSV output so it passes strict validation.

## Original Generation Instructions
[ORIGINAL_PROMPT]

## Malformed CSV Output
```csv
[MALFORMED_CSV]

Validator Errors

[VALIDATOR_ERRORS]

Repair Instructions

1. Analyze the validator errors and identify the root cause of each failure.
2. Produce a corrected CSV that resolves all reported errors.
3. Preserve all original data values unless they are provably malformed (e.g., unescaped quotes inside a quoted field).
4. Maintain the exact column order and header names specified in the original instructions.
5. Use comma as the delimiter and double-quote for field quoting unless the original instructions specify otherwise.
6. Escape internal double-quotes by doubling them.
7. Ensure every row has the same number of columns as the header row.
8. Remove any trailing empty rows.

Output Format

Return ONLY the repaired CSV inside a fenced code block labeled csv. Do not include explanations, apologies, or commentary.

Repair Confidence

After the CSV block, add a single line with the format: REPAIR_CONFIDENCE: <score>/10 where <score> is an integer from 1–10 indicating how confident you are that the repair is complete and correct.

Adaptation notes: Replace [ORIGINAL_PROMPT] with the exact prompt that produced the malformed output—this preserves schema constraints, column definitions, and formatting rules. [MALFORMED_CSV] should contain the raw, broken output exactly as received. [VALIDATOR_ERRORS] should include the specific error messages from your CSV validator (e.g., csv.Error: line 4: expected 8 columns, found 9 or _csv.Error: field larger than field limit). If your validator returns structured error objects, serialize them as clear text. The repair confidence score enables automated retry decisions: if the score is below 7, consider escalating for human review or retrying with a different repair strategy. For high-risk data pipelines, always log the original output, the repair attempt, and the confidence score for auditability.

This prompt is designed as a recovery step within an automated ETL or data generation pipeline, not as a standalone interactive tool. It should be invoked immediately after a primary CSV generation step fails validation. The harness must capture the malformed CSV string, the original target schema or expected dialect, and any specific validation error messages to provide as context. The model's output is a repaired CSV string and a repair confidence score, which the harness uses to decide whether to proceed with ingestion, retry, or quarantine the data.

The implementation should follow a strict sequence: (1) The primary generator produces a CSV string. (2) A validator (e.g., a Python script using the csv module or a schema library like pandera) checks for delimiter consistency, quote balancing, header presence, and row length uniformity. (3) If validation fails, the harness calls the repair prompt, passing the malformed CSV as [MALFORMED_CSV], the expected dialect as [TARGET_DIALECT], and the specific error messages as [VALIDATION_ERRORS]. (4) The harness parses the model's JSON response to extract the repaired_csv string and the repair_confidence score (a float from 0.0 to 1.0). (5) The repaired CSV is re-validated using the same validator. If it passes and the confidence score exceeds a configurable threshold (e.g., 0.85), the pipeline continues. If it fails or the score is too low, the harness can retry the repair prompt once with more explicit instructions or escalate the malformed CSV to a dead-letter queue for human review.

For logging and observability, the harness must record the original validation errors, the repair prompt's input and output, the repair confidence score, and the result of the re-validation step. This trace is critical for diagnosing systemic prompt failures or schema drift. When choosing a model, prefer one with strong code and format manipulation capabilities. Set the temperature to a low value (e.g., 0.1) to maximize deterministic repairs. Avoid using this repair loop for high-risk regulated data without a mandatory human review stage after the repair step, as the model could silently alter data values while fixing the format.