Prompt Pattern Decision Guide

Choose a pattern by failure mode

Start with direct instructions and a clear output contract. Add one or more examples when the model needs help recognizing edge cases, tone, classification boundaries, or a hard-to-describe format. Break work into explicit stages when intermediate evidence must be inspected or when later actions depend on earlier checks.

Use retrieval or tools when required facts are absent or volatile; wording cannot recover unavailable information. Use a supported schema feature when application code requires typed data. Use human approval and trusted application controls for consequential actions; prompt text is not an authorization system.

Fill in a pattern card

Version the instruction and keep provider-specific controls outside the portable core. The same evaluation cases should run against the baseline and candidate.

Failure to prevent: [SPECIFIC FAILURE]
Base instruction: [DIRECT TASK CONTRACT]
Pattern selected: [DIRECT | EXAMPLES | STAGED | RETRIEVAL | TOOL | SCHEMA]
Why this pattern: [MECHANISM MATCHING THE FAILURE]
Examples or context: [MINIMUM TRUSTED MATERIAL — NO SECRETS]
Expected result: [OBSERVABLE BEHAVIOR]
Evaluation cases: [REPRESENTATIVE, EDGE, ADVERSARIAL]
Pass threshold: [MEASURE]
Rollback: [LAST KNOWN GOOD PROMPT VERSION]

Expected result and verification

The expected result is a simpler prompt whose added structure addresses a named failure without degrading important slices such as safety, factuality, format, latency, or cost.

Run the same representative, edge, and adversarial cases against the baseline and candidate. Record the model and provider configuration, classify failures, compare critical slices, and adopt only when the pass threshold is met. Recheck current provider guidance before relying on model-specific syntax.