Prompting that works — instructions, examples, and structure
Use practical prompting patterns: clear role, constraints, examples, and output shape.
Sign in to track progress on this lesson.
01 — Main lesson
Full walk-through. · 7.0 MB
Spoken script — useful when names or terms sound ambiguous.
Welcome back. This is lesson six in the series, and today we are getting practical. Last time we talked about hallucinations and grounding, and I said that a good prompt is not a magic shield against a model making things up. That is still true. But prompting does matter. A lot. The way you instruct a model shapes what you get back, and there are reliable patterns that make your results dramatically better. So today we are walking through prompting that actually works. Not tricks, not incantations, just clear engineering.
Let me start with the most important shift in how you should think about a prompt. A prompt is not a question. It is a brief. You are writing a specification for a task. If you handed this task to a capable colleague who had no context, what would you tell them? You would not just say, write me a summary. You would say who the summary is for, how long it should be, what to focus on, what format you want, and what to do if something is unclear. The model deserves the same respect. It does not read your mind. It responds to what is on the page.
So the first pattern is this. State the goal, the audience, the constraints, and the desired format. All four. Not just the goal. Let me give you a concrete example. A weak prompt says, summarise this meeting transcript. A better prompt says, you are summarising a forty-five minute product team meeting transcript for an engineering manager who could not attend. Produce a summary of no more than two hundred words. Focus on decisions made and action items with owners. Use bullet points. If an action item has no clear owner, say so explicitly rather than guessing. Do you see the difference? The second version tells the model exactly what good looks like. It removes ambiguity. And ambiguity is where models drift.
Now, about format. Be explicit. If you want bullet points, say bullet points. If you want a table, say table. If you want a specific structure, like a heading followed by three short paragraphs, describe that structure. Models are surprisingly obedient about format when you are specific, and surprisingly creative in ways you did not want when you are vague. If you say make it look nice, you have given the model permission to invent. If you say use a numbered list with one sentence per item, you have removed that permission.
The second pattern is few-shot examples. This is a technical term for something very simple. Instead of only describing what you want in abstract words, show the model one or two concrete examples of the input and the output you expect. Often, examples beat instructions. Let me illustrate. Suppose you want the model to classify customer feedback into categories. You could write a long paragraph explaining what counts as a billing issue versus a usability issue versus a feature request. That might work. But it is much more reliable to show three examples. Input, a customer complaint about being charged twice. Output, billing. Input, a customer saying the checkout button does not work on mobile. Output, usability. Input, a customer asking for a dark mode option. Output, feature request. Then give the real input you want classified. The model sees the pattern from the examples and follows it. This is called few-shot prompting because you are giving a few shots, a few examples, before the real task. The beauty of it is that examples communicate things that are hard to say in words. They show the model the shape of your expectation. They pin down edge cases. They reduce the space of acceptable outputs.
A practical tip on examples. Use examples that are realistic but different from each other. If all your examples are easy and obvious, the model might not learn the distinction you actually care about. Include a tricky one. If you want the model to say I do not know when there is not enough information, include an example where the correct output is exactly that. Show the model that not knowing is an acceptable, even desirable, answer. We will come back to that.
The third pattern is decomposition. When a task is hard, break it into steps the model can follow. This is where chain-of-thought comes in, which I mentioned at the end of last time. The idea is simple. A model that is asked to go straight from question to final answer has less room to work through reasoning. A model that is asked to show its steps, or that is told to think step by step, has more surface area to get the reasoning right. Think about it this way. If I ask you to multiply forty-seven by thirty-three in your head and just give me the answer, you might guess. If I ask you to write out the steps, you will probably get it right because you can see each part. Models are similar. Asking for reasoning steps, or explicitly instructing the model to think through the problem before answering, improves performance on tasks that require multiple steps of logic.
Now, I want to be careful here, because last lesson we established that fluency is not truth. Chain-of-thought does not make the model truthful. What it does is give you something to inspect. When the model writes out its reasoning, you can read it and check whether each step is sound. If the model makes a leap that is wrong, you can see it. If it goes straight to an answer, you cannot. So chain-of-thought is not just about better answers. It is about auditable answers. It gives you the working, not just the result. That matters when the stakes are non-trivial.
Some newer models support what is called extended thinking, where the model does internal reasoning before producing its visible response. You do not always see that reasoning, but the model is still decomposing the problem internally. The principle is the same. Decomposition helps. Whether you force it to be visible or the model does it internally, breaking a hard task into steps is better than demanding a single leap from question to answer.
The fourth pattern is asking for uncertainty. This is directly connected to last lesson. You want the model to tell you when it does not know, rather than confidently inventing. You can build this into the prompt explicitly. Say something like, if the information provided is not sufficient to answer, say I do not have enough information to answer this. Do not speculate. Or, if you are not confident in an answer, say so and explain what is uncertain. This sounds obvious, but many people never ask for it. They assume the model will volunteer its uncertainty. It often will not, unless instructed. Models are trained to be helpful and to produce fluent continuation. The default behaviour is to give you something. If you want the model to sometimes give you nothing, you have to tell it that nothing is an acceptable answer. And as I said earlier, the best way to teach this is with an example. Show the model a case where the input is ambiguous and the correct output is, I cannot determine this from the information given. That teaches the behaviour far more reliably than a sentence of instruction alone.
The fifth pattern, and this is the one that separates people who use models well from people who do not, is iteration. Treat prompting as debugging, not one-shot magic. Your first prompt will often be imperfect. You will get output that is close but not right. The temptation is to accept it or to give up. The right move is to look at the output, figure out what instruction was missing or ambiguous, revise the prompt, and try again. This is normal. It is not a sign that you are bad at this. It is the process. You would not write a function, run it once, see a bug, and conclude that programming does not work. You debug. Prompting is the same. Look at the output. Ask yourself, what did I fail to specify? Did I leave the format open? Did I not give an example of the tricky case? Did I not tell the model what to do when it was unsure? Fix the prompt. Run it again. Usually two or three iterations get you to a reliable result.
One more thing on iteration. When you find a prompt that works well for a task you do repeatedly, save it. Keep a small library of prompts that you have tested and refined. This is not glamorous, but it is how professionals get consistent results. You are building a set of tested specifications for tasks you actually need. Reuse them. Adapt them. Do not start from scratch every time.
Let me now give you a reusable prompt skeleton for a work task. This is a spoken template, so listen for the structure. You can adapt it to anything. It goes like this. You are a role, for example, you are a technical writer. Your task is to do something specific, for example, convert a rough meeting note into a structured handover document. The audience is someone specific, for example, an incoming engineer who was not at the meeting. Here are the constraints. Maximum length, required sections, tone. Here is the input material, pasted or referenced. If the input does not contain enough information for any section, write not enough information provided for that section. Do not invent. Here are two examples of the kind of output I want. Example one. Example two. Now produce the output for the input I have provided. That is the skeleton. Role, task, audience, constraints, input, instruction on uncertainty, examples, and then the real input. You fill in each part. You iterate. You keep what works.
Let me recap the five patterns before we wind down. First, treat the prompt as a brief. State the goal, audience, constraints, and format. Second, use few-shot examples. Show the model what good looks like rather than only describing it. Third, decompose hard tasks into steps. Use chain-of-thought or step-by-step instructions, and remember that visible reasoning gives you something to audit. Fourth, ask for uncertainty. Tell the model it is acceptable, even desirable, to say it does not know. Back that up with an example. Fifth, iterate. Prompting is debugging. Revise, test, and save what works.
One last thought. None of this makes the model truthful. We covered that last time and it has not changed. What good prompting does is narrow the space of outputs, reduce ambiguity, and give you more control over the shape and quality of the result. It is engineering, not magic. The model is still a next-token predictor. You are just giving it a much better specification of what you want it to predict. That is the whole game. On the next walk, we will look at tools and function calling, which is how models can reach outside their own weights to fetch real data, run calculations, and take actions. That is a big step beyond text generation, and it connects directly to grounding. But that is for next time. For now, walk on. Prompt like you are writing a brief, not casting a spell. Iterate like a debugger. And keep your examples concrete.
Let me start with the most important shift in how you should think about a prompt. A prompt is not a question. It is a brief. You are writing a specification for a task. If you handed this task to a capable colleague who had no context, what would you tell them? You would not just say, write me a summary. You would say who the summary is for, how long it should be, what to focus on, what format you want, and what to do if something is unclear. The model deserves the same respect. It does not read your mind. It responds to what is on the page.
So the first pattern is this. State the goal, the audience, the constraints, and the desired format. All four. Not just the goal. Let me give you a concrete example. A weak prompt says, summarise this meeting transcript. A better prompt says, you are summarising a forty-five minute product team meeting transcript for an engineering manager who could not attend. Produce a summary of no more than two hundred words. Focus on decisions made and action items with owners. Use bullet points. If an action item has no clear owner, say so explicitly rather than guessing. Do you see the difference? The second version tells the model exactly what good looks like. It removes ambiguity. And ambiguity is where models drift.
Now, about format. Be explicit. If you want bullet points, say bullet points. If you want a table, say table. If you want a specific structure, like a heading followed by three short paragraphs, describe that structure. Models are surprisingly obedient about format when you are specific, and surprisingly creative in ways you did not want when you are vague. If you say make it look nice, you have given the model permission to invent. If you say use a numbered list with one sentence per item, you have removed that permission.
The second pattern is few-shot examples. This is a technical term for something very simple. Instead of only describing what you want in abstract words, show the model one or two concrete examples of the input and the output you expect. Often, examples beat instructions. Let me illustrate. Suppose you want the model to classify customer feedback into categories. You could write a long paragraph explaining what counts as a billing issue versus a usability issue versus a feature request. That might work. But it is much more reliable to show three examples. Input, a customer complaint about being charged twice. Output, billing. Input, a customer saying the checkout button does not work on mobile. Output, usability. Input, a customer asking for a dark mode option. Output, feature request. Then give the real input you want classified. The model sees the pattern from the examples and follows it. This is called few-shot prompting because you are giving a few shots, a few examples, before the real task. The beauty of it is that examples communicate things that are hard to say in words. They show the model the shape of your expectation. They pin down edge cases. They reduce the space of acceptable outputs.
A practical tip on examples. Use examples that are realistic but different from each other. If all your examples are easy and obvious, the model might not learn the distinction you actually care about. Include a tricky one. If you want the model to say I do not know when there is not enough information, include an example where the correct output is exactly that. Show the model that not knowing is an acceptable, even desirable, answer. We will come back to that.
The third pattern is decomposition. When a task is hard, break it into steps the model can follow. This is where chain-of-thought comes in, which I mentioned at the end of last time. The idea is simple. A model that is asked to go straight from question to final answer has less room to work through reasoning. A model that is asked to show its steps, or that is told to think step by step, has more surface area to get the reasoning right. Think about it this way. If I ask you to multiply forty-seven by thirty-three in your head and just give me the answer, you might guess. If I ask you to write out the steps, you will probably get it right because you can see each part. Models are similar. Asking for reasoning steps, or explicitly instructing the model to think through the problem before answering, improves performance on tasks that require multiple steps of logic.
Now, I want to be careful here, because last lesson we established that fluency is not truth. Chain-of-thought does not make the model truthful. What it does is give you something to inspect. When the model writes out its reasoning, you can read it and check whether each step is sound. If the model makes a leap that is wrong, you can see it. If it goes straight to an answer, you cannot. So chain-of-thought is not just about better answers. It is about auditable answers. It gives you the working, not just the result. That matters when the stakes are non-trivial.
Some newer models support what is called extended thinking, where the model does internal reasoning before producing its visible response. You do not always see that reasoning, but the model is still decomposing the problem internally. The principle is the same. Decomposition helps. Whether you force it to be visible or the model does it internally, breaking a hard task into steps is better than demanding a single leap from question to answer.
The fourth pattern is asking for uncertainty. This is directly connected to last lesson. You want the model to tell you when it does not know, rather than confidently inventing. You can build this into the prompt explicitly. Say something like, if the information provided is not sufficient to answer, say I do not have enough information to answer this. Do not speculate. Or, if you are not confident in an answer, say so and explain what is uncertain. This sounds obvious, but many people never ask for it. They assume the model will volunteer its uncertainty. It often will not, unless instructed. Models are trained to be helpful and to produce fluent continuation. The default behaviour is to give you something. If you want the model to sometimes give you nothing, you have to tell it that nothing is an acceptable answer. And as I said earlier, the best way to teach this is with an example. Show the model a case where the input is ambiguous and the correct output is, I cannot determine this from the information given. That teaches the behaviour far more reliably than a sentence of instruction alone.
The fifth pattern, and this is the one that separates people who use models well from people who do not, is iteration. Treat prompting as debugging, not one-shot magic. Your first prompt will often be imperfect. You will get output that is close but not right. The temptation is to accept it or to give up. The right move is to look at the output, figure out what instruction was missing or ambiguous, revise the prompt, and try again. This is normal. It is not a sign that you are bad at this. It is the process. You would not write a function, run it once, see a bug, and conclude that programming does not work. You debug. Prompting is the same. Look at the output. Ask yourself, what did I fail to specify? Did I leave the format open? Did I not give an example of the tricky case? Did I not tell the model what to do when it was unsure? Fix the prompt. Run it again. Usually two or three iterations get you to a reliable result.
One more thing on iteration. When you find a prompt that works well for a task you do repeatedly, save it. Keep a small library of prompts that you have tested and refined. This is not glamorous, but it is how professionals get consistent results. You are building a set of tested specifications for tasks you actually need. Reuse them. Adapt them. Do not start from scratch every time.
Let me now give you a reusable prompt skeleton for a work task. This is a spoken template, so listen for the structure. You can adapt it to anything. It goes like this. You are a role, for example, you are a technical writer. Your task is to do something specific, for example, convert a rough meeting note into a structured handover document. The audience is someone specific, for example, an incoming engineer who was not at the meeting. Here are the constraints. Maximum length, required sections, tone. Here is the input material, pasted or referenced. If the input does not contain enough information for any section, write not enough information provided for that section. Do not invent. Here are two examples of the kind of output I want. Example one. Example two. Now produce the output for the input I have provided. That is the skeleton. Role, task, audience, constraints, input, instruction on uncertainty, examples, and then the real input. You fill in each part. You iterate. You keep what works.
Let me recap the five patterns before we wind down. First, treat the prompt as a brief. State the goal, audience, constraints, and format. Second, use few-shot examples. Show the model what good looks like rather than only describing it. Third, decompose hard tasks into steps. Use chain-of-thought or step-by-step instructions, and remember that visible reasoning gives you something to audit. Fourth, ask for uncertainty. Tell the model it is acceptable, even desirable, to say it does not know. Back that up with an example. Fifth, iterate. Prompting is debugging. Revise, test, and save what works.
One last thought. None of this makes the model truthful. We covered that last time and it has not changed. What good prompting does is narrow the space of outputs, reduce ambiguity, and give you more control over the shape and quality of the result. It is engineering, not magic. The model is still a next-token predictor. You are just giving it a much better specification of what you want it to predict. That is the whole game. On the next walk, we will look at tools and function calling, which is how models can reach outside their own weights to fetch real data, run calculations, and take actions. That is a big step beyond text generation, and it connects directly to grounding. But that is for next time. For now, walk on. Prompt like you are writing a brief, not casting a spell. Iterate like a debugger. And keep your examples concrete.
02 — Refresh
Short recap. · 834 KB
Spoken script — useful when names or terms sound ambiguous.
Quick recap of lesson six. Treat a prompt as a brief, not a question. State the goal, the audience, the constraints, and the desired format. All four. Vague prompts give the model permission to invent, and you do not want that. Few-shot examples often beat abstract instructions. Show the model one or two concrete examples of the input and output you expect. Examples communicate things that are hard to say in words, and they pin down edge cases. Decompose hard tasks into steps. Ask the model to think step by step, or to show its reasoning. Chain-of-thought does not make the model truthful, but it gives you auditable reasoning you can inspect. Ask for uncertainty. Tell the model explicitly that saying I do not have enough information is an acceptable answer. Back that up with an example where the correct output is exactly that. Iterate. Prompting is debugging, not one-shot magic. Look at the output, find what was missing or ambiguous, revise, and try again. Save prompts that work. Your reusable skeleton is role, task, audience, constraints, input, instruction on uncertainty, examples, then the real input. Fill in each part and refine. Good prompting narrows the space of outputs and gives you control. It is engineering, not magic.