Structured Output prompts

Help me get reliable JSON output.

THE STRUCTURE I NEED: [DESCRIBE IT, OR PASTE THE SCHEMA]
MY CURRENT PROMPT:
"""
[PASTE, or 'none yet']
"""
WHAT GOES WRONG: [invalid JSON / missing fields / wrong types / extra text around it / inconsistent]
MODEL: [WHICH]
VOLUME: [HOW MANY CALLS]
LANGUAGE FOR THE PARSING CODE: [WHICH]

Produce:

1. THE PLATFORM FEATURE FIRST - does my model support structured outputs, JSON mode, or tool calling with a schema? If so, that is the answer and prompt wording is a distant second, because constrained decoding guarantees valid structure in a way no instruction can. Show how to use it for my model. Only continue if it is unavailable.

2. THE SCHEMA REVIEW - schemas that models handle reliably and ones they do not. Flag in mine: deep nesting, optional fields with unclear conditions, unions or polymorphic types, free-form maps with arbitrary keys, and very long enumerations. Propose a flatter alternative where the schema is fragile.

3. THE PROMPT - with:
   - The schema stated precisely, with types
   - One complete example of valid output
   - An explicit statement that the response must contain the JSON and nothing else: no explanation, no markdown fences, no preamble
   - What to emit when a value cannot be determined: null, a sentinel, or an error object. Decide and state it, because an undefined answer produces a different improvisation each time.

4. THE FIELD DESCRIPTIONS - each field with what it should contain and its constraints. A schema with bare type names produces technically valid output with wrong content.

5. THE PARSING CODE - defensive, in my language:
   - Strip markdown code fences before parsing
   - Extract the outermost JSON object if there is surrounding text
   - Validate against the schema rather than only parsing
   - Handle missing and unexpected fields explicitly
   - Log the raw output on failure, since a parse error cannot be diagnosed without it

6. THE RETRY STRATEGY - on invalid output, retry including the validation error in the follow-up. Cap the attempts and define what happens when they are exhausted.

7. THE VALID-BUT-WRONG PROBLEM - schema validation passes and the content is incorrect. Say what business-level checks should run on my structure: value ranges, required combinations, and internal consistency.

8. THE VOLUME MATH - at my stated volume, the expected failure rate and what the retry cost amounts to.

9. THE SIMPLER FORMAT QUESTION - if the structure is simple, a delimited format can be more reliable than JSON and easier to repair. Say whether that applies here.

10. THE TEST CASES - inputs likely to produce malformed output: empty input, input containing JSON, input containing quotes and special characters, and input where several fields are indeterminable.

Help me design a schema for model output.

WHAT I NEED THE DATA FOR: [THE DOWNSTREAM USE]
WHAT THE MODEL IS EXTRACTING OR PRODUCING: [THE TASK]
MY DRAFT SCHEMA:
"""
[PASTE, or describe the fields you want]
"""
THE INPUT IT WORKS FROM: [WHAT THE MODEL RECEIVES]

Produce:

1. THE FRAGILITY REVIEW of my draft - the structural features that models handle badly:
   - Deep nesting beyond two or three levels
   - Optional fields where the condition for inclusion is unclear
   - Unions and polymorphic types, where the model must choose a shape
   - Free-form maps with model-chosen keys, which are inconsistent between calls
   - Very long enumerations
   - Fields whose correct value depends on another field's value
   - Arrays of objects with many fields each, where consistency across elements degrades

2. THE FLATTER ALTERNATIVE - where nesting can be removed without losing information. Flat structures are filled far more reliably and are easier to validate.

3. THE FIELD NAMING - names that describe what goes in them. A field called 'type' or 'value' invites inconsistency; a field called 'document_category' does not. Rename anything ambiguous in mine.

4. THE ENUM DECISION - where a field should be constrained to a fixed set rather than free text. This is the single most effective schema change for consistency. Identify the fields in mine that should be enums and propose the values.

5. THE ABSENT VALUE DESIGN - every field needs a defined behaviour when the value cannot be determined. Decide for each: null, an explicit 'not stated' value, or omission. Being explicit prevents the model inventing a plausible value, which is the most damaging failure in extraction.

6. THE INFERENCE SEPARATION - if the model may need to infer rather than extract, that belongs in its own field or with a confidence marker. Inferences and extractions mixed in one field are indistinguishable afterwards, and that distinction is usually the one that matters.

7. THE ONE-THING-PER-FIELD RULE - fields that combine two pieces of information get filled inconsistently. Split them.

8. THE VALIDATION RULES - what can be checked programmatically once the output arrives: required fields present, values in range, enum membership, internal consistency between related fields.

9. THE REVISED SCHEMA - with field descriptions included, because those are instructions to the model as much as documentation.

10. THE SPLIT QUESTION - whether this is one schema or should be two calls producing two simpler structures. A complex schema filled unreliably is worse than two simple ones filled well.

11. THE DOWNSTREAM CHECK - against my stated use, whether the schema actually provides what is needed and nothing more. Fields that are collected and never used add failure surface for no benefit.

Help me extract structured data reliably.

WHAT I AM EXTRACTING FROM: [THE INPUT TYPE - emails, documents, forms, notes, transcripts]
A SAMPLE INPUT:
"""
[PASTE ONE]
"""
A SECOND, DIFFERENT ONE:
"""
[PASTE ONE THAT VARIES]
"""
WHAT I NEED OUT: [THE FIELDS]
WHERE IT GOES: [DESTINATION SYSTEM]
VOLUME: [HOW MANY]

Produce:

1. THE VARIATION ANALYSIS - from my two samples, what differs and what stays constant. Extraction reliability depends almost entirely on how much the input varies, and identifying the variation is what makes the rules work.

2. THE FIELD SPECIFICATION - for each field: what it is, where it typically appears, what forms it takes across my samples, and what to do when it is absent.

3. THE EXTRACTION RULES - precise enough to apply identically every time. For each field: how to identify it, and what to do when it appears differently from the samples.

4. THE AMBIGUITY RULES - decided in advance, because inconsistent handling across a batch is worse than a consistent imperfect choice. For each likely ambiguity, the rule: which date when several appear, which total when there is a subtotal, how to handle a value split across lines, which name when several are mentioned.

5. THE EXTRACT-DO-NOT-INFER INSTRUCTION - the most important rule. Extract only what is stated. Anything inferred goes in a separate field marked as such, or is omitted. Without this, extracted data contains plausible inventions indistinguishable from facts.

6. THE VERBATIM RULE - preserve the original wording, numbers and units. Do not normalise, convert, round or reformat unless explicitly instructed, because normalisation loses information and introduces errors.

7. THE SOURCE QUOTE FIELD - for any field where accuracy matters, including the phrase it was extracted from. This makes verification possible without rereading the source and is the single most useful addition to an extraction schema.

8. THE PROMPT - written, with the rules embedded so every input is processed identically.

9. THE CONFIDENCE AND FLAGS - a field for extraction notes: ambiguous, conflicting values found, inferred, or partially stated. These flags route items to human review rather than letting uncertain data through silently.

10. THE VALIDATION - checks to run on each record: required fields present, formats correct, values plausible, internal consistency.

11. THE EXCEPTION HANDLING - what happens to an input that does not fit the pattern. Flag it for review rather than forcing a fit. Say what proportion of exceptions is normal and when a high rate means the rules are wrong.

12. THE QUALITY SAMPLE - at my volume, how many records to check manually against the source, and which to prioritise: exceptions, extremes, and a random sample.

Help me get consistent formatting in text output.

WHAT THE OUTPUT IS: [THE CONTENT TYPE]
THE FORMAT I WANT: [DESCRIBE IT]
MY PROMPT:
"""
[PASTE]
"""
WHAT VARIES BETWEEN RUNS: [THE INCONSISTENCY]
WHERE THE OUTPUT GOES: [a document / a webpage / an email / pasted somewhere]

Produce:

1. THE SPECIFICATION - the format written as a template rather than described. Showing the shape is more effective than describing it, and it removes the ambiguity that produces drift.

2. THE SECTION DEFINITION - each section with: its heading exactly as it should appear, what goes in it, and its length budget. Vague section descriptions produce sections of wildly varying length between runs.

3. THE HEADING CONSISTENCY - if headings vary between runs, the fix is to state them literally rather than describing what each section should cover. Give the exact headings.

4. THE LENGTH CONTROL - per section rather than overall, because a total word count gets distributed unpredictably. State each section's budget.

5. THE PREAMBLE AND POSTAMBLE - models add an introduction restating the task and a summary at the end. If the output is going straight into a document, both are noise. The instruction: the response must begin with the first section and end with the last, containing nothing else.

6. THE MARKDOWN QUESTION - whether the destination renders markdown. If the output is pasted into something that does not, asterisks and hashes appear literally. Say what to specify for my destination.

7. THE LIST AND EMPHASIS RULES - models default to heavy use of bullet points and bold text. If that does not suit the destination, it must be stated explicitly, because it is a strong default.

8. THE EXAMPLE - one short example of correctly formatted output. For format, an example does more than any amount of description.

9. THE DRIFT PROBLEM - format consistency degrades over long outputs, and later sections follow the specification less closely than earlier ones. What helps: numbered sections, explicit markers, and shorter outputs.

10. THE REWRITTEN PROMPT.

11. THE POST-PROCESSING QUESTION - some formatting is more reliably fixed after the fact than specified in the prompt. If my requirement is mechanical, say whether a find-and-replace or a script is the better answer than another instruction.

Help me produce output that fits its destination.

WHAT I AM GENERATING: [THE CONTENT]
WHERE IT GOES: [a CMS field / a spreadsheet cell / a template / an API / a specific form / code]
THE CONSTRAINTS OF THAT DESTINATION: [character limits, allowed characters, format, required fields]
MY PROMPT:
"""
[PASTE]
"""
WHAT BREAKS: [THE PROBLEM]

Produce:

1. THE DESTINATION REQUIREMENTS - everything the output must satisfy, listed. Character limits, allowed characters, escaping rules, line break handling, required and forbidden elements, and encoding. Most destination failures come from a requirement nobody stated in the prompt.

2. THE CHARACTER LIMIT PROBLEM - models approximate length rather than counting, so a hard limit cannot be guaranteed by instruction. The reliable approach: ask for output comfortably under the limit, then validate and truncate or regenerate. Say what margin to leave.

3. THE SPECIAL CHARACTERS - what breaks at my destination: quotes, apostrophes, ampersands, angle brackets, newlines, emoji, non-ASCII characters. Say what to instruct and what to handle in code afterwards.

4. THE ESCAPING QUESTION - whether escaping should happen in the prompt or afterwards. Almost always afterwards: asking a model to produce pre-escaped output produces inconsistent escaping. Generate clean text and escape it programmatically.

5. THE STRUCTURE REQUIREMENTS - if the destination expects specific fields or a template, how to specify them so the output maps directly without manual rearrangement.

6. THE SEPARATOR PROBLEM - if the output is split into fields, the separator must not appear in the content. Say what to use and what to do when it does appear.

7. THE PROMPT - rewritten with the destination constraints stated explicitly. The model cannot satisfy a requirement it was not given, and this is the most common cause of output that does not fit.

8. THE VALIDATION - what to check before the output is used: length, allowed characters, required elements present, structure correct. This belongs in code rather than in trust.

9. THE FAILURE HANDLING - what to do when the output fails validation: truncate, regenerate with the error included, or flag for review. Say which suits each failure type.

10. THE BATCH CONSIDERATION - if generating many, the consistency requirements and what to check across the set rather than per item.

11. THE DESTINATION TEST - putting one output through the real destination before generating a batch. Constraints discovered after generating five hundred items are expensive.

Help me generate a batch of items.

WHAT I AM GENERATING: [THE ITEMS]
HOW MANY: [COUNT]
WHAT EACH ITEM CONTAINS: [THE STRUCTURE]
WHAT VARIES AND WHAT STAYS CONSTANT: [DESCRIBE]
WHERE THEY GO: [DESTINATION]
WHAT GOES WRONG: [inconsistent structure / quality drops / repetition / drift]

Produce:

1. THE BATCH SIZE DECISION - generating many items in one response causes quality and consistency to degrade toward the end, as the model settles into a pattern and stops varying. Smaller batches with a consistent prompt produce better results than one large request. Say what batch size suits my item type.

2. THE DRIFT PROBLEM - in a long generated list, later items become shorter, more formulaic, and more similar to each other. This is the most common batch failure. What helps: smaller batches, explicit per-item structure, and a stated requirement that items must differ.

3. THE REPETITION PROBLEM - items in a batch converge on similar phrasing and similar content. The fix: state the dimensions along which items must vary, and include the already-generated items in subsequent requests so they can be avoided.

4. THE PER-ITEM TEMPLATE - each item's structure specified exactly, with the fields and their length budgets. A template applied per item holds much better than a description applied to the batch.

5. THE ONE-AT-A-TIME OPTION - generating individually, passing the previous items as context to avoid duplication. Slower and more expensive, and substantially more consistent. Say whether my count and quality requirement justify it.

6. THE VARIATION SPECIFICATION - what should differ between items and what should not. Without this, the model varies the wrong things: it changes the structure while repeating the content.

7. THE PROMPT - written, with the template and variation requirements.

8. THE VALIDATION - checks across the batch: structural consistency, no duplicates, all required fields present, length within bounds, and coverage of the stated variation dimensions.

9. THE DUPLICATE CHECK - how to detect near-duplicates, which are more common than exact ones and less visible.

10. THE QUALITY SAMPLE - which items to check manually: the first, the last, and a random middle one. The last items are where quality degradation shows.

11. THE TOP-UP APPROACH - generating slightly more than needed and discarding the weakest, which is usually cheaper than trying to make every item good.

Help me validate this output before I use it.

WHAT THE MODEL PRODUCES: [THE OUTPUT TYPE AND STRUCTURE]
WHAT IT FEEDS INTO: [THE DOWNSTREAM USE]
WHAT HAPPENS IF IT IS WRONG: [consequence]
VOLUME: [HOW MANY]
CURRENT CHECKING: [WHAT YOU DO NOW, if anything]
LANGUAGE: [FOR VALIDATION CODE]

Produce:

1. THE VALIDATION LAYERS - each catching different failures, and all worth having:
   - STRUCTURAL: is it parseable and does it match the schema
   - TYPE: are values the right types and formats
   - RANGE: are values plausible - dates in range, numbers positive where required, lengths within bounds
   - COMPLETENESS: are required fields present and non-empty
   - CONSISTENCY: do related fields agree with each other
   - CONTENT: is it actually correct, which code usually cannot check
   Say which matter most for my output.

2. THE VALID-BUT-WRONG PROBLEM - the important distinction. Schema validation confirms shape and says nothing about correctness. Output can be perfectly formed and entirely wrong, and this is the failure that reaches production.

3. THE BUSINESS RULES - the checks specific to my data that catch wrong content: relationships between fields, values that cannot co-occur, totals that must reconcile, and anything with a known valid range. These are where content errors are actually caught.

4. THE VALIDATION CODE - written in my language, with clear error messages saying which check failed and on what value.

5. THE FAILURE HANDLING - per failure type: retry, retry with the error included in the prompt, fall back to a default, flag for human review, or reject. Say which for each, because retrying a content error usually produces the same content error.

6. THE LOGGING - the raw output must be kept when validation fails. A failure that cannot be reproduced cannot be diagnosed, and this is the most commonly missing piece.

7. THE HUMAN REVIEW ROUTING - given my volume and the consequence of an error, what proportion needs a person to look at it and which items to prioritise: validation failures, flagged uncertainty, extremes, and a random sample.

8. THE SAMPLING PLAN - if checking everything is impractical at my volume, a sampling approach that would detect a systematic problem.

9. THE MONITORING - what to track over time: validation failure rate, which checks fail most, and any change in either. A rising failure rate is the first sign that something upstream changed.

10. THE PROPORTIONATE ANSWER - given the consequence I described, how much validation is warranted. For low-stakes output, structural validation is enough; for anything consequential it is not.

11. WHAT CODE CANNOT CHECK - the failures only a person will catch, so I know what the validation does not cover.