What this prompt does
This prompt designs a prompt that reliably produces structured output — JSON, XML, or YAML — for a given task, with the edge-case handling and retry logic that make machine-parseable output dependable. It defines the exact schema with required and optional fields and types, embeds that schema in the way [target_model] understands best, adds explicit rules for nulls, arrays, and nested objects, includes a complete example, and bakes in validation instructions. It also designs a retry prompt for malformed output and a consuming-side function that parses with real error handling.
The variables fit the schema to your pipeline. [output_format] picks JSON, XML, or YAML, and [task] defines what is being extracted or generated. [target_model] matters because models differ in how they best receive schemas — some use native tool-calling for structured output. [edge_cases] names the messy realities like missing data and multilingual content, [parsing_method] (such as Zod validation in TypeScript) sets how the consumer validates, [test_inputs] defines what to test against, and [language] produces the parsing function. The result treats schema design and retry logic as first-class, not an afterthought.
When to use it
- An agent step depends on parseable output and stray explanatory text keeps breaking your parser.
- You need a strict schema with typed, required fields that the model honors consistently.
- Extraction tasks hit messy inputs — missing data, ambiguous values, multilingual content — and need defined edge-case rules.
- You want a retry path for when the model returns malformed
[output_format]. - Pairing the prompt with a real validator like
[parsing_method]on the consuming side. - Building a
[language]integration that calls the model and parses the response safely.
Example output
Expect the full schema definition with field types and required markers, a prompt that embeds it the way [target_model] prefers, explicit instructions for [edge_cases], and a complete sample of the expected output. You also get validation instructions, a retry prompt for malformed responses, guidance for when the model wants to add prose outside the structure, and a [language] function that calls the API and parses with error handling tuned for [parsing_method].
Pro tips
- Prefer native structured-output features where
[target_model]offers them — tool-calling or constrained decoding is far more reliable than asking for JSON in free text. - Always pair the prompt with a real validator on the consuming side;
[parsing_method]like Zod is what turns "usually valid" into "provably valid." - Spell out
[edge_cases]explicitly — define what a missing field becomes (null versus omitted) so the schema does not silently shift shape. - Keep the retry prompt narrow: feed back the validation error and ask only for a corrected response, rather than re-running the whole task.
- Test against varied
[test_inputs]; output that parses on a clean input often breaks on a sparse or multilingual one. - Handle the model's urge to add commentary — an explicit "output only the structure" rule prevents prose from contaminating the parse.
