Prompts your team will actually reuse: a structure, not a list

The structure every vendor agrees on

Microsoft’s guidance for Copilot names four parts: goal, context, expectations and source. Google’s Prompting Guide 101 for Gemini uses persona, task, context and format. OpenAI’s help centre guidance stresses being specific and refining in rounds; Anthropic’s prompt engineering documentation says the same at more length and adds examples and explicit output formats. Strip the vocabulary and they describe one thing.

• The task, as a verb with an object. Summarise this thread. Draft a reply. Compare these two versions. Not "help me with".
• The material, attached or pasted, and named in the prompt so the tool knows what to work from. The Copilot / picker, a file upload in ChatGPT or Claude, the open Doc in Gemini.
• The reader and the situation, in one sentence. Who this is for and what they will do with it. This is the part people skip, and it is why the output sounds like nobody.
• The shape of the answer. Length, format, sections, tone. A table with these columns. Under 150 words. Numbered rules. A first draft with gaps marked.
• What not to do. Do not invent figures. Do not add tasks nobody mentioned. Mark anything uncertain with [CHECK]. The instruction that turns a fluent guess into a useful draft.

That is the whole technique. It fits on an index card. The reason teams still struggle is not that they lack the card; it is that they never sit down with their own tasks and write the prompts out.

From a list to a library: what a saved prompt needs

A prompt on its own is half an instruction. The other half is the surrounding knowledge: what to attach, what a good result looks like, what to check before using it. When the person who wrote the prompt leaves, that knowledge leaves with them unless it was written down. A library entry therefore has five fields, and a prompt that is missing any of them is not ready to be shared.

1. 1

   Name

   The task in plain words, as a colleague would search for it. "Weekly client update from meeting notes", not "Update prompt v3".

2. 2

   Tool and where to run it

   Copilot in Word, Gemini in Gmail, Claude Projects, ChatGPT with a file attached. Prompts behave differently across tools; the entry says which one it was tested in.

3. 3

   The prompt

   With the placeholders in square brackets and nothing else that needs editing. If a person has to rewrite a sentence before using it, it is not finished.

4. 4

   What to attach and what good looks like

   Two or three lines. The inputs, and a description of a result you would accept. This is what lets someone judge the output without asking the author.

5. 5

   Owner and last checked

   A name and a month. Tools change; prompts drift. The owner reruns it every quarter and fixes or retires it.

Three prompts, written the way a library entry should be

Write this week’s client update for [client name] using the attached notes. Reader: their [role, e.g. marketing director], who has five minutes and wants to know what moved, what is blocked and what we need from them. Structure: three short sections with those exact headings, then one line on next week. Under 200 words. Plain UK English, no exclamation marks, no adjectives about our own work. Where the notes mention a number or a date, keep it exactly; where something is unclear in the notes, write [CHECK] rather than guessing.

Read the attached [document type, e.g. supplier contract, tender, policy draft]. Do not summarise it. Instead, give me the ten questions a careful [role, e.g. operations director] should ask before agreeing to it, in order of how much money or risk each one carries. For each question, quote the clause or page it comes from so I can check it, and say in one line why it matters. Then list anything you expected to find and did not.

I need to have a conversation with [role, e.g. a supplier account manager] about [the issue, in two sentences, with no names]. My aim is [what a good outcome looks like]. Their likely position is [what you think they will say]. Give me: the three points I must land, in the order to raise them; the two objections most likely to come back and a calm response to each; and a one-sentence opening that is direct without being hostile. Then tell me the one thing I should not say. Keep the whole thing under 250 words.

Getting the team to write their own

Prompts written by the trainer are the trainer’s. Prompts written by the team are the team’s, and those are the ones that survive. In a session we spend most of the day on exactly this: each person takes a task from their own week, writes the prompt with the five fields, tests it on real material, and reads the result to a colleague who says whether they would use it. Then it goes into the library, or it does not.

You can run the same exercise in a team meeting in forty minutes. Everyone brings one repeated task. Ten minutes to write, ten to test, ten to read aloud in pairs, ten to save the ones that worked. Do it monthly and the library grows at the pace of the team’s real work, which is the only pace that lasts. Our own prompt library is built the same way and is free to raid for structure; the entries themselves should be yours.

Below is a prompt one of my team wrote that works but is rough. Rewrite it into a reusable library entry with these fields: Name (the task in plain words); Tool (where it runs); Prompt (with [placeholders] for anything that changes each time, and an instruction not to invent facts); What to attach; What good output looks like (two lines). Keep the author’s intent and tone. Do not make it longer than it needs to be.

[Paste the rough prompt and one sentence on what it is for]