What Is Prompt Engineering? A Practical Guide With Examples

Prompt engineering is the practice of designing the input to a large language model (the instructions, context, examples and format requirements) so that the output is useful, accurate and consistent. In practice it means deciding what the model needs to know, what it should do, and what the result should look like, then testing whether the prompt actually produces that.

That definition sounds abstract, so most of this guide is examples. If you only remember one thing: a model can only work with what is in front of it. Most bad outputs come from a prompt that left out something the writer knew but never said.

#Why does the wording of a prompt matter so much?

A language model predicts a continuation of the text it was given. It has no access to your project, your audience, your previous drafts, or the conversation you had with your manager about tone. Everything it knows about your situation comes from the prompt (and, in chat apps, from earlier messages and any memory features).

So when a prompt says "write a summary of this report", the model fills every gap with a guess. How long? For whom? Bullet points or prose? Should it flag risks or stay neutral? The guess will be plausible and generic, because generic is the safest bet when information is missing.

Prompt engineering is mostly the discipline of closing those gaps on purpose.

#What does a good prompt look like?

Here is a request that people send to chat assistants every day:

Write an email to my team about the new deadline.

The model will produce a polite, bland email with placeholders like "[new date]". Not wrong, just useless without editing.

Now a version written by someone who has done this a few times:

Write a short email to my team of five backend engineers.

Context: The API migration deadline moved from March 14 to March 28
because the payments vendor delayed their sandbox. Nobody on the team
caused the delay. Two people had planned vacation around the old date.

Goal: Tell them the new date, explain the reason in one sentence,
and say that vacation plans should not change.

Tone: direct and calm, no corporate filler. Under 120 words.
Sign it "Dana".

Nothing clever happened there. The second prompt simply contains the facts, the audience, the goal, the tone and a length limit. That is the bulk of prompt engineering for everyday use.

#What are the components of a good prompt?

Different guides name them differently, but the same pieces keep showing up. You will not need every one in every prompt.

Task. The verb and the object. "Summarize", "classify", "rewrite", "extract", "compare". Vague verbs like "help with" or "look at" force the model to guess what you want done.

Context. Background the model cannot infer: who the audience is, what the document is for, what has already been tried. This is where most of the quality comes from. We cover it in depth in the role and context topic.

Constraints. Length, tone, reading level, things to avoid, things that must be included. Constraints are cheap to write and save a lot of back-and-forth.

Output format. Bullets, a table, JSON with specific keys, a single word. If a program will read the output, the format is not optional. The structured output topic covers that case in detail.

Examples. One to a few input/output pairs that show the pattern you want. Examples are powerful and also easy to misuse, which is why we wrote a separate piece on zero-shot vs few-shot prompting.

A role ("You are a senior tax accountant") is sometimes listed as a component too. It can help set vocabulary and depth, but a role without context does far less than people expect. "You are an expert marketer" adds little; "The readers are hospital procurement managers who skim on mobile" adds a lot.

#Is prompt engineering just for chatbots?

No, and this is where the term earns the word "engineering". There are two quite different jobs that share the name.

The first is conversational prompting: you, typing into ChatGPT, Claude or Gemini, iterating until the answer is good. Here you can correct course on the next turn, so a slightly weak prompt costs you a minute.

The second is prompts inside software: a support bot, a document classifier, a code review tool, an agent that calls APIs. The prompt runs thousands of times on inputs you never saw. Nobody is there to say "no, shorter". A small ambiguity that you would fix in a chat becomes a 4% failure rate in production.

The second job adds things the first rarely needs:

• A system prompt that defines behavior across every conversation (how to write one).
• Strict output formats so code can parse the result.
• Grounding the model in retrieved documents so it does not invent facts.
• Defenses against prompt injection, because user input and documents can contain instructions of their own.
• A test set: a few dozen real inputs you rerun every time you change the prompt.

That last point is the one beginners skip and practitioners never skip. If you change a production prompt without rerunning your test cases, you are guessing.

#A worked example: from vague to reliable

Say you want a model to sort incoming customer messages into categories. First attempt:

Categorize this customer message.

Message: "I was charged twice for my March invoice, please fix."

You get back something like "This message falls under the Billing category, as the customer is reporting a duplicate charge." Fine for a human, painful for code. And the next message might come back as "Payments" instead of "Billing", because you never said which categories exist.

Second attempt:

Classify the customer message into exactly one category.

Categories:
- billing: charges, refunds, invoices, payment methods
- account: login, password, profile, deleting the account
- bug: something in the product is broken or behaves wrongly
- other: anything else

Reply with only the category name in lowercase, nothing else.

Message: """I was charged twice for my March invoice, please fix."""

Three changes did the work. The label set is fixed, each label has a short definition so edge cases have somewhere to go, and the output format is spelled out. The triple quotes mark where the user's text starts and ends, which helps the model keep data and instructions apart (though it is not a security boundary against deliberate attacks).

Then you test it on twenty real messages, including awkward ones like "I can't log in to see my invoice". Is that billing or account? Your definitions should answer that. If they don't, the model will pick one inconsistently, and the fix is a sharper definition, not a sterner tone.

#Which prompting techniques should you know first?

A short, honest list, in the order they tend to matter:

1. Be specific about the task and the output format. Covers most everyday problems.
2. Give context. Audience, purpose, constraints, what "good" looks like.
3. Show examples when the format or style is hard to describe in words.
4. Ask for reasoning before the answer on multi-step problems. This is the idea behind chain-of-thought prompting, though newer reasoning models do much of this on their own.
5. Ground answers in sources when facts matter, using retrieval. This is what the grounding (RAG) topic is about.
6. Define tools clearly if the model can take actions.

You will notice there are no magic phrases on that list. Early on, people traded incantations like "take a deep breath" or offering the model a tip. Some of those had measurable effects on specific older models, but they do not transfer reliably, and they are no substitute for a prompt that says what you want.

#What prompt engineering is not

It is not a way to make a model know things it does not know. If the answer depends on your company's internal policy, no wording will produce it unless the policy is in the prompt or retrieved into it.

It is also not a one-time act. Models get updated, inputs drift, and a prompt that worked on one model can behave differently on another. Test on the model you actually use, and retest when it changes.

And it is not only writing. A large part of the job is reading outputs critically: spotting where the model followed the letter of the instruction but missed the intent, then working out which missing sentence caused it.

#How do you get better at it?

Write prompts for real tasks, read the outputs closely, and change one thing at a time. Read the prompting guides that OpenAI, Anthropic and Google publish for their own models; they are free, specific and written by people who see a lot of failure cases.

It also helps to practice the individual decisions in isolation: which of these four instructions fixes this output, where exactly does this prompt fail. That kind of drilling is what TokIQ, a quiz app we are building (coming soon to iOS and Android), is designed for. Whatever you use, the habit that matters is the same: treat every disappointing output as information about your prompt. For a structured path, see how to learn prompt engineering or start with the fundamentals topic.