Prompt Engineering: Practical Techniques with Real Examples

A good prompt is the moment you tell a language model exactly what you want, put it in the right frame of mind, and ask for the result in a usable shape. Prompt engineering is not a magic trick; it is closer to the craft of writing a good brief. In this article we cover five practical techniques through everyday analogies: clear instructions, learning from examples, step-by-step reasoning, role assignment, and output formatting.

What is prompt engineering?

The text you write to a language model is called a prompt. The model takes this text as context and produces the most likely continuation. In other words, it does not really "look up" an answer; it predicts the statistically best text. This simple fact explains why the techniques work: the better the start you give the model, the more accurate the continuation.

Think of it like briefing a new intern. The intern is smart and well-read, but does not know the context in your head. Say "just handle this" and they will guess; give a clear brief and they get it right the first time. Prompt engineering is the discipline of writing that brief.

The model cannot read your mind. You have to put every constraint and every preference into words; otherwise the model fills the gaps with its own assumptions.

Clear instructions: what, for whom, how

The most basic technique is to say what you want without leaving room for ambiguity. A weak prompt usually omits three things: the task (what to do), the audience (who it is for), and the constraints (length, tone, language, format).

• Vague: "Explain AI to me."
• Clear: "Explain AI for high-school students in 150 words, using an everyday analogy and no technical jargon."

The second prompt pulls a far more useful answer out of the same model, because it sets the goal, the limit, and the tone up front. Also prefer positive instructions: "write in flowing paragraphs" usually beats "don't use bullet points," because you show the model what to produce rather than what to avoid.

Learning from examples (few-shot)

Sometimes it is easier to show what you want than to describe it. Putting a few input-output pairs inside the prompt is called few-shot; giving none is zero-shot. Examples convey the format and style you want more clearly than words can.

It is the difference between reading a recipe to a cook and showing them a finished plate and saying "make it like this." The second is often faster and less error-prone.

Task: Label the customer review as positive / negative / neutral.

Review: "Shipping was super fast, loved it."
Label: positive

Review: "The product wasn't like the description."
Label: negative

Review: "Decent for the price."
Label: neutral

Review: "The box was dented but the item was intact."
Label:

Here we did not describe the rule to the model; we showed it with three examples. The model will complete the fourth line in the same shape. Few-shot is especially powerful for classification, format conversion, and tasks that need a consistent style.

Step-by-step reasoning

For questions that need multi-step reasoning, asking the model for its thinking process before the answer improves accuracy. This approach is usually called chain-of-thought; the best-known trigger phrase is "let's think step by step."

Why does it work? The model advances by predicting one word on top of another. Give it room to write the intermediate steps, and each step becomes solid ground for the next; force it to leap straight to the result and the chance of error rises. It is the difference between "write the answer only" and "show your work" on a math exam.

Remember: step-by-step reasoning is not needed everywhere. For a simple, single-step question, asking for extra reasoning only slows things down and adds needless length. Save the technique for tasks that genuinely require more than one step.

Assigning a role

Assigning the model an identity steers it toward the right region of knowledge and tone. A line like "You are an experienced editor" or "You are a meticulous security reviewer" noticeably shifts the focus and tone of the answer.

It is like a theatre director casting an actor: tell them "you are playing an impatient lawyer" and every line falls into that frame. For the model too, a role shapes the expectation of which words are "appropriate."

• No role: "Fix this text."
• With a role: "You are a meticulous technical editor. Shorten this text without changing its meaning; simplify the jargon and explain the reason for each change in a single sentence."

A role does not replace clear instructions; it strengthens them. You get the best result when you combine a role with a precise task.

Output formatting

If a program will process the answer, or you need a specific shape, describe the format explicitly. Constraints like "return JSON," "give only a table," or "each bullet at most one sentence" make the output predictable.

The most reliable method is to show the skeleton of the format you want:

Return the output in exactly this JSON schema, add no other text:

{
  "title": "...",
  "summary": "... (at most 20 words)",
  "tags": ["...", "..."]
}

Giving the skeleton leads to far fewer errors than describing the format in words. Adding a boundary like "add no other text" also stops the model from wrapping the answer in needless explanation; that is critical if you will feed the output straight into code.

One example that combines everything

These techniques work best together. The prompt below gathers a role, a clear instruction, an example, and a precise output format into a single brief:

You are an experienced customer support analyst.        # role
Your task: Classify the incoming email by urgency.      # clear instruction

Example:                                                # few-shot
Email: "I can't log into my account, my demo is in 1 hour."
{"urgency": "high", "reason": "time pressure"}

Now evaluate this email in the same JSON format,        # output format
add no other text:
Email: "There's a small typo on my invoice."

As you can see, prompt engineering is not about memorizing secret commands; it is about clearly conveying what you want, in which role, with which examples, and in which format. Once you internalize this discipline, you will get far more consistent and useful results from the same model.

Prompt engineering directly determines the quality of your communication with a language model. As you try these techniques in your own work, you will develop an intuition for which one a given situation calls for. For more on fitting AI into everyday workflows, take a look at our EcoFluxion page.