How to Write a Prompt with Clear Success Criteria

A prompt with clear success criteria states what a good answer looks like before the model starts writing: the outcome you want, the constraints that matter, the evidence the model may use, and what the final answer must contain. OpenAI’s prompt guidance for GPT-5.5 frames this as the central shift for current models — describe what good looks like and leave room for the model to choose an efficient solution path. Anthropic’s guidance on defining success criteria supplies the other half of the job: criteria should be specific, measurable, and achievable, and they should be paired with evaluations that test them.

This article is for practitioners who already write prompts and want results they can verify rather than merely read. It covers what counts as a success criterion, a reusable four-part prompt structure, a worked example, how to convert criteria into checks, and the failure modes that quietly make criteria worthless.

Task instructions, success criteria, and process instructions

These three things are usually mixed into one block of text, which is why prompts can grow long without becoming clearer.

• Task instruction — what to do: “Classify this support ticket.”
• Success criteria — what makes the result acceptable: “The label must come from a fixed list; the answer must quote the sentence in the ticket that justifies the label; if no sentence supports a label, return unclear.”
• Process instructions — how to get there: “First read the subject line, then read the body, then decide.”

Process instructions are the part most likely to be unnecessary. OpenAI’s guidance notes that legacy prompts often over-specify the process because earlier models needed more help staying on track, and that carrying over every instruction from an older prompt stack can add noise, narrow the model’s search space, or produce overly mechanical answers. Success criteria sit on the outcome side of that divide: they constrain the result, not the route taken to it.

What makes a criterion clear enough to check

Anthropic defines good success criteria as specific, measurable, and achievable. Applied to a single prompt, those three adjectives translate into practical rules.

Specific means the criterion names the thing being judged. “Good performance” is not a criterion; “accurate sentiment classification” is. A criterion that could describe almost any task gives the model nothing to aim at and gives you nothing to test.

Measurable means that after the output arrives, you can decide whether it passed. Some criteria are measurable by machine — a required label set, a word limit, valid JSON, a required citation. Others are measurable by a defined human scale, such as a rubric or a rating from 1 to 5. Anthropic notes that even hazy topics such as ethics and safety can be quantified: a criterion like “less than 0.1% of outputs out of 10,000 trials flagged for toxicity by the content filter” is far more useful than “safe outputs.”

Achievable means the target is grounded in something real — a benchmark, a prior version of the prompt, or a baseline model — rather than an aspiration. If you have never measured the current prompt, you cannot know whether a new criterion is ambitious or impossible.

A useful sanity check: write each criterion as a sentence a reviewer could apply without asking you a follow-up question. If they would need to ask “what counts as good here?”, the criterion is not finished.

A four-part prompt structure

The OpenAI guidance reduces to four questions a prompt should answer. They map cleanly onto a template you can reuse.

The output contract is the component most often missing, and it is the one that makes verification possible. A free-form paragraph is hard to check; a fixed set of fields with stated value ranges can be checked automatically. Where an answer must be judged by a person, the contract should still say what that person will look at.

Worked example: triaging support emails

The following is an illustrative example, not a measured result. It shows how the same task looks before and after criteria are made explicit.

A weak prompt:

Summarize this customer email and tell me if it is urgent.

A revised prompt that states the outcome, constraints, evidence, and output contract:

Task: Summarize the customer email below and assign an urgency label.

Output format: return JSON with exactly these keys:
- "summary": one sentence, maximum 25 words, in English
- "urgency": one of "low", "normal", "high", or "unclear"
- "evidence": the exact sentence from the email that justifies the urgency label

Constraints:
- Do not invent details that are not present in the email.
- If no sentence justifies a label, set "urgency" to "unclear" and "evidence" to an empty string.
- Do not include any text outside the JSON object.

Email:
<paste email here>

The second version is longer, but every added line is checkable. The summary length is countable. The label set is enumerable. The evidence field can be compared against the input text to confirm it was copied rather than generated. The escape hatch for unclear removes the pressure to guess.

Turning criteria into checks

Criteria describe what good looks like; evaluations measure whether you got it. Anthropic’s guidance describes a cycle — test cases, a preliminary prompt, iterative testing and refinement, final validation, ship — and the criteria you wrote are the specification for each stage.

Start with a small set of representative inputs and human-assigned expected outputs. Twenty labeled examples are usually enough to expose obvious problems, though the right number depends on how varied the task is. Then choose metrics that match the task:

• Task-specific metrics: F1 score, BLEU score, perplexity.
• Generic metrics: accuracy, precision, recall.
• Operational metrics: response time in milliseconds, uptime percentage.

For subjective qualities, Anthropic suggests qualitative scales such as Likert ratings (“rate coherence from 1 to 5”) and expert rubrics, with the caveat that qualitative measures are most valuable when applied consistently alongside quantitative ones. A rubric that two reviewers apply differently is not a measurement.

Two further techniques are worth building in early. A/B testing compares the prompt against a baseline model or an earlier version, which is how you know whether a change helped. Edge case analysis tracks the percentage of edge cases handled without errors — empty inputs, mixed languages, tickets containing two unrelated problems, and similar boundary conditions. Edge cases are where over-specified prompts and vague prompts both tend to fail, for opposite reasons.

For structured outputs, some checks need no model at all: parse the JSON, confirm required keys exist, confirm enumerated values are in range, confirm quoted evidence appears in the source. These deterministic checks are fast, free, and unambiguous, and they should run before any judgment-based grading.

Failure modes that make criteria useless

• Unmeasurable adjectives. “Be helpful,” “be professional,” and “be concise” cannot be passed or failed. Replace them with a count, a list, or a rubric.
• Conflicting criteria. “Answer in under 50 words” plus “explain all six steps” is not a hard task; it is an impossible one. The model will silently drop one requirement.
• Style criteria without correctness criteria. A prompt can produce beautifully formatted output that is wrong. Formatting is easy to check, which makes it tempting to over-invest there.
• Over-specification of process. As OpenAI notes, prescribing every step can narrow the model’s search space and yield mechanical answers. State the destination; let the model choose the path.
• Criteria with no test. A criterion nobody measures is documentation, not a control. If you cannot describe how you would check it, rewrite it or drop it.

Where this matters for local models and automation

Success criteria are prompt content, not a provider feature, so the same approach applies whether you call a hosted API or run weights on your own hardware. Two practical differences are worth noting. First, when output is constrained to a fixed structure — JSON with enumerated fields — downstream automation can validate it without a second model call, which keeps workflows cheap and predictable. Second, criteria that are explicit in the prompt are easier to audit later, which matters in WordPress and automation contexts where a prompt may run unattended and its output may be published or acted upon.

Where output feeds a public post, a customer reply, or any decision with consequences, keep a human review checkpoint in the workflow. Criteria tell you what to check; they do not remove the need for someone to check it.

Limits and verification gaps

Clear criteria improve the odds of a usable answer; they do not guarantee a correct one. A model can satisfy every stated criterion and still be wrong about the underlying facts, particularly when the evidence field only proves that a sentence was copied, not that the sentence supports the conclusion. Judgment-based grading introduces its own error, which is why Anthropic’s guidance treats evaluation as an iterative discipline rather than a one-time setup.

Criteria also age. Prompts tuned for one model version may behave differently after an update, and a criterion that was achievable against one baseline may no longer be. Re-running the eval set after a model or configuration change is the only reliable way to know. If you have not measured anything yet, treat any claim about prompt quality — including your own — as an untested hypothesis.

What to do next

Pick one prompt you use regularly. Write down its outcome, constraints, evidence, and output contract as four separate blocks. Then write five criteria a reviewer could apply without asking you a question, and build a handful of test cases with expected outputs. Run the current prompt against them first, so you have a baseline before you change anything. If you get stuck on a specific failure — a criterion the model keeps ignoring, or a metric that does not match what you actually care about — bring the prompt, the environment, and the observed output to the community and compare notes with other practitioners.