Structured Output Schema Generator

Design a JSON Schema for the following data extraction task, then give me working code to use it with [TARGET PROVIDER].

WHAT I'M EXTRACTING: [DESCRIBE THE DATA, e.g. "structured info from a support ticket: category, priority, whether it needs escalation, and a one-sentence summary"]

FIELDS I KNOW I NEED: [LIST ANY SPECIFIC FIELDS, or write "you decide based on the description above"]

CONSTRAINTS:
- Fields that should be enums (fixed set of values) rather than free text: [LIST, or "your judgment"]
- Required vs. optional fields: [SPECIFY, or "your judgment — flag which you'd make optional and why"]

Return:
1. The JSON Schema
2. Working code for [TARGET PROVIDER] using that schema (Pydantic model + `.parse()` for OpenAI, `input_schema` for Claude tool calling, or Gemini's schema-based generation_config, depending on which provider I named)
3. One thing that commonly goes wrong with schemas like this (e.g. a field that should be an enum but tends to get modeled as free text, or a nesting choice that makes parsing harder than it needs to be)

How to use

Use this when you're building a new extraction pipeline and don't want to hand-write the schema from scratch. It's provider-aware: name the API you're actually targeting and you get code that runs, not just an abstract schema.

Variables

• [TARGET PROVIDER] — "OpenAI," "Claude," or "Gemini" (or ask for all three if you're comparing)
• [DESCRIBE THE DATA] — the more specific, the better the field design
• [LIST ANY SPECIFIC FIELDS] — fields you already know you need; leave the rest to the model's judgment
• [LIST, or "your judgment"] — which fields are naturally a fixed set of values

Tips

• Prefer enums over free text wherever the set of valid values is genuinely fixed. "category": "billing" | "bug" | "feature_request" gets filled in far more reliably than an open string field, across every provider.
• Ask for strict: true behavior explicitly if you need a hard guarantee the output matches the schema. OpenAI and Claude both support schema-strict modes; the generated code should use them by default for anything going into a pipeline without a human review step.
• Test the schema on a handful of edge-case inputs (a genuinely ambiguous ticket, missing information, an input close to two categories) before trusting it in production. Schema validity guarantees the shape is right, not that the values are correct.