Lesson 3 of 49 min
Prompting and context
A prompt is a brief for a capable colleague who knows nothing about your situation. Learn the parts of a good one and how to give the model the context it needs.
In this lesson
- Structure a prompt with task, context, constraints and format
- Use examples and system instructions effectively
- Provide relevant context instead of relying on the model's memory
Write a brief, not a wish#
The model cannot read your mind or see your screen. It knows only what is in the prompt (and what it learned in training). Compare:
Vague
"Write something about our new feature."
Specific
"Write a 3-sentence announcement of dark mode for our note-taking app's changelog. Audience: existing users. Tone: friendly, no hype. Mention that it follows the setting they choose in the app, not the device."
The second prompt says what to produce, for whom, how long, in what tone, and the one fact that matters.
The parts of a good prompt#
| Part | Question it answers | Example |
|---|---|---|
| Task | What should be produced? | "Summarise this support ticket" |
| Context | What does the model need to know? | The ticket text, the product name |
| Constraints | What are the limits? | "Under 80 words, no promises about dates" |
| Format | What shape should the answer take? | "A bullet list" or "JSON with these fields" |
| Examples | What does good look like? | One or two sample inputs and outputs |
You rarely need all five. Start with task and context, and add the rest when the output misses.
Building prompts in code#
When an app sends prompts, build them from parts so they stay consistent and easy to review.
type SummaryRequest = { ticket: string; product: string; maxWords: number };function summaryPrompt({ ticket, product, maxWords }: SummaryRequest): string { return [ `You summarise customer support tickets for the ${product} team.`, `Write at most ${maxWords} words as a bullet list.`, "Include the customer's problem, what they already tried, and what they are asking for.", "If the ticket does not say something, write 'not stated' instead of guessing.",1 "", "<ticket>",2 ticket, "</ticket>", ].join("\n");}console.log(summaryPrompt({ ticket: "App crashes when I export a PDF.", product: "Notes", maxWords: 60 }));Telling the model what to do when information is missing reduces made-up details.
Clear delimiters separate your instructions from the user's text, which helps the model and makes it harder for the ticket's content to be mistaken for instructions.
System instructions and messages#
Chat-style APIs accept a list of messages with roles. A system message (some providers call it instructions) sets standing behaviour: who the assistant is, rules it must follow, the output format. User messages carry each request. Put stable rules in the system message and the changing input in user messages.
Examples beat adjectives#
"Write in a concise, friendly tone" means different things to different readers. One short example of the output you want is usually clearer than a paragraph of adjectives. Keep examples varied enough that the model copies the pattern, not the specific words.
Give it the facts#
Models do not know your product, your codebase or anything after their training cutoff. When accuracy matters, put the relevant facts in the prompt: the policy text, the function you want explained, the records to summarise. Supplying retrieved documents this way is called grounding; the next module covers doing it automatically with embeddings.
Iterate like a writer
Treat the first prompt as a draft. Run it on several real inputs, look at what goes wrong, and change one thing at a time. Keep a small set of test inputs so you can tell whether a change helped.
Long detailed prompts or short ones?
Detail helps when the task has rules the model would not guess. But every instruction costs tokens and can conflict with others. Include what changes the output; cut what does not.
ExerciseImprove a prompt
Rewrite this prompt so the output is useful for a busy manager: "Tell me about this bug report."
Show solution
One good version: "Summarise the bug report below for an engineering manager in three bullets: impact on users, likely area of the code, and suggested priority (low, medium or high) with one reason. If impact is not stated, say so.", followed by the report wrapped in <report> tags. It names the audience, the format, the decision the reader needs to make and how to handle missing information.
Recap#
- Prompts are briefs: task, context, constraints, format, and sometimes examples.
- Put standing rules in system instructions and inputs in user messages, with clear delimiters.
- Ground answers in facts you provide, and iterate against real inputs.