Chapter 1 · Prompt Foundations
What a Prompt Really Is: Goal, Audience, Context and Deliverable
- Page 1 of 24
- 19 min read
Nadia in Dhaka types "write something about our new return policy" into a chat assistant and gets three generic paragraphs she cannot use. Her colleague Mateo in Bogotá asks for the same thing in five lines, and gets a notice he can send after one small edit. Same assistant, same minute. The difference is not luck and it is not a secret phrase. Mateo told the model what he needed, who would read it, what facts it had to use and what the finished piece should look like.
That is what this tutorial teaches. A prompt is the input you give a model: your text, and sometimes files or images. Prompt engineering is the everyday skill of turning a real need into that input, running it, checking the result and improving the input. It is a craft you learn by trying, comparing and checking, and it transfers from one assistant to another. This first page gives you the base: what a prompt is, what it is not, and the four things to decide before you write one.
What you will learn
- What prompt engineering means in everyday work, and how a prompt differs from a conversation and from saved instructions.
- How a question differs from a task specification, and when each is the right choice.
- How to decide the goal, the audience and intended use, and the context a model needs before you write.
- How to replace vague words with requirements you can observe, and how to set length, tone and a clear deliverable.
How to use this tutorial
The tutorial has 24 pages in five chapters. Each page ends with exercises and a pointer to the next page.
- Prompt Foundations (pages 1 to 6): goal, audience, context, structure, constraints, delimiters, examples, roles, and how to split, critique and revise.
- Everyday Work (pages 7 to 10): writing and editing, professional communication, summarising, extracting, classifying and checking.
- Languages, Learning and Data (pages 11 to 16): prompting in your own language, translation, studying, research and source checking, spreadsheets, reports.
- Beyond Text and Trustworthy Use (pages 17 to 22): images, documents and audio, debugging a weak output, a personal prompt library, reliable and private use, and untrusted text.
- Practice and Capstone (pages 23 and 24): a practice lab, then a capstone, a cheat sheet and ideas for what to learn next.
What you need. Any chat assistant you can open for free, in a browser or an app. A plain notes file (a text document is enough) where you will build a prompt library. No code and no installation. When an exercise needs a feature your app may not have, such as uploading a file, the page says "if your app supports it".
An honest note about examples. We cannot show you live output from every assistant, and replies differ between products, versions and even between two runs of the same prompt. So every reply printed in this tutorial is an illustrative example written for teaching. It is labelled each time, and it is never the output of a named product. All names, orders, invoices and numbers are invented. Your own reply will be different, and that is expected. Do not use real private data while practising.
How to practise. For each prompt: (1) copy it into your assistant, (2) run it, (3) compare your reply with the example and with the checklist on the page, (4) check the facts, numbers and format yourself, and (5) save the prompt and what you learned in your notes file. Treat every reply as a draft that you must check.
When you finish, the Prompt Engineering for AI: Advanced tutorial follows. It adds systematic testing, structured outputs and Python, and it assumes you can already do what this tutorial teaches.
What prompt engineering means in everyday work
Think of a capable new colleague who knows a lot in general but nothing about your job, your customers or what you did yesterday. If you say "deal with the Okafor order", you will get a guess. If you say who is affected, what happened, what you want back and by when, you will get something useful. A model behaves much the same way. It does not know your situation unless the prompt (or the earlier conversation) tells it.
In practice, prompt engineering is a short loop:
1. DECIDE what you need, for whom, and how you will know it is good
2. WRITE a prompt that states those things
3. RUN the prompt in your assistant
4. CHECK the reply against what you decided in step 1 (facts, numbers, format)
5. IMPROVE change the prompt, not just the reply, and run again
6. KEEP save the prompt and notes if it worked
People use this loop for emails, summaries, study notes, spreadsheet formulas, customer replies, meeting notes and many other tasks. Developers use the same loop to write the instructions inside an AI feature.
What is stable and what is not. Stable across assistants: models respond better to clear goals, relevant context and a described output than to vague wishes, and every output needs checking. Model-specific: how long a reply is by default, how literally a model follows an instruction, and which extra features your app offers. So learn the habits, not "the perfect prompt", and re-test when you change assistant. Wording tricks such as secret phrases do not replace clear requirements, and nothing in this tutorial guarantees a correct answer. It makes a useful, checkable answer more likely.
Prompt, conversation and saved instructions
Three different things can shape what the model does, and beginners often mix them up.
| Term | What it is | What to remember |
|---|---|---|
| Prompt | The message you send now: your instructions and any text you paste. | It is the part you control most directly. |
| Conversation | All the messages so far in one chat. The model reads the earlier ones as context for the next reply. | It helps follow-up requests ("make it shorter"). It also carries earlier mistakes and old instructions. The model can only consider a limited amount of text at once (see How AI Works: LLMs, Tokens and Limitations for the context window), so very long chats can drift. |
| Saved instructions | Standing text that the app adds to your chats for you, for example your preferred language or tone. Apps call this by different names, and not every app or plan has it. | Check where your app keeps it. Keep it short and general. Never put passwords or private data in it. |
A useful habit: when a reply surprises you, ask "what text did the model actually see?" It saw the saved instructions (if any), the earlier messages in this chat, and your latest prompt, and nothing else. It did not see your other chats, your files on your computer, or what you meant but did not write. For a new, unrelated task, start a new chat so old context does not leak in.
A question is not a task specification
"How do I tell a customer their order is late?" is a question. You will probably get an explanation: be honest, apologise, give a new date. That is fine when you want to learn. But if you wanted the email itself, you asked for the wrong thing.
A task specification asks for a piece of work and describes it well enough that you can tell whether the result is right. Compare:
| Question | Task specification | |
|---|---|---|
| Example | How do I tell a customer their order is late? | Write the email that tells a customer their order is late, with the new date, in under 110 words. |
| You get | Advice and general tips | The thing itself, in a form you can use |
| You can check it by | Judging whether the advice sounds sensible | Testing it against the requirements you wrote |
| Use it when | You want to understand or decide | You want a finished piece of work |
Both are legitimate. The skill is noticing which one you need, and not asking a question when you want a deliverable.
Four things to decide before you write
Before typing, spend one minute on four decisions. Write them in your notes if the task matters. The prompt is then mostly a matter of stating them in order.
1. The goal
The goal is what the output must achieve in the real world, not just its topic. "Something about the return policy" is a topic. "Make customers understand that returns are accepted for 30 days and how to start one" is a goal. A goal has a verb and a result. Ask yourself: if the reply were perfect, what would change for the reader or for me?
2. The audience and intended use
Say who will read it and what they will do with it. A summary for a busy manager who must decide today differs from a summary for a student who will study it. The intended use also sets the form: something read on a phone screen, printed on a notice, spoken aloud in a meeting or pasted into a spreadsheet. Give the reader's relevant background ("no finance training", "has used our product for two years"), not their life story.
3. The context the model actually needs
The model does not know your facts. Give it the context it needs and nothing it does not: the situation, the facts it must use (names, dates, amounts), the facts it must not invent, and any limit such as "we do not offer refunds". More is not better. A pasted wall of unrelated text can hide the important part. A simple test: if a human helper would ask you "which one?" or "what happened?", the answer belongs in the prompt. And if a fact is missing, say what to do about it: "if something is not given, write [MISSING] instead of guessing".
4. The deliverable
The deliverable is the concrete thing you want back: "one email with a subject line", "a table with three columns", "five bullet points", "a checklist of 8 items", "two options, labelled A and B". Name it, and say what to leave out ("no introduction, no explanation after the email"). A clear deliverable makes the reply easy to use and easy to check.
Replace vague words with requirements you can observe
Words like "short", "professional", "simple", "good" and "soon" feel clear to you because you know what you mean. The model has to guess, and so does a colleague. A requirement is observable when someone else could look at the reply and say yes or no.
| Vague wish | Observable requirement |
|---|---|
| Make it short | Between 80 and 110 words, in two short paragraphs |
| Make it professional | Formal but friendly, no slang, no exclamation marks, address the reader as "Mr Okafor" |
| Make it simple | For a reader with no technical background: short sentences, no jargon, explain any term you must use |
| Make it good | States the new date in the first two sentences, says sorry once, ends with one clear next step |
| Send it soon | Ready to send today; mention that the parcel arrives on 14 October |
Length
Say how long the output should be, in the unit the reader cares about: words, sentences, paragraphs, bullet points, lines, or "fits on one phone screen". A range ("80 to 110 words") is easier to follow than a single number. Models are not exact counters, so treat the number as a target and count the words yourself when it matters. If you do not specify length, you get the model's default, which may be far longer or shorter than you need.
Tone and formality
Tone is how the message sounds: warm, neutral, firm, apologetic. Formality is how formal the language is. Names for tone mean different things to different people and cultures, so back the label with cues the model can follow: the greeting, whether to use a title, sentence length, contractions, exclamation marks. The same news at three levels:
| Level | Example |
|---|---|
| Casual | Hi Chidi, quick heads-up: your order is a few days late. Sorry about that. |
| Neutral | Hello Mr Okafor, your order will arrive six days later than planned. We apologise for this. |
| Formal | Dear Mr Okafor, we regret to inform you that your order will be delivered on 14 October. |
Choose the level from the audience and the intended use, then state it in the prompt, ideally with one or two cues.
Weak prompt to better prompt
Priya in Pune runs a small online shop that sells handmade notebooks. A courier delayed a customer's parcel, and she wants an apology email. First attempt:
Weak prompt:
Write an email about the delay.
The model does not know whose delay, what product, how long, who the reader is, what you can offer or how long the email should be. It will invent details or write something generic. Now the same need with the four decisions, plus length and tone:
Better prompt:
Write a customer email for my online shop, Pine Leaf Notebooks.
Goal: apologise for a late order and give the new delivery date.
Reader: Mr Okafor, a first-time customer who has not complained yet.
Context: order #4821 (two A5 notebooks) was due on 8 October. The courier lost a
day at its sorting centre. The new delivery date is 14 October. We offer no
refund or discount. Use only the facts in this prompt; do not add promises.
Tone: polite and warm, plain words, no slang, no exclamation marks.
Deliverable: one email with a subject line and a body of 80 to 110 words.
End with the name Priya and the shop name.
What changed:
| Decision | Where it appears in the better prompt |
|---|---|
| Goal | "apologise for a late order and give the new delivery date" |
| Audience and use | "Mr Okafor, a first-time customer who has not complained yet"; an email to send |
| Context | order number, product, due date, cause, new date, what is not offered |
| Observable requirements | "no slang, no exclamation marks", "use only the facts in this prompt" |
| Length | "80 to 110 words" |
| Deliverable | "one email with a subject line", signed Priya |
Here is a reply of the kind a model might give:
Example reply (illustrative; yours will differ):
Subject: Your notebook order will arrive on 14 October
Dear Mr Okafor,
Thank you for your first order with Pine Leaf Notebooks. I am sorry that your
two A5 notebooks (order #4821) did not arrive on 8 October as planned. The
courier lost a day at its sorting centre, so the new delivery date is 14 October.
We will send you a tracking message as soon as the parcel is out for delivery.
We value your trust in a small shop, and we want your first experience with us
to be a good one. Please reply to this email if you have any questions.
Kind regards,
Priya
Pine Leaf Notebooks
What to notice and verify. The reply is well formed and uses the facts you gave. But check it like a reviewer: the subject line, the order number and both dates match your data. The sentence "We will send you a tracking message" is a promise that Priya never gave. A typical failure pattern is that a model adds a friendly but invented commitment, even after "do not add promises". Count the body: this one is within the range. Delete or confirm the promise before sending, because you are the one who will be held to it. Then improve the prompt if it keeps happening (the next page shows how).
Where this shows up at work
- Customer support: a team shares one good reply prompt so that every agent writes with the same tone and the same checked facts.
- Teaching and study: a teacher asks for a quiz with a stated level, length and answer key. A student asks for a summary with the three points that will be tested.
- Office and analysis work: managers ask for meeting notes in a fixed layout. Analysts ask for a short plain-language explanation of a table for a non-expert audience.
- Building AI features: a developer's system prompt is the same skill written once and run thousands of times. You already met prompt and model version tracking in Git, APIs and Backend for AI: Advanced. A prompt you can state clearly is a prompt you can version and test.
Common mistakes
- Treating the prompt like a search query. A few keywords return generic text. Fix: write a task with a goal, a reader and a deliverable, as you would brief a colleague.
- Relying on vague adjectives. "Short, professional, simple" mean different things to different readers. Fix: replace each with a number, a cue or a yes/no test.
- Assuming the model knows your situation. It does not remember your other chats, your company or last week's email. Fix: put the facts it needs in the prompt, and say what to do when a fact is missing.
- Pasting everything. A long dump of unrelated text buries what matters. Fix: include only the context a helper would need to do this task.
- Accepting the first reply as final. Fluent text can contain invented facts, wrong numbers or a promise you did not make. Fix: check every fact against your own data and fix the prompt if the problem repeats.
Try it yourself
Prompt:
Write a notice for the staff room of our school. It tells teachers that the printer
on floor 2 is broken until Friday. Keep it under 50 words. Friendly, but clear.
Use the prompt above for the Easy task.
- Easy. Read the prompt above and label each part as goal, audience and use, context, length, tone or deliverable. Then name one thing that is missing.
- Medium. Rewrite each vague request so that someone else could check the reply with yes or no. Invent any small facts you need and write them into the prompt. (a) "Give me a short summary of this report." (b) "Write a professional message to my landlord about the leak." (c) "Explain interest rates simply."
- Hard. In your assistant, run the weak prompt from this page ("Write an email about the delay.") and then the better prompt. Compare the two replies against these checks: the facts match the prompt; nothing is invented; the word count is in range; the tone has no slang or exclamation marks; the email names the new date. Write the result in your notes file with the date, the prompt and one change you would make. Finally, look for one detail the model added that is not in your prompt. How AI Works: LLMs, Tokens and Limitations explained why models can invent details that sound right.
Answers
Easy. Deliverable: a notice. Audience and use: teachers, posted in the staff room (stated by "for the staff room" and "tells teachers"). Context: printer on floor 2 is broken until Friday. Length: under 50 words. Tone: "friendly, but clear". Goal: is only implied (staff must know not to use the printer). Missing: the goal is not stated as a result, there is no action for the reader (where to print instead), no contact person, and "until Friday" has no date. A strong answer names at least two of these. Pass checklist: you found all six parts; you named a missing item that would change the notice.
Medium. A strong set of answers:
Better prompt:
(a) Summarise the report below for a manager who must decide today. Give 5 bullet
points of at most 20 words each, then one line starting "Decision needed:".
(b) Write a message to my landlord, Ms Haddad, reporting a water leak under the
kitchen sink since Monday. Formal and polite, no blame. Ask her to send a plumber
by Thursday. 90 to 120 words, plain text.
(c) Explain what an interest rate is to a teenager with no finance knowledge.
Use one everyday example with small numbers, 120 words at most, no jargon.
Pass checklist for any answer you wrote: each prompt states a reader; each has a number or a clear test for length; "professional" and "simple" were replaced by cues; facts the model needs are written in the prompt; the deliverable is named.
Hard. Your replies will differ from ours, so look for patterns. The weak-prompt reply will usually be generic and may use placeholders or invented details. The better-prompt reply should name the new date and the order. Pass checklist: you ran both prompts; you checked all five points above and wrote down a yes or no for each; you found and wrote down any invented fact or promise (or noted that you checked and found none); you saved the better prompt in your notes file with one improvement idea. If your word count was out of range, that is a normal finding: note it and ask for a rewrite within the range.
Summary
- A prompt is the input you give a model. Prompt engineering is the loop of deciding, writing, running, checking and improving it.
- A prompt is one message, a conversation is everything said so far, and saved instructions are standing text your app may add. The model sees only what is in those three places.
- A question gets advice. A task specification gets the thing itself. Pick the one that matches what you need.
- Before writing, decide the goal, the audience and intended use, the context the model needs and the deliverable.
- Replace vague words with observable requirements, and state length and tone with numbers and cues. Then check every reply as a draft.
Next: Clarify, Iterate, Improve: From a Vague Request to a Specific Prompt, where you learn to separate essential requirements from preferences, let the model ask what is missing, and improve one prompt step by step.