CSV Generation Demonstration Prompt for Tabular Exports

This prompt is designed for data engineers and integration developers who need to generate consistently formatted CSV output from an LLM as part of an automated export pipeline. The job-to-be-done is teaching the model a precise tabular data contract—including header rows, escaping rules, null representations, and multi-line field handling—through structured input-output examples rather than relying on verbose natural-language instructions. Use this prompt when your application must produce CSV that can be immediately parsed by downstream systems like pandas, Excel, or ETL tools without manual cleanup.

The ideal user has a known output schema (column names, types, and constraints) and can provide 2–4 representative examples that demonstrate the desired formatting. Required context includes the target columns, any special characters that must be escaped, the expected representation for null or missing values (e.g., empty string, \N, or NULL), and whether multi-line text fields are permitted. This prompt is not suitable for ad-hoc data exploration where the schema is unknown, for generating CSV with dynamic or user-specified columns on the fly, or for outputs exceeding ~50 rows where token limits and generation latency become prohibitive. For large-scale exports, use this prompt to generate the formatting logic and then implement the actual data transformation in application code.

Before deploying this prompt, you must implement a validation harness that checks column count stability, delimiter consistency, and proper escaping across multiple generated outputs. Common failure modes include the model adding an extra delimiter at the end of rows, using inconsistent quoting for fields containing commas, or silently dropping columns when input data is sparse. Pair this prompt with a post-generation repair step that can detect and fix these structural errors before the CSV reaches downstream consumers. For high-stakes financial or compliance exports, always include a human review gate on the first batch of generated outputs to confirm formatting correctness against the target system's exact CSV dialect.

This prompt template is designed for data engineers building export pipelines that require reliable, machine-parseable CSV output from an LLM. Instead of relying solely on verbose formatting instructions—which models often misinterpret for edge cases like embedded commas, newlines, or null values—this template uses a few-shot demonstration block. The examples explicitly teach the model how to handle header rows, quote escaping, multi-line fields, and null sentinel values. The square-bracket placeholders let you swap in your own input data, output schema, constraints, and risk level without rewriting the core instruction.

textCopy
You are a data export assistant. Your task is to convert the provided [INPUT] into a valid CSV string following the rules demonstrated in the examples below.

## Output Schema
[OUTPUT_SCHEMA]

## Constraints
[CONSTRAINTS]

## Formatting Rules (learned from examples)
- Use a header row that exactly matches the column names in the output schema.
- Enclose any field containing a comma, double quote, or newline in double quotes.
- Escape internal double quotes by doubling them ("" becomes """").
- Represent null or missing values as [NULL_SENTINEL].
- Use [DELIMITER] as the field delimiter.
- End each row with a newline character (\n), including the last row.

## Examples

### Example 1
Input: {"name": "Acme Corp", "revenue": 1250000, "ceo": "Jane Doe", "notes": "Leading supplier"}
Output:
name,revenue,ceo,notes
Acme Corp,1250000,Jane Doe,Leading supplier

### Example 2
Input: {"name": "Smith & Sons, LLC", "revenue": null, "ceo": "John \"Johnny\" Smith", "notes": "Family business\nEst. 1985"}
Output:
name,revenue,ceo,notes
"Smith & Sons, LLC",\N,"John ""Johnny"" Smith","Family business
Est. 1985"

### Example 3
Input: {"name": "DataPipe Inc.", "revenue": 0, "ceo": null, "notes": ""}
Output:
name,revenue,ceo,notes
DataPipe Inc.,0,\N,

## Input to Convert
[INPUT]

## Output

Adaptation guidance: Replace [INPUT] with your raw data (JSON, text, or a structured record). Define [OUTPUT_SCHEMA] as a comma-separated list of column names in the exact order you need. Set [NULL_SENTINEL] to your preferred null representation (e.g., \N, NULL, or an empty string). Set [DELIMITER] to , for standard CSV or | for pipe-delimited formats. The [CONSTRAINTS] placeholder can hold additional rules like date formatting (YYYY-MM-DD), numeric precision, or character encoding limits. If your input contains sensitive data, add a constraint requiring redaction or flag the [RISK_LEVEL] as high and route the output through a human review step before ingestion into downstream systems. For production use, always validate the generated CSV against the expected column count and delimiter consistency before accepting the output.

The CSV generation prompt is designed to be called from an application layer that handles input preparation, output validation, and error recovery. The prompt itself is stateless—it receives structured input and returns a CSV string. The surrounding harness is responsible for ensuring the output is machine-readable, schema-compliant, and safe to write to a file or stream to a downstream consumer. This separation keeps the prompt focused on formatting and escaping rules while the application owns correctness guarantees.

Input preparation starts by assembling the [INPUT] placeholder with a JSON array of objects, each representing a row. The application should validate that all objects share the same keys before passing them to the model. If the input contains nulls, empty strings, or values with embedded commas, quotes, or newlines, the prompt's examples teach the model how to handle them—but the harness should still log any input anomalies for debugging. Model selection matters: prefer models with strong instruction-following and structured output capabilities (e.g., GPT-4o, Claude 3.5 Sonnet). Smaller or older models may drop columns, mangle escaping, or hallucinate rows. Set temperature=0 to maximize determinism. Output validation is the critical step. After receiving the model response, strip any markdown fences or surrounding text, then parse the CSV with a robust library (Python's csv module, not manual splitting). Validate that: (1) the header row contains exactly the expected columns in the correct order, (2) every data row has the same number of fields as the header, (3) quoted fields are properly escaped and closed, and (4) the delimiter is consistent throughout (no accidental tab or semicolon substitution). If validation fails, log the failure with the raw model output and the specific validation error.

Retry logic should be bounded. On the first validation failure, re-send the same prompt with the model's previous output appended as a negative example inside [EXAMPLES], along with a brief instruction like 'The previous output failed CSV validation because [specific error]. Generate a corrected CSV.' If the second attempt also fails, do not retry further—escalate to a human reviewer or fall back to a programmatic CSV builder using the original JSON input. Logging and observability are essential: record the prompt version, input row count, output byte size, validation pass/fail, retry count, and latency for every call. This data feeds into eval dashboards that track column count stability, delimiter consistency, and escape correctness over time. When to avoid this prompt entirely: if your input is already a clean array of flat objects with no escaping edge cases, generate the CSV programmatically—it's faster, cheaper, and guaranteed correct. Use this prompt only when the input contains unstructured or semi-structured text fields that require judgment about escaping, multi-line handling, or null representation. For high-throughput pipelines, consider caching common input patterns or using the prompt to generate a reference implementation that your code can replicate without model calls.