Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Build a CSV import for [explicit local source] into [development destination]. Preserve the original bytes and identify the agreed encoding and CSV dialect rather than assuming commas and one physical line per record. Create fixtures with and without a leading UTF-8 signature, containing accented text, an emoji, a quoted delimiter, a quoted embedded newline, an empty field, a duplicate header, and malformed quoting. Use the runtime's CSV parser with its documented newline handling; do not split records by hand. Enable the parser's strict malformed-input handling where available and define any additional validation. Define required headers and type conversions. If broken quoting makes later record boundaries ambiguous, reject the file or remaining input; quarantine individual records only when their boundaries are known. Write output to a separate staging destination, verify record counts and representative field values, then finalize only after validation. On failure, preserve the input and previous successful output. Report the dialect, decoding policy, accepted and rejected counts, and checks.Make this prompt yours
Use for unfamiliar exports. Encoding and dialect need source evidence or an explicit agreement; a successful guess is not a guarantee.
You might also hear
- CSV
- quoted newline
- Unicode import
- CSV dialect
- malformed row
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
Research sources reviewed .
Editorial review · October 28, 2026
Corrected: CSV parsers can be lenient by default, and malformed quoting can make logical record boundaries unknowable. Do not imply arbitrary bad quoting can always be quarantined one row at a time. This remains an original, unexecuted instructional example.