KnowledgeInSight
AI Literacy
0% of Course 2 complete

Module 2 · Lesson 1

Working Methods: Prompts and context

You'll learn what a model needs from you in order to do a task well, and why. You'll be able to turn a vague request into a prompt that states the goal, supplies the background, sets the limits, and shows an example.

What you will be able to do

  • Write a prompt that gives a model the goal, context, constraints, and examples it needs.

0% of this lesson · 9 items · 1h 3m total · 48m without the optional activity

Contents of this lesson9 items
  1. ReadingSame Assistant, Different Results: What Changes Between a Weak Prompt and a Strong One3 min
  2. ReadingWhat a Model Needs to Be Told: Goal, Audience, Constraints, and Format4 min
  3. ReadingSupplying Context: Documents, Background, and What the Model Can't Know4 min
  4. ReadingExamples in a Prompt: Showing the Pattern You Want4 min
  5. ReadingIteration: Reading the Output, Diagnosing the Gap, and Revising the Prompt4 min
  6. Guided ReadingGuided Walkthrough: Revising a Vague Prompt in Four Passes7 min
  7. Guided ConversationImprove a Prompt You Use12 min
  8. Hands-on Activity · optionalRewrite One Prompt and Compare the Results15 min
  9. Knowledge CheckPrompts and context10 min

Reading 3 min

Same Assistant, Different Results: What Changes Between a Weak Prompt and a Strong One

Two colleagues use the same AI assistant to write the same kind of update for a client. One gets a draft she can send after a few edits. The other gets four paragraphs of polite filler and decides the tool isn't much use. Both used the same model on the same day.

A popular explanation is that some people know the tricks: a special opening line, a role to assign, a phrase that unlocks better answers. The guides that AI developers publish for their own products point to something plainer. Anthropic, Google, and OpenAI each maintain a guide to writing prompts, and all three put the weight on what the model is told. Google's guide calls "clear and specific instructions" an effective way to shape a model's behavior (Google 2026a, "Clear and specific instructions"). OpenAI's guide tells writers to give the model any additional information it might need to produce a response (OpenAI n.d.-a, "Message formatting with Markdown and XML").

Anthropic's guide makes the same point with a comparison. It asks the writer to think of the model as "a brilliant but new employee who lacks context on your norms and workflows" (Anthropic n.d., "Be clear and direct"). A new employee can be capable and still know nothing about your client, your project, or what happened last week.

The same guide offers a test. Show your prompt to a colleague who knows little about the task, and ask them to follow it. If the colleague would be confused, the guide says, the model will be too (Anthropic n.d., "Be clear and direct").

Try the test on a prompt like "Write an update for the client about the project." A colleague handed that sentence would have questions before writing a word:

  • Which client, and which project?
  • What has happened since the last update?
  • What does the client most want to know?
  • How long should it be, and how formal?
  • Is there anything that shouldn't be said yet?

A colleague would ask. A model usually doesn't. It fills each gap with the most ordinary guess available, and the result is an update that could be about any project for any client.

These three guides are written by companies describing their own products, mostly for software developers, and each company gains when its customers get good results. They're advice from the makers, and they aren't independent tests. Their agreement on this point is still worth noting, since the three compete with one another.

The test gives you a way to read a disappointing answer. A weak answer has two possible explanations: the model can't do the task well, or it wasn't told enough to do it. The second is common, and it's cheap to check. Before you conclude that a tool is no good at something, look at your prompt and ask what a capable stranger would have needed to know.

A fuller prompt makes the output fit your situation. The output still has to be checked.

References

  • Anthropic. n.d. "Prompting Best Practices." Claude Developer Platform documentation. Accessed October 3, 2026.
  • Google. 2026a. "Prompt Design Strategies." Gemini API documentation. Last updated September 17, 2026.
  • OpenAI. n.d.-a. "Prompt Engineering." OpenAI API documentation. Accessed October 3, 2026.

Report an issue with this item

Reading 4 min

What a Model Needs to Be Told: Goal, Audience, Constraints, and Format

This content reflects the field as of October 2026.

Introduction

A request that would be perfectly clear to a coworker often gets a bland answer from an AI assistant. The coworker knows your situation, and the model doesn't.

This reading explains what a model has to work with, the four things a request should state, and why giving the reason for an instruction helps. Citations give the section heading of each developer's guide.

What the Model Starts With

A prompt is the text you give a model to tell it what you want. When a conversation begins, the model has two things to draw on: what it absorbed in training, and what's in the conversation. Training gave it general knowledge of language and the world. It gave it nothing about your job, your reader, or this morning's meeting.

Some products store preferences or details from past chats and add them to new conversations. That helps only as far as the stored details bear on the task in front of you.

Anything else the model needs has to be in the prompt. Where the prompt is silent, the model fills the gap with a typical answer, which is why vague requests produce generic results.

Four Things to State

An instruction is a statement in a prompt that tells the model what to do or how to do it. Most weak prompts contain one instruction and nothing else. Four additions do most of the work.

  • The goal is what the result is for: the purpose it has to serve. A summary written to help someone decide differs from one written for the record.
  • The audience is who will read the result and what they already know.
  • A constraint is a limit the result has to stay within, such as a length, a tone, or something that must be left out.
  • The output format is the form the result should take, such as a short email, a table, or a bulleted list.

The table shows one request with each element added in turn. The example is invented.

ElementWhat the request says
Instruction onlySummarize the attached report.
Goal addedThe summary will help our department heads decide on Thursday whether to renew the software contract.
Audience addedThey haven't read the report, and they aren't specialists in the software.
Constraints addedKeep it under 200 words. Use only what's in the report. Don't recommend a decision.
Format addedGive three bullet points on what the report found, then one sentence on what remains uncertain.

The first row could produce almost any summary. The full prompt leaves far fewer choices to chance, and every added sentence is something a new colleague would have had to ask.

Saying Why

An instruction works better when it comes with its reason. Anthropic's guide gives an example. A bare order never to use ellipses is less effective than one that explains the response will be read aloud by a text-to-speech engine, which can't pronounce them (Anthropic n.d., "Add context to improve performance").

The reason lets the model handle cases the instruction didn't list. A model that knows the text will be read aloud can also avoid tables and symbols, which the bare order never mentioned. The same is true of a person. "Keep it short" gets a different result from "keep it short, because she'll read it on her phone between meetings."

Where the Developers Agree

Three developers' guides give matching advice on this point. Google's calls "clear and specific instructions" an effective way to customize a model's behavior and tells writers to state any constraints and the format they want (Google 2026a, "Clear and specific instructions"). OpenAI's describes instructions as guidance on "how to generate the response you want," including what the model should and shouldn't do (OpenAI n.d.-a, "Message formatting with Markdown and XML"). Anthropic's advises being specific about the desired output (Anthropic n.d., "Be clear and direct").

Each guide is a company's account of its own models, written mainly for people building software. None is an independent study. Agreement among competitors suggests the advice is general, and it will hold only as long as models keep working from what they're told.

Conclusion

A model starts each task with its training and the conversation, and nothing else about your situation. A prompt that states the goal, the audience, the constraints, and the output format supplies what a new colleague would ask for, and a reason attached to an instruction helps the model apply it to cases you didn't list. The developers of several widely used models give this advice about their own products as of October 2026.

Key Terms

  • Prompt: The text you give a model to tell it what you want.
  • Instruction: A statement in a prompt that tells the model what to do or how to do it.
  • Goal: What the result is for: the purpose it has to serve.
  • Constraint: A limit the result has to stay within, such as a length, a tone, or something that must be left out.
  • Output format: The form the result should take, such as a short email, a table, or a bulleted list.

References

  • Anthropic. n.d. "Prompting Best Practices." Claude Developer Platform documentation. Accessed October 3, 2026.
  • Google. 2026a. "Prompt Design Strategies." Gemini API documentation. Last updated September 17, 2026.
  • OpenAI. n.d.-a. "Prompt Engineering." OpenAI API documentation. Accessed October 3, 2026.

Report an issue with this item

Reading 4 min

Supplying Context: Documents, Background, and What the Model Can't Know

This content reflects the field as of October 2026.

Introduction

Ask an AI assistant about your organization's leave policy and it will describe a leave policy. Whether it describes yours depends on whether you gave it the policy.

This reading covers what counts as context, what happens with too little or too much of it, how to keep it apart from your instructions, and what supplying it does and doesn't settle. Citations give the section heading of each developer's guide.

What Counts as Context

Context is the information you supply alongside your request so the model can work from your situation. It comes in two main kinds.

Source material is the documents, notes, or data the task is about: the report to be summarized, the policy to be explained, the survey results to be sorted.

Background is facts about the situation that aren't in any document, such as who is involved and what has already been decided. It also includes what your terms mean. If "the pilot" in your office refers to one particular trial program, the model has no way to know that.

Three developers' guides advise supplying this information directly. Google's tells writers to include what the model needs "instead of assuming that the model has all of the required information" (Google 2026a, "Add context"). OpenAI's lists data outside the model's training, such as private or proprietary material, as a main reason to add context (OpenAI n.d.-a, "Message formatting with Markdown and XML"). Anthropic's describes the model as lacking context on "your norms and workflows" (Anthropic n.d., "Be clear and direct"). Each company is describing its own product.

Working from Your Facts

Grounding means having a model work from material you supply instead of from the general patterns of its training. The difference shows in the output. Without the leave policy, a model writes what leave policies usually say. With it, the model can report what yours says.

Before you paste a document into an AI tool, confirm that you're allowed to share it there. Confidential, personal, and student information usually can't be shared, and the same task can often be done with those details removed.

Too Little and Too Much

Too little context gives generic output. The model has only the typical case to draw on, so it writes for the typical case.

Too much can also hurt. A model given forty pages when two are relevant has to find the two, and details from the other thirty-eight can drift into the answer. Anthropic's guide suggests, for long documents, asking the model to pick out the relevant passages before it starts the task, to help it set the rest aside (Anthropic n.d., "Long context prompting").

What you supplyWhat tends to happen
No material, no backgroundA generic answer built from typical cases
The relevant material and the background a newcomer would needAn answer about your situation
Everything you have, relevant or notAn answer that may pull in details that don't belong

The useful question is which material a capable newcomer would need for this task.

Keeping Instructions and Material Apart

A model reads your instructions and your documents as one stream of text. If they run together, it can mistake a sentence in a document for something you asked for, or treat your request as part of the document.

The developers' guides all recommend marking the boundary. OpenAI's says that tags can show "where one piece of content" begins and ends (OpenAI n.d.-a, "Message formatting with Markdown and XML"). Anthropic's says that separating instructions, context, and examples "reduces misinterpretation" (Anthropic n.d., "Structure prompts with XML tags"). Google's advises giving a large document first and the question after it (Google 2026a).

Those guides describe tags meant for software developers. A plain label does the same job in a chat. You can write "The meeting notes are between the two lines below," paste them between two rows of dashes, and put your request after the second row.

What Supplied Context Doesn't Settle

A model can misread what it's given. It can skip a clause, merge two items, or state something the document doesn't say. Supplying the source doesn't remove the need to check.

It does change the size of the job. With no source, you'd have to check the answer against the world. With a source supplied, you check the answer against that source, which you have open in front of you.

Conclusion

Context is the source material and background that let a model work from your facts. Developers' guidance from Anthropic, Google, and OpenAI, as of October 2026, agrees on including what the model needs, marking it off from the instructions, and not assuming the model already has it. Supplied context narrows the checking to a comparison with your own documents, and that comparison still has to be done.

Key Terms

  • Context: The information you supply alongside your request so the model can work from your situation.
  • Source material: The documents, notes, or data the task is about.
  • Background: Facts about the situation that aren't in any document, such as who is involved and what has already been decided.
  • Grounding: Having a model work from material you supply instead of from the general patterns of its training.

References

  • Anthropic. n.d. "Prompting Best Practices." Claude Developer Platform documentation. Accessed October 3, 2026.
  • Google. 2026a. "Prompt Design Strategies." Gemini API documentation. Last updated September 17, 2026.
  • OpenAI. n.d.-a. "Prompt Engineering." OpenAI API documentation. Accessed October 3, 2026.

Report an issue with this item

Reading 4 min

Examples in a Prompt: Showing the Pattern You Want

This content reflects the field as of October 2026.

Introduction

Describing the writing you want is harder than it sounds. "Friendly but professional, fairly short, not too formal" means something different to everyone who reads it, and a model has to guess as well.

This reading explains what an example adds to a prompt, what developers advise about using examples, how examples can backfire, and what to do when you have none. Citations give the section heading of each developer's guide.

What an Example Carries

An example, in a prompt, is a sample of the output you want. It carries information that instructions tend to miss.

  • Tone. How warm or how formal the writing is.
  • Length. How much is enough.
  • Structure. What comes first, and how the piece ends.
  • Level of detail. What gets a full sentence and what gets left out.

You could try to describe all four. One past email that you liked shows them at once, with less room for misreading. A pattern is what a set of examples has in common, such as tone, length, or structure, and the pattern is what you want the model to take from them.

What the Developers Advise

Including examples in a prompt has a technical name. Few-shot prompting means including a few examples in a prompt to show the model what you want. A prompt with no examples is called zero-shot.

Three developers recommend the practice for their own models. Google's guide says, "We recommend to always include few-shot examples in your prompts" (Google 2026a, "Zero-shot vs few-shot prompts"). Anthropic's calls examples "one of the most reliable ways" to steer format, tone, and structure, and suggests three to five (Anthropic n.d., "Use examples effectively"). OpenAI's describes steering a model with "a handful" of sample inputs and outputs (OpenAI n.d.-a, "Few-shot learning").

These are the companies' statements about their own products. They aren't independent tests, and the best number of examples can differ from task to task. Google's guide says you may need to experiment with the number.

The Risk of Over-Copying

A model pays close attention to an example, and it can't tell which features you meant it to follow. Over-copying is a model's reuse of an example's particular details, such as its phrases or facts, where only its general pattern was wanted.

Suppose your one example email opens with "Hope you had a restful weekend" and mentions a Tuesday deadline. The new output may open with the same greeting on a Thursday, or carry over the Tuesday deadline when the real one is different. The example's quirks came along with its strengths.

Both Google and Anthropic warn about this. Google's guide says that with too many examples a model may fit its response too closely to them (Google 2026a, "Optimal number of examples"). Anthropic's says examples should vary enough that the model doesn't "pick up unintended patterns" (Anthropic n.d., "Use examples effectively").

Varying the Examples

Variety is the remedy the guides give. OpenAI's advises showing "a diverse range of possible inputs with the desired outputs" (OpenAI n.d.-a, "Few-shot learning").

Two or three examples that differ in their details and share the features you care about tell the model what matters. If all three are short, start with the key date, and close with one clear request, while their topics and greetings differ, the shared features stand out as the pattern. A feature that appears in every example will be treated as part of the pattern, so check what your examples have in common by accident.

It also helps to say what the example is for. "Match the length and tone of this email, and don't reuse its details" removes much of the guesswork.

Examples from your own past work can contain names and private details. Remove them or replace them with invented ones before the example goes into a prompt.

When You Have No Example

Sometimes nothing you've written fits. Two approaches work without one.

  1. Describe the pattern directly: the length, the tone, the order of the parts, and what to leave out.
  2. Run the prompt, then correct the first output. Tell the model what to change, such as "shorter, and put the deadline in the first line."

Once an output is right, it can serve as the example the next time the task comes up.

Conclusion

An example shows a model the tone, length, structure, and level of detail you want, often more reliably than a description does. Guidance from Anthropic, Google, and OpenAI as of October 2026 recommends including examples and varying them. The main risk is over-copying, which varied examples and a plain statement of what to match both reduce.

Key Terms

  • Example: A sample of the output you want, included in a prompt.
  • Pattern: What a set of examples has in common, such as tone, length, or structure.
  • Few-shot prompting: Including a few examples in a prompt to show the model what you want.
  • Over-copying: A model's reuse of an example's particular details, such as its phrases or facts, where only its general pattern was wanted.

References

  • Anthropic. n.d. "Prompting Best Practices." Claude Developer Platform documentation. Accessed October 3, 2026.
  • Google. 2026a. "Prompt Design Strategies." Gemini API documentation. Last updated September 17, 2026.
  • OpenAI. n.d.-a. "Prompt Engineering." OpenAI API documentation. Accessed October 3, 2026.

Report an issue with this item

Reading 4 min

Iteration: Reading the Output, Diagnosing the Gap, and Revising the Prompt

Introduction

Most people respond to a disappointing AI answer in one of two ways. They ask again in slightly different words, or they give up on the task. A third response is more useful: treat the answer as information about the prompt.

This reading covers how to read an output for what the prompt left out, when to rewrite the prompt and when to reply in the conversation, how to keep a prompt that works, and when to stop.

Reading the Output for What's Missing

Iteration is improving a prompt in rounds, where each output shows what to change. Developers expect it. Google's prompting guide says prompt design can "require a few iterations" before the responses are consistently what you want (Google 2026a, "Prompt iteration strategies").

The step that makes a round useful is diagnosis: working out what a prompt left out by looking at what is wrong with the output. Begin by naming the fault as exactly as you can. Then ask what the model wasn't told. Four gaps account for most faults.

What's wrong with the outputLikely gapWhat to add
It answers a different question, or serves the wrong purposeMissing goalWhat the result is for and who will read it
It's generic, or gets your facts wrongMissing contextThe document, the facts, the background
It's too long, the wrong tone, or says something it shouldn'tMissing constraintThe limit, stated plainly
The content is right and the style or shape is offMissing exampleA sample of what you want

One check for any of these comes from Anthropic's prompting guide. Show the prompt to a colleague who knows little about the task, and see whether they could follow it (Anthropic n.d., "Be clear and direct"). Whatever they'd ask about is a candidate for the gap.

Revising the Prompt or Replying in the Conversation

A revision is a change to a prompt made to supply what the diagnosis found missing. You can make it in two places.

Reply in the conversation when the output is close and the fix is small: "Cut this to 100 words" or "The deadline is the 7th, not the 9th." The model keeps the draft and changes what you named. This is quick, and it suits a task you'll do once.

Rewrite the prompt and start a new conversation when the output missed the point, or when you'll do the task again. A long thread of corrections is hard to reuse, and early wrong turns stay in the conversation where they can keep influencing later replies. A rewritten prompt carries everything in one place.

AI output varies from one run to the next, so one better answer after a revision is weak evidence. Running the revised prompt a second time in a new conversation shows whether the improvement holds.

Keeping a Prompt That Works

A reusable prompt is a prompt you save because it works for a task you do repeatedly. A weekly status update, a standard reply to a common question, and a summary of meeting notes are typical candidates.

Save the prompt as text somewhere you control, with a blank marked for the part that changes each time. Leave out anything confidential. A saved prompt is worth rereading now and then, since the tool you run it on will change and your own needs may too.

When to Stop

Sometimes a prompt has the goal, the context, the constraints, and an example, and the output is still wrong in the same way. More revision may not help. The task may be outside what the model does well.

A field experiment with 758 consultants, a study in which real workers were randomly assigned to work with or without AI, found exactly this kind of boundary. On most of the study's tasks, AI improved the consultants' work. On one task chosen to be beyond the model's ability, about 84 percent of consultants without AI reached the correct answer, against 60 to 71 percent of those with it. That task didn't look harder than the others (Dell'Acqua et al. 2026). No amount of careful wording moves a task across that boundary.

A practical rule is to stop after two or three rounds in which you supplied what was missing and the same fault came back. At that point, do the failing part yourself, or split the task and give the model only the part it handles.

Conclusion

A first prompt is a draft, and each output shows what it left out. Diagnosis matches the fault to a missing goal, missing context, a missing constraint, or a missing example, and the revision supplies it, either in the conversation or in a rewritten prompt. Repeated failure after the gaps are filled points to a limit of the model.

Key Terms

  • Iteration: Improving a prompt in rounds, where each output shows what to change.
  • Diagnosis: Working out what a prompt left out by looking at what is wrong with the output.
  • Revision: A change to a prompt made to supply what the diagnosis found missing.
  • Reusable prompt: A prompt you save because it works for a task you do repeatedly.

References

  • Anthropic. n.d. "Prompting Best Practices." Claude Developer Platform documentation. Accessed October 3, 2026.
  • Dell'Acqua, Fabrizio, Edward McFowland III, Ethan Mollick, Hila Lifshitz, Katherine C. Kellogg, Saran Rajendran, Lisa Krayer, François Candelon, and Karim R. Lakhani. 2026. "Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of Artificial Intelligence on Knowledge Worker Productivity and Quality." Organization Science 37 (2): 403–423.
  • Google. 2026a. "Prompt Design Strategies." Gemini API documentation. Last updated September 17, 2026.

Report an issue with this item

Guided Reading 7 min

Guided Walkthrough: Revising a Vague Prompt in Four Passes

Introduction

A one-line request to an AI assistant usually returns something that looks finished and says little. The usual fix is to supply the information the first version left out.

This walkthrough follows one prompt through four revisions and a final correction. The teacher, the trip, and every output are invented for the exercise. The outputs are described and excerpted, and they don't come from any real product.

The Starting Point

Ms. Rivera teaches fifth grade. Her class is going to a science museum, and she needs every family to return a signed permission form. She types this into an AI assistant:

Write an email to parents about the field trip.

The assistant returns about 220 words. The email opens, "I am excited to announce an upcoming field trip that promises to be both educational and fun!" It contains placeholders in square brackets for the date, the place, and the cost. It closes by inviting parents to reach out with any questions.

Nothing in it is about her trip. The model had no facts, so it wrote the email that fits every field trip.

Walking Through the Revision

Step 1: Add the goal and the audience

Ms. Rivera asks herself what the email is for. She doesn't need parents to be excited. She needs the forms back on time. She also thinks about who's reading: busy parents and guardians, many of them on a phone.

She adds two sentences: "I teach fifth grade. The purpose is to get every signed permission form back by the deadline."

The new output mentions the form in the second sentence and ends with a request to return it. The model now knows what the email has to accomplish, and it arranged the email around that. The placeholders are still there, because the facts are still missing.

Step 2: Add the facts

She lists what a parent needs to know. The trip is on Thursday, May 14. The bus leaves school at 8:30 a.m. and returns by 2:45 p.m. The cost is $12 per student. Students need a packed lunch and a water bottle. The form and payment are due Thursday, May 7.

With these in the prompt, the placeholders disappear. The email is now about her trip. This is the pass that changes the output most, and it matches the developers' advice to include the information a model needs instead of assuming it has it (Google 2026a, "Add context").

The output has two new problems. It runs to nearly 250 words, and it includes the sentence "If you miss the deadline, just send the form when you can." She never said that. The model filled a gap with something agreeable.

Step 3: Add constraints

The invented sentence shows her which limits she left unstated. She adds four.

  • Keep the email under 150 words.
  • Use a warm, plain tone, with no exclamation marks.
  • Don't promise that late forms will be accepted.
  • Don't say the fee can be waived. Say that families can contact her privately about the cost.

The last two matter most. They concern promises that she, and not the assistant, would have to keep. The output comes back at 140 words, without the offer on late forms, and with a sentence inviting families to contact her about the cost.

It still reads like a form letter. The facts sit in one dense paragraph, and the deadline appears near the end.

Step 4: Add an example

Ms. Rivera has an email she sent in the fall about a book fair, which parents answered quickly. She pastes it in, and she says what it's for: "Here is an email I sent about a different event. Match its length, tone, and layout, and don't reuse its details."

Her old email has a subject line that includes the date, a first sentence that states the event, and a separate line that begins "What to do:". The new output picks up all three. The deadline moves into the subject line, and the action a parent must take gets its own line.

Describing that layout in words might still have been misread. Developers' guides recommend examples for this reason: Anthropic's calls them "one of the most reliable ways" to steer format, tone, and structure (Anthropic n.d., "Use examples effectively"). Her instruction not to reuse the details guards against the model copying the book fair's date or dollar amount into the new email.

Step 5: Read the output against the purpose and fix the remaining gap

She reads the result with one question in mind: could a parent act on this without asking her anything? The date, time, cost, and deadline are all there. The email says to return the form, and it doesn't say how.

That's a missing fact, and it's hers to supply. The output is otherwise right, so she replies in the conversation instead of rewriting the prompt: "Add that the form and payment go back in your child's take-home folder." The assistant adds one clause, and the email is ready for her to check against her own records and send.

She adds the same fact to her saved prompt.

Key Considerations

The common mistake in revising a prompt is to add words without adding information. A version that reads "Write a really excellent, professional, engaging, detailed email to parents about the field trip" is three times as long as the original and tells the model nothing new about the trip, the parents, or the purpose. The output would be the same generic email with more adjectives in it. Each of Ms. Rivera's passes added something the model couldn't have known.

The passes aren't equally important for every task. Here the facts did the most. For a task with a strict house style, the example might matter most.

OpenAI's guide lists the same kinds of content as the parts of a full prompt: instructions, examples, and context (OpenAI n.d.-a, "Message formatting with Markdown and XML"). Ms. Rivera added them one at a time, and with practice a person writes them all in the first draft.

A complete prompt doesn't check the output for her. The assistant could still have changed $12 to $21, so she compares every fact in the email with her own list before it goes out.

Summary

Ms. Rivera turned a one-line request into a prompt with a goal, the facts, constraints, and an example, then fixed one remaining gap in the conversation. Her final prompt follows.

I teach fifth grade. Write an email to my students' parents and guardians about our class trip to the science museum. The purpose is to get every signed permission form back by the deadline.

Facts: The trip is on Thursday, May 14. The bus leaves school at 8:30 a.m. and returns by 2:45 p.m. The cost is $12 per student. Students need a packed lunch and a water bottle. The signed form and payment are due Thursday, May 7, in the student's take-home folder.

Keep the email under 150 words. Use a warm, plain tone, with no exclamation marks. Don't promise that late forms will be accepted. Don't say the fee can be waived; say that families can contact me privately about the cost.

Here is an email I sent about a different event. Match its length, tone, and layout, and don't reuse its details.

Subject: Book fair visit on Friday, October 3 Dear families, our class will visit the school book fair on Friday, October 3. Students may bring up to $10 if you'd like them to choose a book. Nothing is required. What to do: if you're sending money, put it in a labeled envelope in the take-home folder. Thank you, Ms. Rivera

  1. Goal and audience. The first paragraph says who is writing, who will read the email, and what it has to accomplish.
  2. Context. The Facts paragraph supplies everything about the trip that the model couldn't know.
  3. Constraints. The third paragraph sets the length and tone, and names two promises the email must not make.
  4. Example. The past email shows the layout she wants, with a sentence saying what to match and what to leave behind.

References

  • Anthropic. n.d. "Prompting Best Practices." Claude Developer Platform documentation. Accessed October 3, 2026.
  • Google. 2026a. "Prompt Design Strategies." Gemini API documentation. Last updated September 17, 2026.
  • OpenAI. n.d.-a. "Prompt Engineering." OpenAI API documentation. Accessed October 3, 2026.

Report an issue with this item

Guided Conversation 12 min

Improve a Prompt You Use

In this conversation you'll take a prompt you've used and work out what it left unsaid. You'll leave with a revised prompt that states the goal, the context, the constraints, and an example, ready for you to test.

You'll have this conversation with an AI assistant, using your own account. Choose a button to open a new chat with the prompt already filled in, then press send to start. If the chat opens empty, copy the prompt and paste it in.

Run this conversation in whichever assistant you already use:

Claude desktop app

To use another LLM, simply copy and paste the prompt into its chat window.

Show the full prompt (it lists misreadings to watch for, so skip it if you would rather come to the conversation fresh)
Guided Conversation: Improve a Prompt You Use (about 12 minutes)

Note to the learner: press send to start. Everything below is facilitator guidance for the AI. It lists misconceptions to watch for, so skip it if you'd rather come to the conversation fresh.

Please facilitate a coached problem session with me. I'm an adult with no technical background who has used AI chatbots for everyday tasks, and I'm studying how to write prompts that give a model what it needs. Follow this guidance for the whole conversation.

GOAL
I can write a prompt that gives a model the goal, context, constraints, and examples it needs, starting from a prompt I already use.

HOW TO RUN THE CONVERSATION
- Ask one question at a time, then wait for my reply. Keep each of your turns under about 120 words.
- Don't lecture. Explain a point only when I need it to continue, then return to my prompt.
- Be curious and collegial. Use plain words and define any technical term briefly on first use. Welcome disagreement when I give a reason.
- This is a coached problem. The problem is: revise one prompt of mine so it has a goal, context, constraints, and an example. Ask for my own attempt at each element before you give any hint. Give one hint at a time. Don't rewrite the prompt for me before I've tried. Help me sharpen what I write.
- Plain conversation only: don't search the web or create files or documents.
- Don't ask for confidential, personal, or student information. I can paste or describe my prompt, with real names and private details removed. If I start to share any, remind me to leave them out.
- Don't carry out my prompt in this conversation. We're revising it, and I'll test it myself afterward.
- Aim for about 12 minutes. Spend most of the time on topics 2 and 3. If my replies are brief, offer one concrete prompt, such as "Think of something you asked an AI assistant to write this month," and move on. If I seem uncertain, shorten the conversation to 5-7 minutes. Always reach the final topic.
- Start now. Open with one or two warm sentences: this is a conversation, not a quiz; a prompt I'd really use matters more than a perfect one; I can ask you to clarify anything. Then ask me to paste or describe one prompt I've used recently, with nothing confidential in it, and to say what I thought of the result.

TOPICS, IN ORDER
1. My prompt. Ask what the task was and what was wrong with the output, as exactly as I can say. Follow up if my description is vague ("it was bland" - bland how?).
2. What a new colleague would ask. Ask me to picture handing my prompt to a capable colleague who knows nothing about the task. What would they need to ask before starting? Draw out questions about purpose, reader, facts, limits, and what a good result looks like. Ask me which of those questions my prompt already answers.
3. My revision, element by element. Take the four elements one at a time: goal and audience, context, constraints, example. For each, ask what I'd add before you suggest anything. For the example, ask whether I have a past piece I liked, and remind me to remove private details. If I have none, ask me to describe the pattern I want.
4. Closing. Ask me to put the pieces together and state my revised prompt in full. Tell me I can take it into a short optional activity where I run the old and new prompts and compare the results.

KEY POINTS TO KEEP ACCURATE
- Method: name what's wrong with the output, ask what the model wasn't told, then supply it. The four elements are the goal (what the result is for, and for whom), context (documents, facts, background), constraints (limits such as length, tone, what to leave out), and an example of the output wanted.
- A model has only its training and what is in the conversation. It doesn't know my situation unless I say it.
- Published guidance from several AI developers agrees on three points: be clear and specific, include the context the model needs, and show examples. This is each developer's advice about its own products, not independent testing.
- Giving the reason for an instruction helps the model apply it sensibly.
- Length isn't the aim. Each added sentence should tell the model something it couldn't have known.
- An example can be copied too closely, so I should say what to match and what not to reuse.
- If I ask how you work, explain the general mechanism in one or two sentences and say plainly that you can't inspect your own internals, so your statements about yourself are not evidence.

MISCONCEPTIONS TO CORRECT GENTLY
When one appears, name the accurate version briefly, then return to my prompt.
- "There are magic words": information matters, and phrasing tricks mostly don't.
- "Longer is better": relevant is better. Extra words that add no information don't help, and irrelevant material can distract.
- "A good prompt guarantees a correct answer": a good prompt makes the output fit my situation, and the output still needs checking.

LIMITS
- No product-specific features, settings, or interface steps. Keep the advice usable in any assistant.
- Don't recommend or compare products.
- Don't ask for or accept confidential material.
- Don't promise that my revised prompt will work. Testing it is how I'll find out.

TO FINISH
After I state my revised prompt, close in one short turn:
- Affirm one specific thing I worked out, in my own words where possible.
- Suggest one or two next steps that fit how the conversation went. Possible steps: run the old and new prompts in separate new conversations and compare the outputs; show the revised prompt to a colleague and ask what they'd still need to know; save the prompt for reuse with a blank for the part that changes; go back to one element that's still thin.
- Restate my revised prompt on its own lines, labeled "My revised prompt", so I can copy it.

Report an issue with this item

Hands-on Activity 15 minOptional

Rewrite One Prompt and Compare the Results

Overview

The quickest way to see what a prompt's contents do is to run two versions of the same request and put the outputs side by side. In this activity you'll take a prompt you've used, rewrite it with four elements, and trace each difference in the output back to what you added.

The activity is optional. Your notes are for you, and nobody collects them.

What You'll Need

  • An AI assistant you already use
  • One prompt from your own recent use, with nothing confidential in it. Remove or replace names, personal details, student information, and anything your workplace treats as private. A revised prompt of your own that you've already drafted is fine to use here.
  • Somewhere to write a few notes

Your Task

Take a prompt you've used, rewrite it with a goal, context, constraints, and an example, and compare the two outputs.

Steps

  1. Run your original prompt in a new conversation and save the output. Use the prompt as you first wrote it. Paste the output into your notes and label it "Original."
  2. Rewrite the prompt, adding each of the four elements. Say what the result is for and who will read it. Supply the facts or the document, with private details removed. State the limits, such as length, tone, and anything that must be left out. Add an example of the output you want, or a description of its pattern if you have none.
  3. Run the new prompt in a new conversation and save the output. A new conversation keeps the first exchange from influencing the second. Label this output "Revised."
  4. List three specific differences and say which element caused each. Be concrete. "The revised one is 90 words where the original was 240, because I set a limit" is the kind of note to aim for. Then write down anything the revised output still got wrong.

What to Expect

The revised output will usually be more specific to your situation and closer to the length and tone you wanted. The facts you supplied tend to make the largest difference, and the example tends to change the layout.

You may also see the revised output copy something from your example that you didn't intend, or miss a constraint. Those are useful findings, since each one points to the next revision. If the two outputs look about the same, your original prompt may already have contained what mattered, or the task may be one where the model's typical answer was fine.

Outputs vary from run to run. If a difference surprises you, running the same prompt once more in a new conversation will show whether it holds.

Self-Check

When you're done, check that:

  • You have both prompts and both outputs saved
  • Your revision contains all four elements
  • Each difference you listed is tied to an element
  • You noted anything the revision still got wrong

Nothing is uploaded. Write in your own notebook or document and keep it.

Report an issue with this item

Knowledge Check 10 min

Prompts and context

This ungraded knowledge check assesses your understanding of what a model needs from a prompt in order to do a task well. You'll be asked about what a model needs to be told, supplying context, using examples, and iterating on a prompt.

Note: Use this to test yourself, review the feedback on any questions you miss, and retry until you feel confident before moving forward.

5 questions · ungraded · retry as often as you like

Report an issue with this item