Practice — Prompt Engineering & Structured Output

A team builds a Claude-powered contract-review assistant. The system prompt says: "You are a meticulous contract reviewer for Acme Corp; flag any clause that deviates from Acme's standard terms." The user prompt for each request contains the specific contract text and the specific policy version to check against.

An engineer sets the system prompt to: "You are a summarizer. Summarize the following email into 3 bullet points, in a formal tone, no more than 50 words, addressed to a VP audience." Each API call then carries only the raw email text as the user prompt. The team now wants to reuse the same assistant for a different request that needs 5 bullets in a casual tone.

A customer support bot's system prompt says: "You are a support agent for Acme Cloud. Always be polite, never promise refunds without a policy lookup, and respond in the customer's language." Each user turn carries only the customer's current message and conversation history.

A team wants Claude to classify support tickets into one of five categories, and to handle an easy-to-miss edge case (tickets that are actually spam) consistently. Describing the edge case in prose alone has produced inconsistent results.

A developer, trying to nail a tricky output format, adds 15 few-shot examples to every prompt call.

A data-extraction schema has a phone field. The team wants missing phone numbers represented as null, not an empty string or "N/A", and prose instructions describing this have been followed inconsistently.

A team is deciding whether to wrap a prompt's instructions, examples, and input document in tags.

A prompt for a legal document analyzer includes general reviewing instructions, three example analyses, a 40-page contract, and specific questions about that contract — all concatenated as one plain paragraph with no separators.

A team currently asks Claude to answer with a paragraph of prose describing extracted fields, then writes a regex-based parser to pull the fields back out of that prose.

Two engineers debate how to get reliable JSON out of Claude for a downstream system integration. Engineer A says: "Just tell it in the prompt — respond only with valid JSON matching this schema." Engineer B says: "Force a tool call whose input schema is the desired output shape."

A schema field is defined simply as a string type with no further description, and the model has been returning dates in several inconsistent formats.

A tool named lookup with no description and parameters named a and b is provided to Claude.

A create_ticket tool has a priority parameter typed as a plain string with no enum or description. In production, Claude has supplied values like "urgent!!", "P1", and "high priority" inconsistently.

An agent has both search_orders (looks up an existing order by ID) and search_order_history (looks up a customer's past orders by customer ID) — both described only as "Search orders." The agent frequently calls the wrong one.

A team validates Claude's structured output against a Zod schema after each call. On the first failure they observe, they simply retry the exact same request unchanged, expecting a different outcome.

An extraction pipeline retries a failed schema validation indefinitely until it eventually passes.

A team needs Claude to extract structured shipping details (recipient, address, weight) from freeform customer emails and feed them directly into a shipping API with no human review. Some emails are ambiguous or missing fields entirely.

A structured-output pipeline extracts a total dollar amount and a list of line items from an invoice via Claude.

An extraction pipeline for scanned invoices needs to identify which of several company names printed on a document is the vendor, as opposed to the bill-to company — a distinction that different documents represent inconsistently across letterhead, header labels, and positioning.

A team is designing an extraction pipeline for messy vendor invoices (scans, emails, PDFs) that must feed a downstream accounting system with zero tolerance for malformed records. They propose: a system prompt describing the assistant's durable role as an invoice-extraction specialist; a user prompt per document wrapping the document text in <document> tags alongside 3 few-shot examples of correctly extracted invoices, including one edge case; a forced tool call with a defined schema for the extracted fields; Zod validation of the tool call's input; and, on validation failure, feeding the specific error back to the model and retrying up to 3 times before escalating to a human queue.