Prompt Engineering & Structured Output

1. 4.1Explicit criteria in promptsReplace vague review instructions with explicit report-versus-skip criteria and severity examples, disabling noisy categories temporarily to protect developer trust.
2. 4.2Few-shot promptingUse two to four targeted examples to lock in output format, show how to handle ambiguous cases, and reduce hallucination across varied document structures.
3. 4.3Structured output with tool useDefine a tool whose input schema is the shape you want, pick the right tool_choice, and design nullable fields and extensible enums so the model reports rather than invents.
4. 4.4Validation, retry and feedback loopsValidate extractions, retry with the document and specific errors, recognize when information is simply absent, and add fields that make failures analyzable.
5. 4.5Batch processingUse the Message Batches API for latency-tolerant work at half the cost, schedule submissions against the SLA, and resubmit only failures by custom_id.
6. 4.6Multi-instance and multi-pass reviewReview generated code with a fresh instance rather than the one that wrote it, and split large reviews into per-file passes plus a cross-file integration pass.

• Replace words like "important" or "significant" with explicit conditions for what to report and what to skip.
• Use two to four targeted examples, especially for the ambiguous cases, to fix format and judgment.
• Get structured output by defining a tool whose input schema is the shape you want.
• Make fields nullable when the information may be missing, so the model reports absence instead of inventing a value.
• Add an "other" option with a detail field to enums that may not cover every case.
• On validation failure, retry with the original document and the specific error; stop retrying when the data simply isn't there.
• Use the Message Batches API for work that can wait up to 24 hours (it costs half as much), never for checks someone is waiting on.
• Split big reviews into per-file passes plus one pass that looks across files.

• Telling the model to "be more careful" or "only report important issues".
• Parsing JSON out of free text and patching failures with cleanup code.
• Required fields that force the model to invent a value.
• Moving a check that blocks merges onto the batch API to save money.
• Asking the same session that generated code to review it.

You get 4 of the 6 scenarios at random, so practice this domain in each of them. All six scenarios.

1. Write a code review prompt with explicit report and skip criteria, and measure false positives before and after.
2. Build an extraction tool with a JSON schema that has a nullable field and an enum with "other".
3. Add a validation and retry loop that sends the exact error back with the document.
4. Submit a small batch, match results by custom_id, and resubmit only the failures.