Write observable pass criteria before running the prompt
A useful criterion describes something a reviewer can point to in the answer. Instead of good tone, write uses the requested audience vocabulary without inventing familiarity. Instead of accurate, write every factual claim is supported by the supplied notes or labeled as a question. Keep the list short enough that the same reviewer can apply it consistently.
Separate answer-shape checks from judgment checks. Required headings, table columns, length limits, and uncertainty labels can be inspected directly. Whether advice is appropriate, a claim is current, or a decision is fair may need an owner with domain context. The test table should name that owner rather than hiding the handoff inside a single pass score.
Use cases that fail in different ways
The normal case proves the basic workflow. The edge case stretches one real variable such as a long reference bundle, an unusual audience, or two competing priorities. The missing-context case checks whether the prompt asks for what it needs instead of inventing it. The conflicting-instruction case checks which rule wins. The format-stress case checks whether the answer remains inspectable when the material is messy.
Use realistic but safe examples. Remove private identifiers and avoid copying production secrets into a convenience test. When a prompt controls tools, files, accounts, publication, or decisions, add cases that confirm it asks before acting and stops when permission or evidence is missing.
Record the failure, not just the score
A pass or fail cell is too thin for revision. Save the prompt version, test input, answer excerpt or artifact location, failed criterion, and reviewer note. Describe the observable problem: omitted one required column, added a claim not found in the notes, followed the later conflicting instruction, or returned prose instead of the requested table.
Make one prompt change per test round when possible. If you change the role, context order, examples, stop rules, and output schema together, the rerun cannot show which edit helped. A narrow revision record also makes it easier to reverse a change that improves one case while breaking another.
Rerun the same table after every meaningful edit
Regression testing depends on keeping the cases stable long enough to compare versions. Run the edited prompt on the same five inputs and apply the same criteria. Add a new case when a real failure appears, but do not remove an inconvenient case merely because the newest version fails it.
Model behavior can vary, so one run is not a guarantee. For important workflows, repeat sensitive cases and review the spread of answers. Treat the table as a practical change log and review aid, not proof that a prompt is universally safe, factual, or reliable.