Prompt Design: Defining the Task and Its Success Criteria

A prompt is not a magic phrase that unlocks hidden intelligence. It is an interface specification for a probabilistic system.

The clearest prompts reduce ambiguity about the work and the acceptable result.

Good prompt design states the goal, supplies relevant context, defines constraints, specifies the output, and makes success testable.

Decorative role-playing can affect style, but it cannot substitute for evidence, permissions, validation, or a well-defined task.

A concrete example: contract extraction

“Summarize this contract” leaves many choices open.

A stronger request is:

Using only the supplied contract, return a three-row table for renewal date, termination notice, and payment terms. Quote the supporting clause number. Write “not found” when the contract does not state a value.

This defines:

• the source boundary,
• requested fields,
• output shape,
• evidence requirement,
• and missing-information behavior.

Start with the user outcome

Before writing prompt text, define what the user needs to accomplish.

“Generate a response” is vague. “Draft a reply that answers the refund question using the current policy and leaves account-specific amounts for the support agent” is testable.

The outcome determines required data, risk controls, and evaluation criteria.

Separate instructions from data

Structure the request into clear regions:

• application instructions,
• user request,
• trusted context,
• untrusted documents or tool output,
• and output requirements.

Use labels or delimiters consistently. Tell the model that quoted documents are evidence, not instructions. This clarity helps behavior but does not create a security boundary; tool permissions must still be enforced by code.

Provide only relevant context

More context is not automatically better.

Repeated rules, unrelated examples, and large document dumps consume tokens and can distract from decisive evidence. Retrieve focused passages and include metadata such as source, date, and region when those distinctions matter.

Keep authoritative rules concise and remove contradictions.

State constraints positively and precisely

“Do not hallucinate” is difficult to operationalize.

Prefer instructions such as:

• use only the supplied sources for factual claims,
• cite the source identifier after each claim,
• write “insufficient evidence” when support is absent,
• do not infer account status,
• and never call a write tool without approval.

These rules describe observable behavior.

Specify the output contract

When software consumes the response, define a schema:

• field names,
• types,
• allowed values,
• required and optional fields,
• length limits,
• and error representation.

Use structured-output features when available, then validate the result in code. A prompt requesting JSON does not guarantee valid or semantically correct JSON.

Use examples deliberately

Examples can teach:

• desired format,
• classification boundaries,
• tone,
• edge-case handling,
• and refusal behavior.

Choose examples that represent the hard distinctions in the task. Too many easy examples waste context and can make the model copy superficial patterns.

Keep example inputs and outputs clearly separated from the live request.

Define uncertainty behavior

The prompt should say what to do when information is:

• missing,
• conflicting,
• outdated,
• ambiguous,
• or outside scope.

Possible behaviors include asking a clarifying question, returning a typed error, citing both sources, escalating, or declining to make a claim.

Without an explicit path, the model is encouraged to complete the pattern with plausible text.

Break complex work into stages

A single giant prompt may mix retrieval, analysis, calculation, drafting, and approval.

Separate stages when intermediate results can be validated:

1. identify required facts,
2. retrieve evidence,
3. extract structured values,
4. verify support,
5. draft the user-facing answer.

This improves observability and lets deterministic code handle calculations or policy checks.

Keep business rules outside when possible

Do not encode every changing price, permission, threshold, or compliance rule only in prose.

Store rules in authoritative systems and pass the current result or relevant data to the model. Code should enforce hard constraints such as maximum refund, allowed recipients, and approval requirements.

The prompt explains the task; it should not be the sole enforcement layer.

Version prompts like code

Track:

• prompt identifier and version,
• model and settings,
• retrieval configuration,
• tool definitions,
• evaluation results,
• rollout date,
• and change rationale.

A small wording change can affect behavior across many cases. Use review, tests, staged rollout, monitoring, and rollback.

Build an evaluation set

Collect representative cases, including:

• common requests,
• edge cases,
• adversarial inputs,
• missing evidence,
• conflicting instructions,
• multilingual examples,
• and prohibited actions.

Score dimensions separately: correctness, completeness, evidence use, format validity, tone, safety, latency, and cost. Do not optimize only for a few impressive demonstrations.

Protect against prompt injection

User input and retrieved content may attempt to override instructions or obtain secrets.

The application should:

• minimize exposed secrets,
• restrict tools by identity and task,
• validate tool arguments,
• require confirmation for consequential actions,
• treat external content as untrusted,
• and monitor suspicious attempts.

Prompt wording supports these controls but cannot replace them.

Avoid fragile prompt folklore

Claims that one phrase always makes a model reason better are rarely universal. Behavior changes across models, versions, tasks, and settings.

Use a simple baseline, change one meaningful element, and compare on the evaluation set. Keep techniques that produce measurable improvement without unacceptable cost or latency.

Prompt and model share responsibility

Some failures are not prompt failures. The model may lack capability, retrieval may omit evidence, a tool may be unreliable, or the task may require deterministic logic.

Diagnose the stage before repeatedly rewriting instructions. A clearer prompt cannot recover a document the retrieval system never supplied.

Knowledge check

1. What information makes a prompt testable?
2. Why is an output schema still validated in code?
3. When are examples most useful?
4. Why should hard business rules live outside prompt prose?
5. How should prompt changes be evaluated and released?

The one idea to remember

Prompt design is task and interface design. Define the outcome, evidence boundary, constraints, uncertainty behavior, and output contract; then version and evaluate the complete system instead of searching for a universally magical phrase.