The ten prompt patterns every knowledge worker should know

"Prompt engineering" sounds like a discipline. In practice, it is a small bag of patterns. Once you know the patterns, you stop writing prompts from scratch — you reach for the pattern that fits the situation and customise it for the moment.

This article is the ten patterns I find myself using almost every day. Most of them generalise across writing, analysis, decision-making, learning, and coding. Once you have all ten in your head, you have most of the practical prompt-engineering you will ever need.

Patterns are safer than copied prompt recipes because they preserve intent. Choose the pattern for the job, then add context, constraints, and validation for the specific task.

1. The interview-me pattern

When you want the model to help you with something but you have not fully articulated what you want, let it interview you.

Before drafting anything, ask me [N] questions you would need answered to do this well. Wait for my answers before continuing.

This is the pattern most beginners under-use. It is also the one that produces the biggest quality lift in the shortest time. Most prompts fail because the prompter has not yet figured out their own situation. The interview pattern fixes that by making the model help you sharpen the prompt.

Use it for: drafting any complex piece, planning a project, getting unstuck on a decision, designing anything.

2. The critique-and-revise pattern

When you have a draft (yours or AI-generated), do not ask for "a better version." Ask for critique, then ask for the specific revision.

Read this draft carefully. Tell me: 1. What is working — the parts I should not change. 2. What is weak — specific lines or paragraphs, with quoted text. 3. What is missing. 4. Anything that contradicts itself or sounds wrong.

>

Do not rewrite anything yet.

After the critique, you can either revise yourself or ask the model to do specific revisions ("rewrite the second paragraph based on your critique, keeping the others").

Use it for: improving any piece of writing, code review, analysis review, slide review.

3. The three-variants pattern

For anything where the right answer is judgement-dependent, generate three options and pick.

Produce three versions: - Version A: [specific constraint, e.g., short and direct, 50 words] - Version B: [specific constraint, e.g., warm and explanatory, 150 words] - Version C: [specific constraint, e.g., formal and detailed, 250 words]

>

Label each clearly.

Comparing three options is faster and produces a better final than asking for "the best version." It also reveals the trade-offs you were making implicitly.

Use it for: emails, social posts, headlines, taglines, slide titles, code approaches, hiring decisions, anything with multiple valid framings.

4. The devil's-advocate pattern

Models are eager to please. By default they will produce arguments that support whatever you suggested. To counteract this:

[After getting a response.] Now play devil's advocate. Take your own answer and produce the strongest credible counter-argument. What would the smartest critic of this position say?

This catches the parts of your thinking that were thin and the parts of the model's response that were optimistic. Particularly useful when you suspect you are being told what you want to hear.

Use it for: decisions, strategy, business cases, anything where you are about to act on what the model said.

Do not use it as theatre. If the decision is factual or regulated, the counterargument is not a substitute for checking sources, policy, or legal requirements.

5. The structured-template pattern

When you want a specific output shape, do not describe the shape — show it.

Respond in exactly this format:

>

Decision: [your recommendation]

>

Top three reasons for: 1. [...] 2. [...] 3. [...]

>

Top three reasons against: 1. [...] 2. [...] 3. [...]

>

What would change my answer: [...]

>

Confidence level: [Low / Medium / High] because [...]

The model fills in the bracketed parts. The structure is predictable, parseable, and consistent across runs. Particularly useful when you want to compare outputs across many similar prompts.

Use it for: analytical decisions, structured reports, batch processing where you need consistent format, anything you want to paste into a doc and have look uniform.

6. The step-back pattern

When you are about to ask a specific question, first ask the broader one.

Before answering my specific question, take a step back and tell me: what is the general principle or framework that applies here? Then apply it to my specific case.

Empirically, this lifts answer quality on hard analytical questions, because the model commits to a framework before making specific claims. Less "well, in this case..." hedging; more principled answers.

Use it for: technical questions, strategic decisions, learning, anything where the right answer depends on a general principle being applied correctly to a specific situation.

7. The persona pattern

Assigning a specific role to the model dramatically shifts the style and content density of the response.

You are [a specific kind of expert] with [specific background]. You communicate in [a specific style]. You always [a specific habit].

A few that work consistently well:

• "You are a senior tax accountant in Estonia. You are direct and assume I am intelligent."
• "You are a careful copy editor who only changes what genuinely needs changing."
• "You are a skeptical investor who has seen too many bad ideas. You ask hard questions."
• "You are a patient tutor who has taught this topic for ten years."

Be specific about the role. "An expert" is weaker than "a senior cybersecurity engineer who has done incident response for fifteen years."

Use it for: anything where the kind of response matters as much as the content.

8. The role-play pattern

A variation on persona: have the model play a person rather than just an expert, and have a conversation with them.

Role-play as my prospective client. They are a marketing director at a mid-size B2B company. They are friendly but skeptical and have been burned before. I am about to pitch them on hiring my agency. Ask me questions and react the way they would. Stay in character. Push back if my pitch sounds vague or oversold.

Use it for: interview prep, sales practice, hard conversations rehearsal, customer empathy work. The model's ability to maintain character is good enough in 2026 to make this genuinely useful preparation.

9. The contrast-pair pattern

When you cannot quite describe what you want, show what you do and do not want.

Here is an example of writing that hits the tone I want: [paste good example]

>

Here is an example of writing that misses the tone: [paste bad example]

>

The differences I care about are [your observation]. Now write [your task] in the style of the first one.

This is more powerful than describing the style in adjectives. The contrast makes the dimension you care about explicit, and the model is much better at matching examples than matching descriptions.

Use it for: brand voice, code style, design taste, anything where the right answer is "more like this, less like that."

10. The output-template pattern

A formal version of structured-template (#5) for repeatable batch work. Define a strict template, then apply it across many items.

For each item I give you, produce a response in this exact JSON format:

>

json { "summary": "...", "priority": "...", "category": "...", "next_action": "..." }

>

Priority must be one of: "high", "medium", "low". Category must be one of: "billing", "technical", "feature_request", "other". Wait for each item before responding.

Strict templates are the foundation of using AI in any structured workflow — pipelines, automations, integrations with other tools. The more specific the template, the more reliable the output.

Use it for: classification, extraction, batch processing, anything where downstream tools need consistent format.

For automation, pair this pattern with validation. If the output is not valid JSON, contains a category outside the allowed list, or leaves a required field blank, the workflow should stop or route to human review.

Putting them together: a real workflow

The patterns are not exclusive. A typical complex task chains several together.

Suppose you are writing a proposal for a new company policy. The workflow might look like:

1. Interview-me to clarify what the policy needs to address (#1).
2. Step-back to articulate the principle behind your approach (#6).
3. Three-variants of the actual policy proposal (#3).
4. Structured-template for the final draft (#5).
5. Devil's-advocate against the strongest version (#4).
6. Critique-and-revise for the final polish (#2).

That is six patterns, in a 45-minute working session, on a single piece of work. The result is dramatically better than "write me a policy on X."

A note on what these patterns share

If you look at the ten patterns together, you notice they cluster around three themes:

Patterns that get more context out of you — interview-me, contrast-pair, step-back. These work because the bottleneck is usually you, not the model.

Patterns that structure the model's response — structured-template, output-template, three-variants. These work because the model defaults to safe, vague responses; structure forces specificity.

Patterns that make the model push back — critique-and-revise, devil's-advocate, role-play. These work because the default mode is too agreeable; forcing the model to find weaknesses produces better thinking.

Almost every "prompt engineering trick" you will see online fits into one of these three categories. If you understand the three, you can invent your own patterns for situations the ten do not cover.

Choose by job type

| Job | Best starting pattern | Validation habit | | --- | --- | --- | | Drafting | Three-variants | Pick one and edit, do not send raw | | Analysis | Step-back + structured-template | Ask what evidence would change the answer | | Decisions | Devil's-advocate | Verify facts and list assumptions | | Learning | Interview-me + patient tutor | Quiz before moving on | | Automation | Output-template | Validate schema and route failures | | Tone matching | Contrast-pair | Compare against a real accepted example |

How to internalise them

Reading about patterns does not make them habits. The fix is to use them deliberately for a couple of weeks. A practical approach:

• Print the list of ten and keep it visible while you work.
• Before sending any non-trivial prompt, pause for two seconds. Ask: which pattern fits this?
• If none seem to fit, try the simplest match anyway. The discipline of looking is more important than perfect pattern selection.

After two weeks, the patterns become reflexive. You stop reaching for the printed list. You catch yourself naturally combining them. You start noticing when you are missing one — when you should have asked for the interview, when you should have asked for the counter-argument, when you should have shown an example.

That is when AI stops feeling like a chatbot and starts feeling like a tool you actually know how to use. The patterns are the difference.