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.
Overview
YAML output makes sense in a narrow band: configuration files, CI pipelines, and outputs a human reviews before committing. The contract mechanics are identical to JSON — schema, example, validation, strictness — with YAML-specific rules taking over: two-space indentation, quoting for special characters, no document separators. This resource loads an event-registration contract in YAML mode to show the engine's format switch in action; if your consumer is code rather than a file, the same schema is one click away from JSON.
Workflow
-
Generate in YAML mode
Same schema engine, YAML serializer — note the format-specific rule block.
-
Check the indentation rule
Two-space indentation is pinned explicitly; indentation drift is YAML's signature failure.
-
Flip formats to compare
Switch the select to JSON and watch the contract re-render — the schema investment is format-portable.
Why This Works
- Format-specific rules address each format's own failure modes — YAML's is indentation, not fences
- One engine across formats means the schema is defined once and rendered anywhere
- Choosing the format by consumer (file vs parser) is the decision the mode select encodes
Best for
- DevOps and CI workflows where YAML is the native tongue
- Outputs destined for files rather than parsers
- Teams that already settled the JSON-vs-YAML question per consumer
Not for
- Code consumers — JSON parses more predictably; switch the format select back
- Deeply nested structures where YAML indentation errors get expensive
Use cases
- Generating config-file entries a human reviews before commit
- Producing pipeline definitions in YAML-native ecosystems
- Switching an existing JSON contract to YAML without redesigning it