The Prompt Patterns Behind Every Good AI Answer (and How to Reuse Them)

Why a prompt that works brilliantly for someone else falls flat for you

Say a colleague sends you the exact prompt she uses to turn her messy meeting notes into a client update. She swears by it. You paste it in, drop in your own notes, and the output comes back generic: correct sentences, wrong emphasis, missing the one thing your client actually cares about this quarter. You didn’t do anything wrong. You just inherited five decisions she’d already made for her own situation, and none of them were yours to keep.

That’s the part almost nobody names when they talk about “good prompts.” A prompt that works is really a stack of choices: who the model should act as, what it needs to know, what it isn’t allowed to do, what shape the answer should take, and how you’ll know if it got it right. Your colleague’s prompt made all five of those choices for her client, her tone, her level of detail. Copy the sentence and you copy her answers, not the questions she was answering.

This is why prompt libraries and swipe files feel useful for about a week and then quietly stop getting used. You collect fifty prompts, and maybe six of them still fit a task you actually have this month. The other forty-four are someone else’s decisions, frozen in someone else’s wording, waiting for a task that matches theirs closely enough to work.

There’s a real alternative to collecting more prompts, and it isn’t writing better ones from scratch every time either. It’s learning the handful of underlying shapes those prompts are built from, so you can look at a new task and construct the right one in about the time it would have taken to search your notes for something close enough.

Companion piece, different angle: if what you actually want is a set of ready-to-paste Copilot prompts rather than the structure behind them, our roundup of out-of-the-box Copilot prompts covers that ground directly. This piece is for when the ready-made prompt doesn’t quite fit and you need to know why, and what to change.

The anatomy of a prompt pattern: role, context, constraint, format, check

Strip away the specific wording of any prompt that consistently works, and you’re left with five fields. Leave one blank and the model fills it in with a guess, which is usually where a mediocre answer comes from. Fill in all five deliberately and you’ve written a prompt pattern rather than a one-off prompt, something you can reuse by swapping the content of each field without touching the shape.

• Role. Who should the model act as, and from what vantage point? Not a costume, a genuine constraint on what it pays attention to. “Act as a skeptical procurement manager reviewing this vendor proposal” changes what gets flagged compared to “summarize this proposal.”
• Context. What does it need to know that isn’t obvious from the task alone? Your audience, your constraints, what’s already been tried, what “done” looks like for this specific piece of work.
• Constraint. What should it not do? Length limits, tone limits, things to avoid claiming, information it shouldn’t invent. This is the field people skip most often, and it’s usually the one that would have prevented the output they end up rewriting.
• Format. What shape should the answer take? A table, a numbered list, three paragraphs, a specific template with named fields. Vague format instructions produce answers you then have to restructure by hand.
• Check. How will you or the model verify the answer is actually right? This can be as simple as asking it to flag anything it’s unsure of, or as specific as “list which of these five criteria you couldn’t confirm from the source material.”

Here’s what that looks like filled in for a real task, not left as an empty form:

Notice that none of the five fields is the actual sentence you’d type. They’re the decisions the sentence has to make. Two people can fill in this table completely differently for the same task, both correctly, because the role, context and constraint that fit their actual situation aren’t the same as someone else’s.

Anthropic’s own prompt engineering documentation makes a version of this same point from the model side: giving Claude a clear role, labelled context, explicit constraints and a defined output format is what turns a vague response into something reviewable and reusable.^[1] OpenAI’s guidance for its own API lands on the same five ideas in different words: write clear, specific instructions, give the model reference material to work from, and tell it what format you want back.^[2] Neither vendor is telling you to memorize a magic phrase. They’re both describing the same underlying shape.

The six patterns that cover most professional work

Once you have the five fields, most requests you’d type into ChatGPT, Claude or Copilot sort into one of six recognisable jobs. None of these is a specific prompt. Each is a shape, with the anatomy above filled in a characteristic way for that kind of task.

A short example of each, in the same client-update situation from earlier, shows how differently the same five fields get filled depending on which pattern applies. Research and synthesis pulls the themes out of a stack of feedback emails. Drafting to a voice takes those themes and writes them the way your specific client-facing team actually talks, not a generic corporate register. Structured extraction turns a long call transcript into a clean table of decisions and owners. Critique and revision hands your draft update to a model playing a skeptical CFO and asks what it would push back on. Decision support lays out whether to send the update this week or wait for one more data point, with the tradeoffs named rather than a single answer. Step-by-step execution walks through building the update, getting sign-off on the structure first, then the numbers, then the tone, checking in at each stage rather than asking for the whole thing at once.

Six patterns isn’t a claim that nothing else exists. It’s a claim that these six cover enough of what shows up in an ordinary week that learning them beats collecting individual prompts for each new task.

How to look at a task and know which pattern it needs

The useful skill isn’t memorizing six labels. It’s looking at a task before you type anything and asking what you’re actually trying to get out of the model, because that answer points straight at a pattern.

Ask yourself one question first: am I trying to understand something, produce something, check something, choose between things, or move through a sequence? That single question does most of the sorting.

A first-line sales manager preparing for a difficult performance conversation is a good test of this. Her first instinct might be to ask a model to “help me write a script for this conversation,” which sounds like drafting to a voice. Look closer and it’s actually decision support first: she hasn’t decided how direct to be, whether to bring up a specific incident or keep it general, whether HR needs to be looped in before the conversation happens. Skipping straight to drafting produces a polished script for a conversation she hasn’t actually planned yet. The pattern-matching step would have caught that before she wasted ten minutes on a script she was going to throw out.

This is also where role-specific advice actually diverges, and it’s worth being specific rather than generic about it. A financial analyst leans on structured extraction and decision support most weeks: pulling numbers out of reports, then weighing scenarios against each other. A content marketer leans on drafting to a voice and critique and revision: producing copy that sounds like the brand, then stress-testing it before it goes out. An HR generalist handling a policy question leans on research and synthesis and step-by-step execution: pulling together what the actual policy says across several documents, then working through a specific case one stage at a time. The six patterns are the same for everyone. Which two or three you reach for most depends entirely on what your actual week looks like.

Combining patterns, and when to split one prompt into several

Some tasks genuinely need two patterns, not one, and the mistake people make is trying to cram both into a single prompt instead of running them as a short sequence.

Say you need to turn forty pages of customer interview notes into a one-page recommendation for your product team. That’s research and synthesis first (what do these interviews actually say, and where do they disagree), then decision support second (given that, what should the team actually do about it). Asking for both in one prompt usually produces something that skims the synthesis and rushes the recommendation, because the model is trying to do two jobs in one pass and neither gets full attention.

The better approach is to run them as a short chain: get the synthesis first, look at it, then feed that synthesis back in as the context field for a second, decision-support prompt. Three signs a task wants this treatment instead of one long prompt:

• You catch yourself writing a prompt with two distinct asks joined by “and then.” “Summarize these notes and then tell me what we should do” is a synthesis-then-decision chain wearing a single sentence.
• The input is long enough that the model would have to hold a full synthesis in mind while also reasoning about a decision, which is exactly where a one-pass answer starts skimming the first job to get to the second.
• You’d want to sanity-check the first output before trusting a second step built on top of it, which a single prompt never gives you the chance to do.

This takes two minutes longer than one long prompt and produces a noticeably more useful answer, because each pattern gets to do its actual job instead of splitting attention with the other. Separating them isn’t extra work, it’s the same work in an order the model can actually do well.

This matters more as tasks get longer, not less. A one-paragraph request rarely needs chaining. A forty-page input almost always benefits from it, because cramming synthesis and judgment into one pass is exactly where the quality drop shows up most.

How to tell whether your prompt is actually better, instead of just longer

The instinct when a prompt underperforms is to add more to it: more context, more caveats, more examples. Sometimes that helps. Often it just makes the prompt longer without making the output better, and there’s no way to tell the difference unless you actually compare versions instead of assuming the newer one wins.

Treat a prompt change the way you’d treat any small experiment: change one field at a time, keep the input the same, and look at what actually moved. If you add a constraint and the output improves, that constraint was doing something. If you add a paragraph of extra context and nothing changes, that paragraph was decoration, and it’s now something you’ll paste into every future version of this prompt for no reason.

Two changes are worth watching for specifically. A format change usually produces a visible, checkable difference, because you can see whether the structure you asked for actually showed up. A context change is easier to fool yourself about, because more context feels like it should help, and confirming it did means comparing the actual output, not just your sense that the prompt looks more thorough.

This is also where the anatomy pays off a second time. Because the five fields are named, you always know exactly which one you changed, which makes the before-and-after comparison something you can actually run in under a minute instead of a vague feeling that “this version seems better.” Do this a handful of times on a prompt you use often, and you’ll end up with a version that earns every line in it, which is a genuinely different thing from a prompt that’s just gotten longer over time.

If you’re building your first prompt this week, skip the search for a ready-made one. Pick a task, fill in the five fields honestly, run it, and check one thing: did the constraint or format field change the answer? If it didn’t, that’s the field to sharpen next time, and you’ll have learned something a copied prompt never would have taught you.

Sana Mian, Co-Founder of Future Factors AI

Sana is an AI educator and learning designer specialising in making complex ideas stick for non-technical professionals. She has trained 2,000+ learners across corporate teams, bootcamps, and keynote stages. Future Factors offers AI Bootcamps, Corporate Workshops, and Speaking & Consulting for businesses ready to adopt AI without the overwhelm.

More about Sana →