CSV Output Prompts
When the destination is a spreadsheet, CSV is the contract: one header row, one data row, quoting rules, and an honest answer about nested data.
View Resource →Structured Output
JSON Output Prompt Builder
Stop parsing prose. Define the task and the schema, and get an output-contract prompt — field definitions, a realistic example response, validation rules, and strictness-controlled output rules. JSON first; YAML, XML, and CSV as modes. Runs entirely in your browser.
What should the model do before returning the data? E.g. "Process the customer details in the input and return them as a structured record."
Schema Fields *
The contract's heart: every field with its type, requirement, and meaning. Reorder with ↑ ↓.
Schema Preview (live example — not the output)
⚠ This schema has array/object fields — CSV flattens them with "; ". For nested data, JSON is the better format.
Output Contract Prompt
Force JSON Output from AI
Stop getting 'Sure, here is the JSON…' — the output-contract pattern that forces models to return only parseable JSON: schema, example, and a strict rule block.
View Resource →JSON Mode Prompt — With and Without Native Support
Native JSON modes guarantee syntax, not your schema. The prompt contract that covers field names, types, and null discipline — whether or not the API has JSON mode.
View Resource →JSON Output for Zapier, Make, and n8n
Automation platforms fail silently on malformed model output. The strict contract that keeps AI steps feeding clean JSON into the rest of the flow.
View Resource →Turn a JSON Schema into a Prompt
You have the schema — fields, types, requirements. The translation into a prompt the model actually follows: schema lines, realistic example, and validation rules.
View Resource →Nested JSON Output — Arrays and Objects
Flat schemas are easy; reliability gets hard at the first nested array. How to contract arrays and objects so the structure survives the model.
View Resource →Stop AI Wrapping JSON in Markdown Fences
```json fences are the most common reason JSON.parse fails on model output. The rule set that prevents them — and why fences happen in the first place.
View Resource →Create Reliable JSON Responses
Getting JSON once is easy; getting the same JSON shape on run 500 is the real problem. The consistency mechanics: stable schema, null discipline, and type pinning.
View Resource →XML Output Prompts
Legacy integrations and enterprise systems still speak XML. The output contract for well-formed, single-root XML responses — same engine, XML rules.
View Resource →YAML Output Prompts
When the consumer is a config file or a human-reviewed pipeline, YAML beats JSON. The same output-contract engine, rendered as a YAML mode.
View Resource →AI Data Extraction Workflow
Turn messy text into structured data you can trust enough to feed another system — bound the source, extract the fields, force clean JSON, and validate before it flows downstream.
View Playbook →AI Reliable JSON Output Workflow
Make any AI task return JSON your code can rely on — define the schema, force the model to it, validate every response, and diff the drift when a model update breaks the shape.
View Playbook →How it works
Describe the task, pick the output format (JSON by default — YAML, XML, and CSV are modes of the same engine), set the strictness level, and build the schema: every field with a name, type, required flag, and description. The schema preview shows a live example of exactly what your prompt will enforce — name-aware sample values included, so an email field previews as user@example.com, not "string". Click Generate JSON Prompt and the builder assembles the full output contract: the task, the schema with field meanings, a realistic example response, validation rules, and strictness-controlled output rules. Nothing leaves your browser.
Use cases
- Getting parseable JSON from chat models that keep adding prose and markdown fences
- Defining the response contract for OpenAI, Claude, or Gemini API calls
- Feeding reliable structured data into Zapier, Make, or n8n automations
- Standardizing one schema across a team so every prompt returns the same shape
Pro tips
- Start with Standard strictness. Switch to Strict only when you see prose or fences leaking through — Strict's nine-rule block costs tokens on every call.
- Field descriptions are not decoration: 'severity — critical, high, medium, or low' constrains the value space. The more a description sounds like validation, the better the output.
- The example response in the prompt is doing heavy lifting — models follow examples more reliably than rules. That's why the builder generates realistic sample values instead of "string".
- Using a model with native JSON mode? Keep the schema and validation sections anyway — native mode guarantees syntax, not your field names, types, or null discipline.
FAQ
How is this different from the Extraction Prompt Generator?
This tool defines the output's structure — the contract any task returns its data in. Extraction is a specific task: pulling fields out of unstructured text. They'll often be used together, but this tool doesn't care what the task is; it cares that the response parses. When the task IS extraction, start with the Extraction Prompt Generator and come back here to tighten the format.
Why is there no separate XML or YAML tool?
Because the format is a serializer, not a product. The contract engine — schema, example, validation rules, strictness — is identical for JSON, YAML, XML, and CSV; only the rendering changes. One tool with format modes beats four tools that are 85% the same.
What exactly does the strictness level change?
The OUTPUT RULES block. Flexible asks politely (two rules). Standard adds the no-fences, no-surrounding-text, null-for-unknown set. Strict adds the full battery: output only valid JSON, no explanations, no commentary, no markdown, no code fences, exactly one object, schema followed exactly, null over invention, no trailing commas.
Do I still need this if my model has a native JSON mode?
Native JSON modes guarantee syntactically valid JSON — they don't guarantee your schema. Field names, types, required-vs-null discipline, and value constraints still come from the prompt. The generated contract works alongside native modes; the strictness rules simply become cheap insurance.
How does it handle nested data — arrays and objects?
Array and object field types render correctly in JSON, YAML, and XML, including in the example response. CSV is flat by nature: the builder warns you, and the contract instructs the model to join multiple values with "; " inside cells. For genuinely nested data, the warning will point you back to JSON.
Why does the example use realistic values like user@example.com?
Models imitate examples more faithfully than they follow rules. An example with "email": "string" teaches the model that placeholder text is acceptable; an example with a realistic value teaches the shape AND the content style. The sample generator is name-aware for exactly this reason.