What this prompt does
This prompt makes the model design a prompt that returns valid, schema-conforming JSON on real inputs, with a recovery path for when it doesn't. A single stray sentence around the JSON breaks the downstream parser, so this embeds the schema directly, shows matching examples, and forbids prose or code fences in the output. Embedding the schema and showing a sparse example does more than begging the model to be valid.
The [task] variable is the extraction or generation job, and [schema] is the target JSON schema embedded into the prompt with field types and required fields. [edge_inputs] names the awkward cases — missing fields, multiple items, nulls — that get explicit handling rules so they don't silently produce malformed output. [failure_action] defines what the repair step does on a parse error, for example returning the closest valid JSON with unknown fields set to null. A second, cheap LLM call fixes structure without re-answering the task, so the repair never changes your data.
When to use it
- An LLM feeds JSON into a real parser and an occasional stray sentence breaks it.
- You need the output to match a strict
[schema]every time, including sparse cases. - Handling edge inputs like missing line items or a missing total without crashing.
- Adding an automatic repair step so a parse failure self-corrects instead of erroring out.
- Building a test list of inputs that should each parse cleanly to guard against regressions.
- Defining exactly how malformed output should degrade rather than failing hard.
Example output
You get the full prompt template, then the repair-call prompt, then the test inputs. The main prompt embeds [schema] with types and required flags, includes two example outputs (one sparse), and explicitly instructs JSON-only with no prose or fences. It adds handling rules for the named [edge_inputs] and describes a validation-plus-repair step where a second LLM call applies [failure_action] on parse error. The test list is inputs that should each parse cleanly. It's a complete template plus its repair path and tests, ready to wire into a pipeline.
Pro tips
- Embed
[schema]and show a sparse example — that does far more than begging the model to be valid. - Keep the repair call cheap and narrow: it should fix structure only, never re-answer
[task], or it'll change your data. - Spell out
[edge_inputs]concretely (missing total, no line items, nulls) so the model has explicit rules instead of guessing. - Choose a
[failure_action]that degrades safely, like nulling unknown fields, so downstream code gets predictable shapes. - Forbid code fences explicitly in the output rules, since a wrapping fence is a common reason strict parsers reject otherwise-valid JSON.
- Run the test list after any prompt change; clean-parsing inputs are your regression guard against reintroduced prose or fences.
