JSON Extraction Prompt
Extract structured data from messy text with a schema designed against the real failure modes: filled-in blanks, deep nesting, and inferred values.
Extract structured data from the document below.
Extract exactly this JSON structure:
{
"[field]": "string. [WHAT IT IS + FORMAT + EXAMPLE, e.g. 'invoice number as printed, e.g. INV-2024-0031']",
"[date_field]": "string (YYYY-MM-DD) or null. [WHICH date this is; null if not stated]",
"[enum_field]": "one of: [\"option_a\", \"option_b\", \"unknown\"]. [WHEN EACH APPLIES; use \"unknown\" when the document doesn't say]",
"[amount_field]": "number or null. [UNIT AND SIGN CONVENTION, e.g. 'total in USD, negative for credits']",
"[items]": [
{
"evidence": "string, the EXACT sentence or cell from the document this item comes from, quoted verbatim",
"[item_field]": "string. [WHAT]"
}
]
}
Extraction rules:
- Extract, don't infer: a value must be stated in the document, not deduced from vibes. If the document says "due in 30 days" and no invoice date exists, due_date is null, not today plus 30.
- Empty is a valid answer: return [] for lists with no items and null for absent fields. Never invent an entry to fill an array.
- The evidence field comes FIRST in each item and must be a verbatim quote. If you can't quote it, the item doesn't exist.
- Normalize formats exactly as the schema states (dates to YYYY-MM-DD, amounts to plain numbers without currency symbols); do not normalize anything else.
- Ambiguity: if two document values could fill one field, pick the more specific and append the alternative to an "extraction_notes" array at the root.
- Output raw JSON only, no markdown fences, no commentary.
Document:
"""
[PASTE THE TEXT / EMAIL / INVOICE / TRANSCRIPT]
"""How to use
Schema design carries this prompt: keep nesting shallow (failure rates climb past 3 levels), give every enum an 'unknown' escape hatch, and put field descriptions on everything. They are prompt text, not decoration. The evidence-before-value ordering is the anti-hallucination lever: quoting first forces grounding. On an API, move this same schema into native structured outputs (OpenAI) or a tool schema (Anthropic): prose JSON requests guarantee syntax at best, not schema. Validate semantics (ranges, cross-field rules) in code afterward.
More agent prompts
You are a software engineering agent working in the [PRODUCT/TEAM] codebase ([LANGUAGE/STACK]). Your objective is to take an assigned task from description to verified, working code. You may read and modify anything in the repository; you do not push, merge, deploy, or alter CI configuration unless the task explicitly says to. # Operatin
Coding Agent System Prompt
Autonomous coding agent that matches repo conventions, proves work with passing tests before claiming done, and reports failures truthfully.
You are a debugging agent for the [PRODUCT] codebase. Your objective is to find the root cause of a reported bug, fix it with the smallest possible change, and prove the fix. You are not here to refactor, harden, or improve unrelated code: a debugging session that ends in a 40-file diff has failed even if the bug is gone. # Reproduce Bef
Debugging Agent System Prompt
Root-cause-first debugging agent: no fix until the bug is reproduced, minimal diffs only, and done means the repro dies while the test suite stays green.
You are a code migration agent. Your objective is to move the [PRODUCT] codebase from [SOURCE VERSION/FRAMEWORK] to [TARGET VERSION/FRAMEWORK] while preserving behavior exactly. You are a mechanical translator with judgment, not a redesigner: the product must work the same after every step you take. # The Prime Rule: Migration Changes On
Code Migration Agent System Prompt
Framework-upgrade agent that migrates in build-green slices, verifies every codemod, follows official guides over memory, and never mixes in behavior changes.