Five parts of a prompt your whole team can reuse

A reliable prompt isn't a clever trick, it's a template with five named parts, each doing a different job. Once a team shares the vocabulary, a prompt someone else wrote is something you can read, fix, and reuse rather than something you have to reverse-engineer from the output. Here's the scaffold, worked through on one real task: turning raw meeting notes into client-ready minutes.

The scaffold

Of the five, Format is usually the single most effective fix on its own. Naming the exact sections and requiring a table for action items restructures a vague paragraph into something scannable, faster than any amount of extra instruction about tone or role. Role and Constraints then sharpen what Format produces; they don't replace it.

Zero-shot versus few-shot

Zero-shot means instructions only. Few-shot means instructions plus one worked example. Show a single perfect action-item row, with owner, action, and due date filled in exactly the way you want every future row to look, and the model copies that shape for everything after it. This is the cheapest quality upgrade available in prompting: one example, usually a sentence or two of extra text, and the output gets measurably more consistent. It works because these models learn a task from what's in the prompt itself, adapting to instructions and examples without any retraining (Brown et al., 2020).

The step-by-step phrasing

On genuinely multi-step work, such as reconciling numbers before drafting a memo, or extracting decisions before writing minutes, asking the model to work through the steps before producing the final answer measurably improves the result, and costs one added sentence (Kojima et al., 2022). The honest caveat: newer models increasingly reason step by step without being asked. Treat the phrase as a tool you reach for when a task is genuinely multi-step and the output still looks shallow, not as a line you paste into every prompt out of habit. Teach the principle, break complex work into steps, and let people judge when spelling it out still helps.

The [CHECK] convention

Tell the model explicitly what to do when it doesn't know something, and give it a marker to use instead of a guess. Writing [CHECK] into the output where an owner or date is unclear turns an invisible failure, a plausible-looking name that's simply wrong, into a visible one you can search for and fix in ten seconds. This single line in the Constraints section does more for a document you're about to send to a client than almost anything else in the template.

From template to team agent

A template sitting in a shared doc helps whoever remembers to open it. An agent helps everyone, with zero setup per use. Copilot Studio's Agent Builder takes exactly what you wrote in the scaffold, with no code involved:

1. Open Agent Builder: in Microsoft 365 Copilot, choose Create an agent, or go to copilotstudio.microsoft.com and start a new agent.
2. Paste the template into Instructions. Role, Task, Format, and Constraints go in as written. The worked example goes in too; it's what keeps every output in shape.
3. Add a starter prompt, a one-line button, like "Paste raw meeting notes to get client-ready minutes," so colleagues don't have to write their own opening line.
4. Test with a real, recent example, and check every name, owner, and date against the source. Any place the agent guessed where the template says [CHECK] means the constraint needs tightening.
5. Share it to the relevant Teams channel. You're the named owner of what you just published.

Why the scaffold outlives any single prompt

The value of naming the five parts isn't the template itself, it's that a colleague reading your prompt six months from now can tell which part is broken when the output goes wrong. A vague result usually traces back to one missing or weak part rather than the whole prompt being flawed, and having names for the parts turns debugging a prompt into the same kind of conversation as debugging anything else: point at the piece, fix that piece, test again. Teams that share this vocabulary reuse each other's prompts instead of starting over each time, because a Role-Task-Context-Format-Constraints prompt from another team is legible even if you've never seen the specific task before.

The same structure scales down as well as up. A one-off prompt typed into a chat box benefits from the same five parts as a template destined to become a shared agent. The only difference is how much effort goes into the worked example, since a prompt you'll use once doesn't need the same polish as one your whole team will run for a year.