Prompt Engineering Guide: Write AI Instructions That Work

Prompt engineering is the practice of turning an intended result into instructions a model can execute and a person can review. It is less about secret phrases and more about context, constraints, examples, and a clear definition of done.

Research and disclosure: Guidance is based on OpenAI prompting guidance, Anthropic prompting overview, and Google Gemini prompting guide, reviewed September 2, 2026. Model behavior changes, so test prompts against the model and task you actually use.

The five-part prompt

1. Task: state the action and the intended outcome.
2. Context: provide the source material, audience, and relevant background.
3. Constraints: set length, tone, exclusions, privacy limits, and allowed sources.
4. Output contract: specify headings, fields, examples, or a schema.
5. Checks: ask the model to flag uncertainty and verify required conditions.

Task: Turn these interview notes into a one-page product brief.
Audience: Product and engineering leads.
Use only: The supplied notes; label missing evidence as an open question.
Output: Problem, users, constraints, proposal, risks, and next actions in Markdown.
Checks: Separate facts from assumptions and list five questions for review.

Improve prompts with evidence

Run a small set of representative inputs, including incomplete and contradictory examples. Compare outputs against the checks rather than judging one impressive response. Keep the prompt version, model, input, and reviewer notes together so improvements are reproducible.

For a reusable library, keep the task statement, a passing example, a known failure, and model assumptions beside each prompt. The Ottermind AI prompt library guide covers maintenance; this guide focuses on writing and testing the instruction itself.

A practical review rubric

Score each output on four questions: did it use permitted evidence, follow the requested shape, make uncertainty visible, and satisfy the intended audience? If a score is unclear, rewrite the acceptance check rather than adding more adjectives.

From vague request to production prompt

Consider a request such as “summarize these customer interviews.” Before writing instructions, decide what the summary will change. A product team may need recurring pain points and representative quotes; an executive may need three decisions and their risks; a support team may need an updated answer library. The same source needs different output contracts.

Write the transformation in stages:

1. Extract statements and attach an interview identifier.
2. Group similar statements without erasing disagreement.
3. Count or qualify the groups using the supplied sample only.
4. Draft implications and label them as interpretation.
5. Ask a reviewer to approve the claims before publishing.

This staged approach is usually more reliable than asking for a polished conclusion in one pass. It also gives you useful checkpoints when the output is wrong.

Use examples carefully

Few-shot examples are powerful when the desired format is difficult to describe, such as classifying support tickets or extracting fields from invoices. Use examples that represent the boundary cases, not only easy inputs. Explain why an example is correct when the distinction is subtle. Keep examples short enough that they do not crowd out the actual source material.

For sensitive work, replace names, account numbers, and private details with realistic placeholders. A prompt that teaches a model to handle confidential data is not a reason to send confidential data to an unapproved service.

When a prompt needs tools

If the task requires search, file access, or a calculation, describe the tool's role and failure behavior. State which sources are allowed, what happens when a call returns no result, and whether the model may take an external action. Pair a tool-enabled prompt with application-level permission checks; a sentence asking the model to “be careful” is not a security control.

Techniques that generalize

• Use delimiters to separate instructions from untrusted source text.
• Ask for structured output when another system will parse the result.
• Give one or two examples when the desired shape is hard to describe.
• Break research, drafting, and critique into separate passes.
• Tell the model what to do when information is missing.

What prompt engineering cannot solve

A prompt cannot make stale sources current, turn an unclear goal into a good strategy, or guarantee factual output. Add retrieval, permissions, human review, and tests when the result affects customers, money, or production systems.

FAQ

Is prompt engineering still useful with better models?

Yes. Better models follow clearer goals more reliably, but they still need accurate context, boundaries, and an acceptance test.

Should prompts be long?

Only when the task needs the detail. Remove repeated or decorative instructions that do not change the decision or output.

How do I reuse a prompt?

Store the task, inputs, output contract, examples, model assumptions, and a few passing test cases. Review it when the workflow or model changes.

What is the fastest way to learn?

Start with one recurring task, write the five parts, test failure cases, and revise against observable errors.