If you type a fresh version of "summarize this status update for leadership" every few days, the task has outgrown a one-off prompt. You can improve the prompt itself with examples, personas, chains, and named-file grounding. You can also keep the versions that have survived a real test in a prompt library. These techniques still rely on the four elements from lesson one. They give you more control when the task needs it.
Start with Microsoft's prompt galleries
Microsoft offers two galleries for different parts of the job. The public Prompt Gallery is a browsable catalog organized by function, product, and task, with "Copy prompt" and "Open in Copilot" actions. Start there when you want ideas. The in-product gallery inside Copilot contains Microsoft's Suggested prompts, prompts you've saved under "Your Prompts," and prompts shared by your team. You may also find downloadable function packs for roles such as Sales, Marketing, HR, and Finance. Each pack contains a small set of scenario prompts to adapt.
A copied prompt is still a draft. It was written for a broad audience, so its source, audience, and output format may have little to do with your task.
Adapt a gallery prompt before you use it
Treat every borrowed prompt as a draft to finish with the four elements. Replace each bracketed placeholder, name your exact source and audience, set the format and length, and add the missing-information rule you already know:
Use only the supplied source. If an owner, date, amount, action, or risk
is absent, write "Not stated in the source." Do not infer missing facts.
Then, when you check the output, classify each statement three ways: supported (the source states the fact), mechanically derived (the prompt only changed presentation, sorting supplied ratings, placing a supplied request under a heading), or not supported (a fact, owner, or judgment you can't trace). Annotate the mechanical transformations so a colleague could reproduce them, and re-prompt anything unsupported. A gallery prompt gets you past the blank composer. That adaptation step is where the answer earns its trust.
One more habit for pack prompts specifically: inspect every bracketed value and file reference before you run it, down to the ones that look harmless. Function packs ship with placeholders like [specific areas of concern] and sample file names that mean nothing in your tenant. Leave one unresolved and Copilot either stops to ask mid-answer or, worse, invents a value to keep going. Read the whole prompt once as if you were Copilot: could any word point at something you haven't supplied? Resolve it, then add the source-fidelity line. The difference between a pack prompt that works and one that fabricates without telling you is usually a single placeholder nobody replaced.
The prompt lifecycle: discover, adapt, test, save
A prompt only becomes reusable after it passes gates you can observe. The path is discover → adapt → test → save, and saving branches into sharing and scheduling when your workspace offers them.
The gate people skip is the last one. Saving a prompt does not prove its output is accurate. A successful save, share, or schedule only proves the control worked. Quality starts with a different input running through the prompt cleanly, because that's the first evidence it generalizes beyond the example you built it on.
Show, don't just tell: few-shot examples
Most prompts are zero-shot: you describe the task and ask for a result. Few-shot prompting adds a few completed demonstrations before the real inputs, so Copilot sees the exact labels, reasoning, and output shape you expect. It's worth the extra length when categories have fuzzy boundaries, local terminology, or a strict schema.
There's one rule that makes or breaks a few-shot test: your demonstrations must use different items than the ones you're evaluating. If you show three completed examples and then ask Copilot to classify those same three, you've tested copying. Keep a written rubric, demonstrate with sample items, and score the prompt on unseen inputs. A correct few-shot run doesn't have to look different from a correct zero-shot run. The test is whether both follow the same rubric while the few-shot run applies your examples to new material.
Reach for few-shot when a category boundary is fuzzy (is a completed-but-frustrating task Neutral or Risk?), when your team uses local terminology a general model won't know, or when you need a strict output schema. Keep every demonstration consistent with your written rubric. A demonstration that contradicts the rule teaches Copilot the wrong pattern faster than the rule corrects it. Resist demonstrating with the very items you're grading. A perfect score on those items proves Copilot can echo the answers you handed it. The next hundred comments you haven't labeled are the real test.
A persona can shift emphasis
A persona tells Copilot whose perspective to take, which is a precise way to set context and expectations. Skip "act as an expert": it's untestable. Define four parts instead: the role (operations analyst), the audience (a regional director), the decision focus (blockers addressable this week), and the constraints (don't infer causes, owners, or affected-user counts).
The line a persona must never cross: it may reorder, re-emphasize, or recommend, but it must not change the underlying facts. Ask the same verified source as an operations analyst and as a communications manager, and the priorities and recommendations can differ. The counts, quotations, and events stay identical. If a persona prompt reports "all users can't sign in" when the source showed one blocked user, the persona broke its contract and the output is wrong.
Chain prompts, and stop on a failed checkpoint
A prompt chain breaks a big task into stages: extract, classify, count, recommend, and verifies each result before feeding it to the next. The reason to bother is containment: an unsupported number in stage one becomes a wrong recommendation in stage four if nothing catches it in between. Define decision rules before you rank ("a group with a task blocker outranks friction. Report ties as ties"), and build a checkpoint into the counting stage: each group's count must equal the number of listed source IDs, and every ID must appear exactly once.
When a checkpoint fails, the correct move is to stop, identify the mismatch, fix and re-verify that stage, and only then continue. If a stage reports four items but lists three IDs, you do not push forward because the failures "seem urgent," and you do not ask a persona to reinterpret the count. A persona can't repair broken evidence. Grounding a comparison in named files with / references works the same way: assign each file a clear role ("use /ProjectBrief.docx for requirements, /ReadinessChecklist.xlsx for status"), then verify the filenames, quoted evidence, and calculations against the files rather than trusting a confident summary.
Skipping the stages and asking for the whole analysis in one shot lets errors compound silently. A miscount in the extraction stage becomes a wrong ranking, which becomes a misdirected recommendation, which becomes a decision memo that sends people to fix the wrong thing, and by the final bullet, nothing visibly points back to the original mistake. Checkpoints are cheap insurance: a one-line rule that "each count must equal the number of listed IDs" catches the error where it's still obvious.
Define your decision rules before you ask for a ranking, too. "Find the most urgent issue" invites Copilot to improvise a definition of urgent. A stated rule, severity first, then count, ties reported rather than broken, makes the ranking reproducible and reviewable.
