What is prompt engineering?
Prompt engineering examples are concrete, before-and-after demonstrations of how changing the wording, structure, or context of an AI prompt changes the quality of the output. This page covers practical examples drawn from real work tasks, written for team leads and professionals who use ChatGPT, Claude, Copilot, or Gemini daily and want more consistent results without a technical background.
The term sounds more specialized than it is. At its core, prompt engineering just means writing your instructions to an AI model deliberately rather than typing the first thing that comes to mind. The "engineering" part is a little misleading: there is no code, no API, no machine learning knowledge required. You are editing sentences.
What makes examples useful is that they make the difference visible. Reading a list of best practices ("be specific," "give context") is easy to forget. Seeing a vague prompt produce a vague answer, and then seeing a revised prompt produce something you could actually use, is harder to ignore.
This page walks through how prompt engineering works mechanically, shows worked examples with the actual prompts and outputs, and covers where the approach breaks down. For a broader map of the underlying methods, the guide to prompting techniques is the right starting point.
How it works
Every prompt has the same basic anatomy: a task, context, and constraints. The skill is deciding how much of each to include, and in what order.
The task is what you want the model to do. "Write a summary" is a task. Context tells the model who the audience is, what the source material is, or why the output matters. Constraints shape the form: word count, tone, format, what to leave out.
Most weak prompts fail on context, not task. "Write a summary" gives the model nothing to work with. "Write a three-sentence summary of the following sales call transcript for a VP who did not attend the meeting" gives it almost everything.
A few structural decisions make the biggest difference in practice.
- Role framing tells the model what kind of expert is answering. "You are an experienced employment lawyer" shifts tone and vocabulary without any further instruction.
- Output format prevents guessing. If you want a numbered list, ask for one. If you want plain prose, say so.
- Negative constraints cut noise. "Do not include a preamble" or "avoid bullet points" saves editing time.
These elements combine differently depending on the job. The full range of prompting techniques covers more advanced arrangements, including chain-of-thought and few-shot patterns, for when a single well-formed prompt is not enough.
Worked examples
Each example below shows a before prompt, a revised prompt, and what the revision actually changes. The model outputs are marked [NEEDS REAL OUTPUT] and must be filled before publication.
Before
Write a summary of our Q3 results.[NEEDS REAL OUTPUT]
After
You are a financial analyst writing for a board audience. Summarize the following Q3 results in four bullet points, each under 20 words. Focus on revenue, margin, headcount, and the single biggest risk. Tone: direct, no jargon.
[PASTE DATA HERE][NEEDS REAL OUTPUT]
What changed: The revised prompt specifies the audience, the format, the exact topics to cover, and the tone. The model no longer guesses what "summary" means in this context.
Before
Help me write a job description for a marketing manager.[NEEDS REAL OUTPUT]
After
Write a job description for a mid-level marketing manager at a 50-person B2B SaaS company. Include: role overview (2 sentences), 5 responsibilities, 4 required skills, and one paragraph on team culture. Avoid buzzwords like "rockstar" or "ninja".[NEEDS REAL OUTPUT]
What changed: Constraints on company size, seniority, and structure give the model enough context to skip generic filler.
Before
Reply to this customer complaint.[NEEDS REAL OUTPUT]
After
You are a customer support lead. Reply to the complaint below. Acknowledge the issue in one sentence, explain what caused it in plain language, and state the resolution. Keep the total reply under 100 words. Do not offer a discount.[NEEDS REAL OUTPUT]
What changed: Adding a word limit, a specific constraint ("no discount"), and a three-part structure stops the model from producing a vague apology that leaves the customer no clearer on next steps.
When to use it and when not to
Prompt engineering pays off most when you have a task you repeat often, or where the stakes of a bad output are high enough that a few minutes of setup is worth it. Writing a weekly status summary, drafting customer responses, or generating first-pass job descriptions all fit this profile. The task is predictable enough that a well-structured prompt gives consistent results every time.
It also helps when you're handing a task to someone else. A new team member with a solid prompt will outperform a veteran working from vague instructions. The prompt carries the context that would otherwise live only in someone's head.
There are cases where it's the wrong tool, though. If the task itself is poorly defined, no amount of prompt refinement will fix it. A prompt can't substitute for a decision about what you actually want. Similarly, prompt engineering doesn't help much with genuinely novel or open-ended research where the value is in unexpected directions, not reliable repetition.
It's also not a solution for tasks that require verified, real-time information. Models have knowledge cutoffs and will confidently produce outdated or incorrect facts if you push them into territory where accuracy depends on current data. In those cases, point the model at a source rather than asking it to recall.
How do prompt engineering examples compare with related techniques?
Prompt engineering is a broad field, and examples-based prompting sits alongside several other approaches. Knowing where the lines are helps you pick the right tool.
| Technique | How it works | Best for | Limitation |
|---|---|---|---|
| Examples-based (few-shot) | You include sample inputs and outputs in the prompt | Tasks with a clear format you want replicated | Longer prompts, higher token cost |
| Zero-shot prompting | No examples, just a clear instruction | Simple, well-defined tasks | Output format is harder to control |
| System prompts | Instructions set before the conversation begins | Defining persona, tone, and rules for a whole session | Requires access to system prompt field; not always available |
| Chain-of-thought | You ask the model to reason step by step | Complex reasoning, math, multi-step decisions | Verbose output; slower for high-volume tasks |
The practical difference between few-shot prompting and zero-shot prompting is mostly about format control. If you just need an answer, zero-shot is fine. If you need the answer in a specific structure, a few examples will get you there faster than a long instruction block.
System prompts and few-shot examples often work well together. A system prompt sets the overall context and voice; the examples inside the conversation show exactly what output format you expect.
Chain-of-thought is the odd one out. It is not really about format at all. It is about making the model show its reasoning, which matters most when accuracy on a complex problem is more important than speed or brevity.
Common mistakes
The most common one is vagueness. A prompt like "write me a summary" gives the model nothing to work with: no length, no audience, no tone, no source material. The output will be generic because the input was. Specificity is almost always free, and adding two or three concrete constraints tends to improve results more than any clever technique.
The second mistake is front-loading instructions with context the model does not need. A 400-word preamble explaining your company history before asking for a subject line wastes the context window and can actually dilute what the model prioritizes. Put the most important instruction close to where the model will act on it, usually near the end of the prompt.
Iterating without keeping records is another quiet failure mode. Someone writes a prompt that works well, adjusts it slightly the next day, and within a week has no idea what the original said. If you cannot reproduce a good result, you cannot teach it to anyone else.
Finally, people assume a prompt that works in one model will work identically in another. It often does, roughly. But Claude and GPT-4 weight instructions differently, and a prompt tuned tightly for one can produce noticeably weaker output on the other. Test across models before treating anything as a team standard.
Using this across a team
Solo prompt engineering is relatively straightforward: you iterate, find what works, and reuse it. The harder problem is consistency when five or ten people are running similar tasks through different AI tools and writing prompts from scratch each time.
The output variation is real. Two team members asking the same question in different ways will get meaningfully different answers, and neither will know the other got something better.
The practical fix is a shared prompt library. Treat your best-performing prompts the way you treat a style guide or a document template: write them down, give them a home, and make sure the team can find them without asking around. When someone improves a prompt, update the shared version rather than keeping the better one in a personal folder.
A few things that make shared prompts actually stick in practice: name each prompt clearly so people can find it without opening it, note which model or models it was tested on, and flag any prompt that requires editing before use (placeholders like [CLIENT NAME] or [PRODUCT CATEGORY] should be obvious, not buried).
Prompt templates built for teams solve the storage and distribution problem. Getting the team to agree on which prompts belong there is the human work that no tool does for you.
Frequently asked questions
What is prompt engineering in simple terms?
Prompt engineering is the practice of writing instructions for an AI model carefully enough that you get consistently useful output. Think of it as the difference between asking a new colleague "write something about our product" and giving them a proper brief with context, audience, format, and goal.
Do I need to know how to code to do prompt engineering?
No. Prompt engineering requires clear thinking and decent writing, not programming knowledge. The techniques on this page, role assignment, format instructions, worked examples in the prompt itself, are all plain text. A content writer or project manager can apply them just as effectively as a developer.
Does prompt engineering work the same way across ChatGPT, Claude, Copilot, and Gemini?
The core principles transfer across all four, but each model has tendencies worth knowing. Claude tends to follow detailed formatting instructions closely. ChatGPT responds well to explicit role and tone guidance. Results from the same prompt can differ in length, structure, and emphasis, so test on the model your team actually uses.
How long should a well-engineered prompt be?
Long enough to remove ambiguity, short enough to stay readable. Most working prompts land between 50 and 200 words. Adding a worked example often does more than adding another paragraph of explanation.
When should I use a pre-built prompt template instead of writing my own?
Use a template when the task recurs often enough that inconsistent phrasing creates inconsistent results. Writing your own from scratch makes sense for one-off or highly specialized requests where no template will fit cleanly.
Further reading
The resources below go deeper on the techniques mentioned throughout this page. Each covers a specific aspect of prompting rather than trying to explain everything at once.
On the broader method
Prompting techniques: a practical guide covers the full range of approaches, from basic instruction-writing through to chain-of-thought and role-based prompting. A good place to start if you want to understand where worked examples sit relative to everything else.
On specific techniques referenced here
Zero-shot prompting explains what happens when you give a model no examples at all, and when that is actually the right call. Reading it alongside this page clarifies why few-shot prompting sometimes outperforms it, and sometimes does not.
System prompts covers how to set persistent instructions that shape model behavior across a whole conversation, not just a single turn. Useful if you want the tone and format work you did in your examples to carry forward automatically.
On saving and reusing what works
Prompt templates for teams is the Convergence product page. If you have refined a prompt through the worked-example process and want colleagues to use it consistently, this is where to look.
External reference
The OpenAI prompt engineering guide is worth reading for its discussion of tactics like few-shot prompting and chain-of-thought. It is written for developers but the underlying principles apply to any user.