The Anatomy of a Great Prompt

Tell a new colleague to "look at the numbers" and they'll need to ask which numbers matter, what they're looking for, and who needs the answer. If you ask them to check whether March revenue dipped in the retail segment and email Ayşe the three biggest drivers, they can start. Copilot needs that same clarity, and it can't use your expression or the room around you to work out what you left unsaid.

When a Copilot answer disappoints, the request often left out an instruction the task depended on. The four-part checklist in this lesson helps you find that gap before you send the prompt.

A good prompt has four elements

Microsoft's prompting guidance rests on four elements, and so does every prompt that has worked well for us:

1. Goal is what you want back: a summary, a table, an email draft, a list of risks. State the action and the deliverable.
2. Context is why you need it and who it's for: the audience, the situation, the decision it feeds, and any constraint that should shape emphasis.
3. Source is what Copilot should base the answer on: a file, a meeting, an email thread, pasted text, or the web.
4. Expectations describe how the output should look: tone, length, format, section order, and what to do when a fact is missing.

You can usually locate the weak element by looking at the failure. "Help with this project" gives Copilot no action or deliverable, so the goal needs work. Start with a verb such as summarize, compare, extract, draft, rewrite, identify, organize, or recommend, then name what you expect back. For context, include the audience, purpose, and constraints that genuinely change the response. Extra background can distract as easily as missing background can. Name the source directly because "the document" may refer to any of several files. Expectations should be observable too. "Make it professional" leaves the standard open, while "neutral tone, five bullets, under 20 words each" gives you a result you can check.

Some quick factual questions don't need the full framework. Use all four elements when the answer will be shared, sent, or used in a decision. If the result misses, identify the element responsible before rewriting the entire prompt. That targeted diagnosis is faster and protects the instructions that already worked.

Each element changes the answer

Each row in the table below adds one element to the same request, and each addition fixes a different problem:

Length is not what fixed the answer in that table. Completeness did. Two sentences that name the goal, the audience, the source, and the format will beat a rambling paragraph.

Each element also repairs a different failure. A goal turns an open-ended request into something you can check. Context changes what the answer emphasizes. A source changes where the facts come from. Expectations change the shape you get back. So if the facts are wrong, adding three more sentences about the goal will not help. You need to name the source instead. Match the fix to the failure: check goal and context if the content is off, check the source if the facts are wrong, and check expectations if only the format needs work.

How context differs from source

This is the pair people blur most often. Get it wrong and an answer can be factually correct but emphasize the wrong things, or well organized but built on a fact nobody supplied.

Context and source answer different questions, and mixing them up causes the blur:

• Context: "I'm preparing a Monday briefing for operations leaders who must decide whether to hold the target date." That tells Copilot what to emphasize and how much to explain.
• Source: "Use only the July 8 project notes for factual statements." That tells Copilot where every fact must come from.

Context is never evidence. Telling Copilot the audience is "senior leaders" does not license it to state a budget figure the notes never mentioned. When the answer will drive a decision, pin the source down with an explicit boundary, such as "Use only the update between SOURCE START and SOURCE END for factual statements," so instructions and evidence never blur together.

When the source is missing a fact you asked for, don't leave a gap for Copilot to fill with something plausible. Tell it what to do instead: "If a requested value is absent from the source, write 'Not provided.'" That single line turns a silent guess into a visible flag you can act on.

Take a risk table pulled from a project update that never named who owns each risk. Without a rule, Copilot may fill the owner column with a name the source never mentioned, and now the table contains a fact nobody supported. A reviewer trusts the tidy table and acts on an owner nobody agreed to. With the "Not provided" rule, that same cell reads "Not provided": the gap stays visible, and you know to go find the real owner. Spell out the missing-information behavior whenever a confident guess costs more than an honest blank.

Expectations make the answer checkable

Expectations describe how the output should look: tone, audience, required sections and their order, length, table columns or bullet structure, and rules for missing information. Naming them creates a standard you can score the answer against. "Make it professional" can't be scored. "Write for nontechnical leaders in a neutral tone, lead with the decision needed, then status, then a risk table, under 400 words" can.

Expectations get sharper fast with a couple of habits. First, state positive instructions: describe the behavior you want. "Give three specific next actions" is more actionable than "don't be vague." Second, use if-then rules for conditional cases: "If an owner is absent, write 'Not provided.'" Microsoft's own guidance leans on both patterns.

Here is the whole framework as a planning template you can keep next to your keyboard:

Goal: [action and deliverable]
Context: [purpose, audience, and relevant situation]
Source: [material Copilot should use]
Expectations: [format, tone, length, order, and missing-information rules]

The labels are a checklist. Fold them into natural sentences once the habit sticks. What they buy you is a way to inspect an answer instead of just admiring it. When expectations are observable, you can read the response and tick each one: right sections, right order, right length, missing values flagged. A prompt whose success you can't check is a prompt you'll end up re-doing.

One more habit makes expectations more reliable: keep your instructions and your evidence visibly separate. When you paste a source, fence it, for example "Use only the text between SOURCE START and SOURCE END for facts," so a sentence in the source is never mistaken for an instruction, and an instruction is never mistaken for a fact to repeat. That separation matters more as your prompts get longer.

Which element should you fix first?

When an answer misses, diagnose it before you rewrite the whole prompt. Read the response against each element in turn: Did it do what the goal asked? Is the emphasis right for the context? Can every fact be traced to the source? Did it follow the format and missing-value rules in your expectations? The first check that fails names the element to fix.

Then correct the single largest failure rather than rewriting from scratch. Say the brief was strong but invented a risk owner. You don't need a new prompt. You need one targeted follow-up: "Revise using only facts stated in the source. The source names no risk owner, so replace any inferred owner with 'Not provided,' and keep all four sections." That preserves the goal and source you already got right and fixes only the element that failed. Rewriting everything risks breaking the parts that worked.

Then verify. A polished sentence still fails if the source doesn't support it, so compare every name, date, number, status, and owner against your evidence before you rely on it. Run through the elements in order as a review checklist: did it do the goal, match the context, stay inside the source, and follow the expectations? You'll practice that targeted fix in the next lesson, Iterate and Refine. For now, look for which element left room for the failure.