Prompt Engineering Explained Simply: Zero-Shot, Few-Shot and Chain of Thought

Start with a new teammate

Imagine a new person joins your team on Monday morning. They are clever. They have read an enormous amount. They are fast, patient and never tired.

But they have one strange gap: they do not know who you are, what your team does, or what a good answer looks like here. They only know what you tell them in the message in front of them.

So the quality of their work depends almost entirely on the quality of your instructions. Vague instructions produce vague work. Clear instructions with an example produce work you can actually use.

That is the whole idea behind prompt engineering. A large language model (an LLM) is that clever new teammate. Prompt engineering is simply the craft of writing the instructions well.

This post walks through that craft one small step at a time. No maths. No jargon without an explanation. If English is not your first language, you should still be able to follow every paragraph, because every idea gets a small picture next to it.

What a prompt actually is

A prompt is just the text you send to the model. That is it. There is no magic word and no secret syntax.

What the model does with that text is worth understanding, because it explains almost every trick later in this post. The model reads your text and then predicts what should come next, one small piece at a time. It keeps predicting until it decides the answer is finished.

The model is not looking things up in your company folder. It is not reading your mind. It is continuing the text you gave it. So whatever you leave out, it has to guess.

Two useful consequences follow from this, and they explain a lot:

• The model copies patterns. If your prompt is written in bullet points, the answer often comes back in bullet points. If you show it one worked example, it tends to follow the same shape. This is not a bug. It is the single most useful lever you have.
• The model cannot ask you for the missing part unless you invite it to. It will usually make a reasonable guess and carry on. Half of prompt engineering is simply removing the need for it to guess.

The three voices in a conversation

When you use an LLM through an app or through code, the conversation is usually split into three kinds of message. Beginners often mix them up, so it is worth being slow here.

The system message is the standing brief. It is where you say things like "you are a careful reviewer", "always answer in Nepali", "never invent a source", "finish with a score from 1 to 5". You write it once, and it quietly shapes every answer after that.

The user message is the specific request. "Review this paragraph." "Summarise this email." "Which of these two designs is safer?" It changes each time.

The assistant message is what comes back. It is not something you write, it is the output. When people say "the model produced a review", they mean the assistant message.

Why does the split matter in practice? Because putting a rule in the wrong place is one of the most common reasons a prompt misbehaves.

| Put it in the system message | Put it in the user message | | --- | --- | | The role the model should play | The specific thing to work on | | The output format you always want | Today's question | | Rules that must never be broken | Details that only apply this once | | The scoring scale, if you use one | The item being scored |

A rule buried in the middle of a long user message is easy for the model to skim past. The same rule in the system message tends to stick.

Prompts and prompt templates

Once you write more than a handful of prompts, you will notice you are typing the same sentences over and over, changing only a small part in the middle. That repeated shape has a name: a prompt template.

A template is a prompt with holes in it. You fill the holes to make a real prompt. Think of a recipe card that says "cook [VEGETABLE] for [MINUTES] minutes".

Templates matter for three practical reasons. They keep your results consistent, because the wording no longer drifts every time you type it. They make results comparable, because two items judged by the same template were judged by the same standard. And they make improvement possible: when you fix the template, every future prompt improves at once.

Now we can look at the actual prompting styles. There are three main ones, and they build on each other.

Style 1: Zero-shot prompting

Zero-shot means you give the instruction and nothing else. Zero examples. You simply ask.

Here is a small zero-shot prompt:

Read the customer message below and decide whether it is
urgent or not urgent. Reply with one word.

Message: "The payment page has been down since this morning and
no one can check out."

This works well, and most of the time it is the right place to start. Zero-shot is short, cheap and easy to read. For common tasks that the model has seen a million versions of (translate this, summarise this, fix the grammar), it is often all you need.

Its weakness is precise. You are letting the model choose the shape of the answer. Ask ten times and you might get "Urgent", "This is urgent", or a polite paragraph explaining why it is urgent. If a program downstream is reading that answer, the variation will break it.

The fix for zero-shot is not always to add examples. Often it is simply to be more specific:

Read the customer message below and classify it.

Reply with exactly one word, either URGENT or NORMAL.
Do not add any explanation or punctuation.

Message: "The payment page has been down since this morning and
no one can check out."

That second version is still zero-shot. There are still no examples. It is just a clearer instruction, and clearer instructions solve a surprising share of prompt problems.

Style 2: One-shot and few-shot prompting

Sometimes describing the answer you want takes longer than just showing one. That is where one-shot and few-shot come in.

• One-shot means you include exactly one finished example in the prompt.
• Few-shot means you include a small number of finished examples, usually two to five.

The example is not there to teach the model the topic. The model already knows the topic. The example is there to show the shape: how long the answer should be, what order the parts come in, what tone to use, which details to leave out.

Here is that idea written out as a real one-shot prompt:

Turn each change into a single line release note for
non technical users. Keep it under twelve words.

Example
Change: fixed a bug where the login session expired after 30 seconds
Note: Login no longer times out early.

Now do this one.
Change: added a dark mode toggle to the settings screen
Note:

Notice the last line. It ends with Note: and then stops. This is a small but powerful trick. You have started the answer for the model, so it naturally continues in exactly the right place and format.

When should you add more examples? Move from one-shot to few-shot when the task has different cases that should be handled differently. If some inputs are long and some are short, or some should be rejected and some accepted, show one example of each kind. A single example teaches the format. Several examples teach the boundaries.

When should you not? Examples cost space and money, because everything in the prompt is charged for. If a plain instruction already gives you the answer you want, adding examples just makes it slower and more expensive. And there is a subtler risk: bad examples are copied faithfully. If your one example happens to contain a small mistake, the model may treat that mistake as the rule.

Style 3: Chain of thought

Now the interesting one.

Some tasks fail not because the model does not know the answer, but because it answers too quickly. Ask a person "what is 17 times 24" and demand an instant reply, and they will often be wrong. Give them five seconds and a piece of paper, and they will be right.

Chain of thought prompting is the piece of paper. You ask the model to write out its intermediate steps before giving the final answer.

The simplest version is astonishing in how little effort it takes. You add one sentence:

A shop sells notebooks in packs of 8. A school buys 14 packs
and then gives 25 notebooks away. How many are left?

Think through this step by step, then give the final number
on its own line starting with "Answer:".

This is called zero-shot chain of thought, because there is still no example in the prompt. You have only asked for the reasoning to be written down.

The stronger version is one-shot chain of thought (or few-shot chain of thought). Here you include one worked example that itself shows the steps, so the model can see not just that it should reason, but how you want it to reason.

Here is a one-shot chain of thought prompt written out in full, so you can see the shape:

You classify support tickets. Work through each ticket in three
steps, then give the label.

Example
Ticket: "I was charged twice for my subscription this month."
Step 1 - What is the customer actually reporting? A duplicate charge.
Step 2 - Which team owns this? Billing owns payment problems.
Step 3 - Is money at risk right now? Yes, they have been overcharged.
Label: BILLING_URGENT

Now do this one.
Ticket: "The export button spins forever on large reports."
Step 1 -

Look at what the example is doing. It is not teaching the model what billing means. It is fixing the questions the model asks itself, and the order it asks them in. That is the real value of chain of thought in a production system: it makes the reasoning repeatable, not just present.

One important warning. Chain of thought makes answers longer, slower and more expensive, because every step is text the model has to generate and you have to pay for. For a simple lookup or a translation, it adds cost and buys nothing. Save it for tasks that genuinely have steps.

Putting the three side by side

Here is the whole picture in one table. If you remember nothing else from this post, remember this.

| | What you put in the prompt | Best for | Watch out for | | --- | --- | --- | --- | | Zero-shot | Instruction only | Common tasks, short answers, quick tests | The answer shape can wander | | One-shot / few-shot | Instruction plus one or more finished examples | Fixed formats, specific tone, unusual output shapes | Costs more, and copies mistakes in your examples | | Zero-shot with chain of thought | Instruction plus "work through it step by step" | Problems with several stages, when you want to see the reasoning | Steps vary from run to run | | One-shot with chain of thought | Instruction plus a worked example that shows the steps | Reviews, grading, anything you must audit later | The longest and most expensive option |

A sensible working order is: start at the top of that table and only move down when the results are not good enough. Most people jump straight to the bottom row, pay for it on every request, and never find out that a clearer one paragraph instruction would have done the job.

Using a model as a judge

One of the most useful things you can do with these techniques is ask a model to assess something rather than produce it. Reviewing a piece of writing, checking whether a document follows a rule, grading an answer, comparing two options. People call this pattern model as a judge.

It works, but it needs more care than an ordinary prompt, because a judgement is only useful if it is consistent. Here is the shape that tends to work.

The four parts are worth pausing on, because each one solves a specific problem.

Judge one rule at a time. If you ask "is this document good?", you get a vague paragraph. If you ask "does every claim in this document have supporting evidence listed underneath it?", you get something you can act on. Split a big review into several small runs, each with a single question.

Ask for the problem, the reason and the fix separately. Left to itself, a model will often merge all three into one sentence, and you lose the ability to count problems or act on them. Naming the three parts forces them apart.

Say what happens when nothing is wrong. This is the step everyone forgets. If your prompt only describes how to report problems, a model that finds no problems has no instructions, so it may invent a small one just to fill the shape. Add a line like: "If the item fully meets the rule, skip the problem list and instead explain in two sentences why it passes."

Define the score scale, including which end is good. A "1 to 5" scale with no explanation is a coin toss, because some people mean 1 is best and others mean 5 is best. State it explicitly and describe each number.

Here is a complete judge prompt that uses everything above. It is one-shot with chain of thought, which is the combination worth reaching for when the judgement will be recorded, compared or acted on.

SYSTEM MESSAGE

You review short product descriptions against a single rule.
The rule for this review is: every claim about a benefit must be
followed by a concrete detail that supports it.

Work in three steps for each problem you find.
  Step 1 - Quote the exact phrase that breaks the rule.
  Step 2 - Explain in one sentence why it breaks the rule.
  Step 3 - Suggest a rewritten version that follows the rule.

Then give a score on this scale, where 1 is best:
  1 - every claim is supported. Nothing to change.
  2 - one weak claim, easy to fix.
  3 - several unsupported claims, but the description is usable.
  4 - most claims are unsupported.
  5 - nothing is supported. Rewrite from scratch.

If you find no problems at all, skip the three steps and instead
write two sentences explaining why the description passes,
then give the score.

Here is a completed review to follow.

Description: "Our blender is incredibly powerful and will change
your mornings."
  Step 1 - "incredibly powerful"
  Step 2 - It promises a benefit but gives no measurement,
    so a reader cannot check it.
  Step 3 - "Our 1200 watt motor crushes frozen fruit in
    under ten seconds."
  Score: 4

USER MESSAGE

Review this description.

Description: "This backpack is unbelievably light and fits
absolutely everything you need for a week away."

Read that prompt again and notice how little of it is about the product. Almost all of it is about the shape of the answer. That ratio is normal for a good prompt, and it is the biggest single difference between prompts that work once and prompts that work every time.

A worked comparison

To make the difference concrete, here is the same small task written four ways. The task: decide whether a bug report has enough information for a developer to start work.

Zero-shot

Does this bug report have enough detail for a developer to
begin work? Answer YES or NO.

Report: "The app crashes sometimes."

You will almost certainly get NO, which is correct but not helpful. Nobody learns anything.

Zero-shot with chain of thought

Does this bug report have enough detail for a developer to
begin work?

First list what a developer would need. Then check the report
against your list. Then answer YES or NO on the last line.

Report: "The app crashes sometimes."

Now you get a list (steps to reproduce, device, version, expected behaviour), a check against it, and then the verdict. Much more useful, but the list may be different tomorrow.

One-shot

Judge whether a bug report is ready for a developer.

Example
Report: "Search returns nothing for two word queries on the
iOS app, version 3.2. Expected results to appear."
Verdict: READY
Missing: none

Now do this one.
Report: "The app crashes sometimes."
Verdict:

Now the output has a fixed shape, so a program can read it. But there is still no reasoning, so a borderline report may be judged inconsistently.

One-shot with chain of thought

Judge whether a bug report is ready for a developer. Check for
four things in this order: steps to reproduce, the exact result,
the expected result, and the version or device.

Example
Report: "Search returns nothing for two word queries on the iOS
app, version 3.2. Expected results to appear."
  Steps to reproduce: yes, search a two word query
  Exact result: yes, nothing is returned
  Expected result: yes, results should appear
  Version or device: yes, iOS app 3.2
Verdict: READY
Missing: none

Now do this one.
Report: "The app crashes sometimes."
  Steps to reproduce:

This is the version you would actually put into a tool. Fixed checks, in a fixed order, with a fixed output. Two people reading two different results can compare them fairly, because both were judged the same way.

Choosing a style without overthinking it

The important arrow on that diagram is the one on the left: stop when it works. Every extra sentence in a prompt is text you pay for on every single request, and text that can conflict with your other instructions. A short prompt that works is better than a long prompt that also works.

The mistakes that cause most bad answers

These come up again and again. Each one has a short fix.

| The mistake | Why it hurts | The fix | | --- | --- | --- | | Asking two things at once | The model does one well and rushes the other | One question per prompt, or number them clearly | | Not saying the output format | Every run comes back in a different shape | Show the exact shape, or give one example | | Politeness instead of instruction | "Maybe you could try to..." reads as optional | Write plain commands: "List", "Rewrite", "Score" | | Very long background before the task | The real request gets lost in the middle | Put the task first, then the background | | No rule for the "all clear" case | The model invents a problem to fill the shape | Say what to write when nothing is wrong | | A scale with no meaning | 1 to 5 means nothing on its own | Describe each number in one sentence | | Copying a shaky example | The model copies your mistake faithfully | Check your examples harder than your instructions | | Chain of thought on trivial tasks | Slow and expensive for no gain | Save the steps for problems that have steps |

Trying it in code

Everything above is just text, so it works in any language and any tool. Here is a small Python example using the Anthropic SDK, so you can see where the system message and the user message actually go.

import anthropic

client = anthropic.Anthropic()  # reads your API key from the environment

SYSTEM = """You judge whether a bug report is ready for a developer.
Check four things in this order: steps to reproduce, the exact
result, the expected result, and the version or device.

Write one short line for each check, then a final line that reads
either "Verdict: READY" or "Verdict: NOT READY"."""

report = "The app crashes sometimes."

message = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    system=SYSTEM,          # the standing rules
    messages=[
        {"role": "user", "content": f"Review this report.\n\n{report}"},
    ],
)

print(message.content[0].text)

Reading it in plain words:

• system is the standing brief. It never changes between reports, so it lives outside the loop.
• messages carries the specific request. In a real tool you would loop over many reports here, changing only this part.
• max_tokens is a ceiling on how long the reply may be. Chain of thought answers are longer, so give them more room than a one word classification.
• The reply comes back in message.content, and the text of the first block is the answer you would show or store.

To turn this into a few-shot prompt, you do not need a new function. You simply put the worked example inside SYSTEM, exactly as it appeared in the judge prompt earlier. That is worth repeating because it surprises people: all of these techniques are just different text in the same two fields.

Quick answers to common questions

Is prompt engineering going away as models get better? The mechanical tricks fade, and that is a good thing. Newer models need far less coaxing to reason well. What does not fade is the part that was never really about models: stating clearly what you want, what "good" means, and what the answer should look like. That is a description problem, and it stays.

How many examples should I include in a few-shot prompt? Start with one. Add a second only when you meet a case the first one does not cover. Most tasks never need more than three. If you find yourself at eight examples, your instruction is probably unclear and you are patching it with examples.

Does "think step by step" really change anything? For tasks with genuine intermediate stages, yes, and often noticeably. For a task with no stages, such as translating a sentence, it mainly adds length. The phrase is not magic; the steps are.

Should the reasoning be shown to my users? Usually not. Reasoning is working notes, not a finished answer. A common pattern is to ask for the steps, use them to reach a better final answer, then display only the final part to the reader while keeping the steps in your logs for debugging.

Why do I get a different answer each time I run the same prompt? Because generating text involves choosing between plausible continuations, and that choice is not always identical. Tighter instructions and a worked example reduce the wobble a lot. If you need the output to be machine readable, ask for a strict format and validate it in your code rather than trusting it.

Where should I put my instructions if the prompt is very long? Put the most important rules near the beginning and repeat the output format near the end, right before the model starts answering. The middle of a long prompt is the easiest place for an instruction to get lost.

A checklist you can keep

Before you send a prompt you plan to reuse, run down this list. It takes thirty seconds and catches most problems.

1. Role. Have I told the model what it is doing and for whom?
2. One job. Is this prompt asking for exactly one thing?
3. Format. Have I described or shown the exact shape of the answer?
4. Boundaries. Have I said what to leave out, and how long the answer should be?
5. The all clear case. Have I said what to write when there is nothing to report?
6. The scale. If I ask for a score, have I explained every number and said which end is good?
7. Steps. Does this task have real stages? If yes, ask for them. If no, do not.
8. The example. If I included one, is it genuinely correct? The model will copy it exactly.
9. Length. Can I delete any sentence without losing anything? Delete it.

The one thing to remember

Prompt engineering is not a collection of secret phrases. It is the ordinary skill of giving good instructions, applied to a reader who is extremely capable and completely without context.

Everything in this post reduces to three moves, and you now know all of them:

• Say what you want clearly. That is zero-shot, and it solves more than people expect.
• Show one finished answer. That is one-shot, and it fixes the shape of the output faster than any amount of description.
• Ask for the steps. That is chain of thought, and it turns one difficult jump into several easy ones, while leaving you a trail you can inspect.

Start at the top. Move down only when you have to. And when a prompt fails, resist the urge to add more words. Read it once more as if you had never seen the task before, and find the thing you assumed the reader already knew. That missing sentence is almost always the fix.

If you want to see how these ideas connect to the wider picture of how models are built and measured, the posts on why context windows matter and llm evaluations pick up naturally from here.

Tech stack

• Python with the Anthropic SDK for the code example, using claude-opus-5 as the model
• Plain text prompts, which work identically in any language, tool or chat window
• Hand drawn SVG diagrams and animations, inlined in the page so nothing extra is downloaded and everything stays sharp at any screen size