Prompt Engineering That Actually Works: Clear Goals, Context, Examples, Constraints, and Evals

Prompt Engineering That Actually Works: Clear Goals, Context, Examples, Constraints, and Evals

Good prompting is not about discovering one magical phrase. It is about giving a model enough goal, context, constraints, and examples to understand what success looks like—and then testing that prompt on realistic tasks.

Modern models are better at understanding natural instructions than older systems, so the best prompts are usually clear and goal-driven rather than packed with rituals or unnecessary “secret prompt” tricks.

Start with the actual goal

Weak prompt:

Improve this.

Stronger prompt:

Rewrite this API documentation for backend developers who already know HTTP.
Keep it concise, preserve all technical behavior, and add one example request and response.

The stronger version tells the model:

• task
• audience
• scope
• desired level of detail
• required output

OpenAI's current guidance similarly recommends clear, specific prompts with enough context and a defined outcome.

Give context the model cannot infer

A model does not automatically know your internal norms.

Useful context can include:

who the reader is
what system this belongs to
what has already been decided
which facts are authoritative
what must not change

Example:

This is a public REST API already used by mobile clients.
Do not rename existing fields or endpoints.
We only want to improve error documentation.

Without this, the model might “improve” something by breaking compatibility.

Separate instructions from source material

When a prompt contains documents, code, or user-generated content, clearly separate them from the instructions.

For example:

Task:
Summarize the incident and list confirmed causes only.

Incident report:
---
...source text...
---

This helps the model distinguish what to do from what to analyze.

Structured delimiters, Markdown sections, or XML-style tags can all work; consistency matters more than one exact syntax.

Specify the output contract

If the format matters, say so.

Examples:

Return exactly three recommendations.

Use this structure:
## Problem
## Root Cause
## Fix

Return valid JSON matching this schema.

Do not assume the model will infer your downstream parser or UI needs.

For machine-consumed outputs, use structured-output/schema features where the model/API supports them rather than relying only on prose instructions.

Say what to do, not only what to avoid

A prompt full of negatives is hard to optimize:

Don't be verbose.
Don't add headings.
Don't repeat.
Don't sound robotic.

Prefer a positive target:

Write 3–5 concise paragraphs in natural professional prose. Include only information that changes the reader's decision.

Anthropic's current prompting guidance explicitly recommends telling the model the desired behavior/format instead of describing only what not to do.

Use examples for stable patterns

Examples are especially useful when you need consistent:

• classification
• tone
• formatting
• extraction
• edge-case handling

Suppose you want issue severity labels:

Example input: Login button is 2px misaligned
Output: low

Example input: Any user can read another tenant's invoice
Output: critical

Then provide the real case.

Examples teach the decision boundary more precisely than a long abstract description.

Make examples representative

Do not show three almost-identical examples.

Good examples cover:

• normal case
• boundary case
• failure/ambiguous case

A model may overfit to accidental patterns in the examples, so diversity matters.

Explain important constraints when the reason affects behavior

Compare:

Do not rename the slug.

with:

Preserve the slug because it is the canonical public URL and changing it would break existing links/SEO.

The second instruction helps the model generalize correctly if a related URL decision appears later.

Not every rule needs an explanation, but high-impact constraints often benefit from one.

Put authoritative facts in the prompt or retrieve them

If a task depends on information the model should not guess, provide or retrieve it.

Examples:

• current software version
• contract clause
• product limits
• repository state
• customer record

Do not compensate for missing evidence by adding stronger language such as “be extremely accurate.”

Accuracy comes from access to the right information plus verification.

Ask for uncertainty behavior

For research tasks, specify what to do when evidence is missing:

Do not invent a value. If official sources do not confirm it, state that it could not be verified.

This is more useful than simply saying “do not hallucinate.”

It gives the model an acceptable fallback behavior.

Prompt for the right amount of detail

Output length should match the task.

Examples:

Explain in under 150 words for a product manager.

Give a detailed architecture review including trade-offs and failure modes.

Current model families can differ in default verbosity, so explicitly requesting concise or detailed output can improve consistency.

Use roles only when they add real context

A role can be useful:

You are reviewing this as a senior database reliability engineer.

That may focus the response on reliability risks.

But decorative roles such as:

You are the world's greatest genius...

usually add little useful task information.

The most valuable role tells the model which domain lens and responsibility to apply.

Break complex tasks into clear stages

For a multi-step task, define the workflow:

1. Inspect current implementation.
2. Identify root cause.
3. Propose minimal fix.
4. Implement.
5. Run relevant tests.
6. Summarize changed behavior.

This is especially useful when the order matters.

Do not over-prescribe the model's hidden reasoning with dozens of tiny thought steps. Give the external workflow and success criteria; allow the model flexibility inside each stage.

Prefer general goals over brittle micromanagement

A prompt can become worse when it encodes one solution too early.

Instead of:

Use Redis sorted sets, create exactly three keys, then...

when the design has not been verified, say:

Design the simplest scalable leaderboard for this workload. Evaluate Redis data structures and justify the chosen representation.

Micromanage only constraints that are truly fixed.

Use iterative prompting when the task itself is exploratory

OpenAI's current prompt guidance recommends iterative refinement for complex work.

A useful loop can be:

first: inspect/analyze
then: choose approach
then: produce final artifact

This is better than asking for a polished implementation before the model has seen the current repository/data.

For autonomous agents, those stages can happen inside one workflow using tools rather than requiring the human to write a new prompt each time.

Long documents need context structure

For large document tasks:

• clearly label each document/source
• preserve source metadata
• keep the actual question explicit
• retrieve only relevant sections when possible

Anthropic's current long-context guidance emphasizes deliberate placement and structure of long source material rather than dumping unorganized text into a prompt.

Ask for evidence-based answers when sources matter

Example:

Use only the attached report. Cite the line/page supporting each key claim. If the report does not contain an answer, say so.

This prevents the model from silently mixing general knowledge into a source-grounded task.

If outside research is allowed, say which sources should be preferred.

Tool instructions should describe when and why to use tools

For agents, define tool behavior around intent:

Use web search for version-sensitive/current claims.
Use repository search before proposing code changes.
Re-fetch an external object immediately before a version-guarded edit.

Do not require unnecessary tool calls just to appear thorough.

Tools add latency and failure risk, so every call should serve the task.

Define mutation safety explicitly

For actions that change external state, prompts should include safety invariants:

Never overwrite a concurrent change.
Fetch the latest version first.
Verify the object after mutation.

This is far more important than stylistic prompt tricks.

Prompt injection changes how source content should be treated

When an agent reads arbitrary webpages, documents, or emails, that content can contain instructions aimed at the model.

Your system should define those sources as untrusted data.

The prompt hierarchy must keep tool/document content from overriding developer/user intent.

This is an agent security problem, not just prompt wording.

Evaluate prompts with a test set

Do not judge a prompt by one impressive response.

Build representative cases:

• easy
• normal
• edge case
• ambiguous
• adversarial

Score things such as:

• correctness
• instruction following
• format
• evidence grounding
• latency/cost

Then compare prompt revisions on the same dataset.

Change one thing at a time

If you simultaneously change:

• model
• prompt
• retrieval
• tools
• temperature/config

and quality improves, you do not know why.

For important systems, make targeted changes and run regression evals.

Prompt engineering becomes much more reliable when treated like software/configuration engineering.

Avoid myths and cargo-cult prompting

Be skeptical of claims that one phrase always unlocks better reasoning.

Model behavior changes across model generations.

Current prompting docs from both OpenAI and Anthropic emphasize plain clarity, useful context, examples, desired format, and model-specific guidance over universal secret formulas.

Keep prompts readable enough that a human teammate can understand the task contract.

Revisit prompts after model upgrades

A prompt tuned around weaknesses of an older model can cause overthinking or unnecessary verbosity on a newer one.

After upgrading:

1. run your eval suite
2. remove obsolete scaffolding
3. check output length/tool behavior
4. simplify where possible

Do not treat a system prompt as write-once configuration.

A reusable prompt template

For many tasks:

Goal
What outcome is needed?

Context
What facts/system state does the model need?

Constraints
What must remain true?

Sources/tools
What should be used and when?

Output
What should the final artifact look like?

Failure behavior
What should happen if evidence is missing or an action cannot be verified?

Not every prompt needs all six sections. Use only what materially helps.

Prompt checklist

Before blaming the model, check:

• Is the task unambiguous?
• Is necessary context provided?
• Are hard constraints explicit?
• Is desired output/length clear?
• Would one or two examples clarify the pattern?
• Does the model have the evidence/tools needed?
• Is missing-information behavior defined?
• Is the prompt full of obsolete or conflicting rules?
• Has it been evaluated on more than one example?

The best prompt techniques are boring in a good way: clear goals, relevant context, explicit constraints, representative examples, defined outputs, and regression evals. Prompt engineering works best when it makes the task easier to understand rather than making the prompt more theatrical.

References

• OpenAI — Prompt Engineering Best Practices
• OpenAI — How to Create a Good Prompt
• Anthropic — Prompting Best Practices