Prompt Engineering Guide with Examples: How to Get Reliable Answers from ChatGPT, Claude and Gemini

Prompt engineering is the practice of writing instructions that get consistent, useful output from a language model. The short version: tell the model who it's helping and why, give it the context it can't guess, state the task precisely, show an example of a good answer, and specify the output format. Then test the prompt on several real inputs before you trust it. Those five habits fix most bad AI answers, whether you use ChatGPT, Claude, Gemini or Copilot.

I'm Gulab Chand Tejwani, a Microsoft Certified Trainer at TechNet Consultancy in Anand. I teach prompting in our generative AI course to developers, analysts and project managers, and I use it daily in our own software work. The examples below come from that kind of everyday work rather than party tricks.

Why do vague prompts give bad answers?

A model only knows what's in its training data and what you put in the prompt. It doesn't know your audience, your company, your deadline or what "good" looks like to you. When you leave gaps, it fills them with the most generic, average answer. That's not laziness; it's the most likely text given what it was told.

So most prompt engineering is just removing guesswork.

What are the parts of a good prompt?

I teach a simple checklist. Not every prompt needs all of it, but when an answer disappoints, one of these is usually missing:

1. Role and audience: who the model is acting as and who will read the result.
2. Context: background facts, data or documents the model needs.
3. Task: one clear instruction with a verb. "Summarise", "classify", "rewrite", "list".
4. Constraints: length, tone, what to avoid, what to do if information is missing.
5. Format: bullet list, table-like list, JSON, email, a fixed template.
6. Examples: one or more samples of the output you want.

The official guides from Anthropic, OpenAI and Google all recommend versions of the same ideas. That agreement is useful: these techniques transfer between models.

Example 1: From a vague request to a usable email

Weak prompt:

Write an email about the project delay.

You'll get a polite, generic email that fits no real situation.

Better prompt:

You are helping a project manager write to a client.

Context:
- Project: inventory web app for a distributor in Anand
- The go-live date of 14 November will move to 28 November
- Reason: the client's stock data arrived 10 days late
- We will deliver the reporting module early, on 14 November, as planned

Task: Write a short email to the client's operations head.
Constraints: under 150 words, factual and calm, no blame, no apology
more than once. End with a clear next step: a 20-minute call this week.
Format: subject line, then the email body.

Now the model has the facts, the tone and the length. The second version takes a minute longer to write and saves ten minutes of editing.

Example 2: Few-shot prompting for consistent classification

When you need the same kind of output every time, show examples. This is called few-shot prompting.

Classify each customer message into one category:
Billing, Technical, Course enquiry, Other.
Reply with the category only.

Message: "I was charged twice for the PMP mock exam."
Category: Billing

Message: "My Power BI Desktop won't open the .pbix file from class."
Category: Technical

Message: "Is the next Blazor batch online or in Anand?"
Category: Course enquiry

Message: "The video stops after five minutes on my phone."
Category:

Three examples are often enough. Pick examples that cover the tricky cases, not just the obvious ones. If "Technical" and "Billing" get confused, include a borderline example of each.

Example 3: Asking for structured output (JSON)

If code will read the answer, ask for a fixed structure. Most model APIs now support structured outputs, where you pass a JSON schema and the API enforces it. Even without that, a clear format instruction helps:

Extract the following from the support email below and return only JSON:
{
  "customer_name": string,
  "product": string,
  "issue_summary": string (max 20 words),
  "urgency": "low" | "medium" | "high"
}
If a field is not mentioned, use null. Do not guess.

Email:
"""
Hi, this is Riya from Shah Traders. Our Blazor billing portal shows a
blank page since this morning and we can't raise invoices. Please help ASAP.
"""

The line "If a field is not mentioned, use null. Do not guess." matters more than it looks. Giving the model permission to say "unknown" is one of the best ways to reduce made-up answers.

Example 4: Letting the model reason before answering

For problems with several steps, such as calculations, planning or debugging, ask the model to work through the problem before giving a final answer. This is often called chain-of-thought prompting.

A 40-hour course runs 2 hours per session, 3 sessions per week,
starting Monday 2 November. Public holidays: none.
Work out the date of the final session. Show your reasoning step
by step, then give the date on its own line.

Newer "reasoning" models do much of this internally, so you may not need to ask. It still helps to request the steps when you want to check the logic yourself. And always check arithmetic and dates; models still slip.

Example 5: Grounding answers in a document

Hallucination drops sharply when you give the model the source and tell it to stick to it:

Answer the question using only the policy text between the tags.
If the answer isn't in the text, say "The policy doesn't cover this."
Quote the sentence you relied on.

<policy>
...paste the leave policy here...
</policy>

Question: Can I carry unused leave into next year?

Wrapping sources in tags or clear delimiters helps the model tell instructions apart from content. This idea, scaled up with a search step, is exactly what retrieval-augmented generation does. I explain it in how to build a RAG chatbot over your documents.

Example 6: Prompting for code

Developers get better code when they give the same specifics they'd give a colleague:

I'm using .NET 10 with ASP.NET Core minimal APIs and EF Core 10.
Write a GET endpoint /api/courses/{id} that returns a CourseDto
(Id, Title, DurationHours) or 404 if not found.
Use AsNoTracking. Don't use AutoMapper. Keep it in Program.cs style.

Naming the framework version stops the model mixing old and new APIs. Then read and run the code. Generated code can compile and still be wrong, and you're the one responsible for it. For the real thing, see our ASP.NET Core Web API tutorial.

Example 7: Chaining prompts instead of one giant prompt

When a task has distinct stages, run them as separate prompts and check the output between steps. Here's a chain I use for turning a long meeting transcript into a client update:

Step 1 (extract)
From the transcript below, list every decision, open question and
action item. For action items include owner and due date if stated.
Return three bullet lists. Do not summarise anything else.

Step 2 (check)
Here are the extracted items and the transcript. Mark any item that
isn't clearly supported by the transcript as UNSURE.

Step 3 (write)
Using only the items not marked UNSURE, write a client update email
under 200 words. Audience: the client's project sponsor. Tone: clear,
factual, positive where honest.

Each step is easy to check, and an error in step 1 doesn't silently flow into a polished email. The same idea is how most AI features in real software are built: several small, testable calls instead of one clever one.

Example 8: Asking the model to critique your work

Models are useful reviewers when you tell them what to look for:

You are reviewing a Power BI DAX measure written by a junior analyst.
Check it for: wrong filter context, division by zero, and hard-coded
values. For each problem, quote the line, explain it in one sentence
and suggest a fix. If you find no problems, say so. Don't rewrite
anything that is already correct.

Measure:
Margin % = DIVIDE(SUM(Sales[Profit]), SUM(Sales[Revenue]))

"Don't rewrite anything that is already correct" stops the model changing working code just to look helpful.

Which prompting technique should you use when?

Technique	Use it when	Example from this guide
Clear instructions + context	Always; it's the baseline	Example 1: project delay email
Few-shot examples	You need the same format or labels every time	Example 2: message classification
Structured output (JSON)	Code will read the answer	Example 3: support email extraction
Step-by-step reasoning	Maths, dates, planning, debugging	Example 4: course end date
Grounding in a source	Facts must come from a document	Example 5: leave policy
Prompt chaining	The task has distinct stages	Example 7: transcript to email

How do you test whether a prompt is good?

This is where most people stop too early. A prompt that works once may fail on the next input. A simple process:

1. Collect 10 to 20 real inputs, including awkward ones.
2. Write down what a correct output looks like for each.
3. Run the prompt on all of them and mark pass or fail.
4. Change one thing at a time and re-run.
5. Keep the winning prompt in a shared document or in code, with a version note.

In our Generative AI course we turn this into a small evaluation script, because once a prompt powers a feature, you need to know when a model update breaks it.

Three prompt templates you can reuse today

Copy these into a notes file and fill the brackets. They cover a lot of everyday work.

For summaries (anyone):

Summarise the text below for [audience] who needs to [decision or action].
Use at most [n] bullet points. Start with the single most important point.
If the text doesn't say something, don't guess.
"""[text]"""

For analysts:

Here is a table of [data description] as CSV. Describe the three most
notable patterns and one possible data quality issue. For each pattern,
state which columns and rows support it. Don't calculate anything you
can't show from the data.
[csv]

For developers:

Stack: [language, framework and version]. Constraints: [libraries allowed
or banned, style]. Task: [what the code must do], including how it should
handle [edge cases]. Return the code, then a list of assumptions you made.

What prompt mistakes should you avoid?

• Stacking five tasks in one prompt. Split them into steps.
• Negative-only instructions. "Don't be wordy" works less well than "Use at most three sentences."
• Pasting confidential data into public tools. Follow your company's AI policy. Business versions of these tools usually have different data terms from free consumer versions; check them.
• Trusting facts, numbers and citations without checking. Models can invent references that look real.
• Treating prompts as magic words. There's no secret phrase. Clear thinking produces clear prompts.

Is prompt engineering still a useful skill in 2026?

Yes, though it has changed. Models are better at understanding plain requests, so tricks matter less. Clear specification, good examples, grounding in sources and systematic testing matter more, because more work now runs through AI features in real products. Those skills are the bridge from "I use ChatGPT" to "I build reliable AI workflows."

For a full learning path, read Generative AI course for beginners 2026. Project managers and analysts will also like AI tools for project managers and analysts.

FAQ

What is prompt engineering in simple words?

It's writing clear instructions for an AI model, with the context, examples and format it needs, so you get useful and consistent answers instead of generic ones.

Do prompts work the same in ChatGPT, Claude and Gemini?

Mostly. The core techniques (context, clear task, examples, format, grounding) work across all major models. Details differ, so test important prompts on the model you'll actually use.

Is prompt engineering a real job?

It's rarely a standalone job title now. It's a skill inside other roles: developers building AI features, analysts, content teams, support teams and project managers. Employers value people who can combine it with domain knowledge.

How long does it take to learn prompt engineering?

You can learn the basics in a few days and get noticeably better within two weeks of daily use. Testing and evaluating prompts for production features takes longer and is part of our generative AI course.

Can I learn prompt engineering without coding?

Yes. Everything in this guide works in a chat window. Coding becomes useful when you want to automate prompts, test them at scale or build them into applications.