Common Prompt Patterns

Every time you open a blank chat, you start from scratch. You remember that a certain prompt worked well once, but not quite how you worded it, so you improvise again and get a different result.

Experienced users don't improvise every time. They reach for a small set of patterns: reusable shapes that solve a recurring kind of problem. A pattern isn't a magic phrase. It is a structure that works across tools and topics because it gives the model what it needs for a particular type of job. This lesson covers seven that hold up well, each with a short example you can adapt.

1. The template (fill-in-the-blanks)

Use it when: you do the same kind of task over and over.

A template is a prompt with the stable parts written once and the changing parts left as placeholders. You fill in the brackets each time. The result is consistent because most of the prompt never changes.

Write a [TYPE OF MESSAGE] to [AUDIENCE] about [TOPIC].
Tone: [TONE]. Length: under [NUMBER] words.
Must include: [KEY POINTS].
Avoid: [THINGS TO LEAVE OUT].

The first time you build a template takes a few minutes. Every use after that takes seconds, and anyone on your team can use it and get similar results.

2. The role

Use it when: the answer needs a particular kind of expertise or point of view.

Asking the model to take on a role steers which knowledge and voice it draws on. It works best when paired with the real situation, not used alone.

Before:

Is this lease okay?

After:

Act as an experienced tenant advocate reviewing a residential lease
for a first-time renter. Read the lease below and list any clauses
a renter should ask about before signing, in plain language.
Lease: [PASTE LEASE TEXT]

A role doesn't give the model credentials. It is not a lawyer, doctor or accountant, and for decisions that matter, a qualified person should check the result. What the role does is point the answer in a useful direction.

3. Few-shot (show, don't describe)

Use it when: you need a specific format or judgment applied consistently.

Instead of describing the output, you show two or three examples and then give the new input. The model follows the pattern in your examples.

Turn each note into a one-line task.

Note: need to call the landlord about the leak before friday
Task: Call landlord about leak (due Friday)

Note: sam said the flyer has the wrong date, fix + reprint
Task: Fix date on flyer and reprint

Note: [YOUR NOTE]
Task:

Choose examples that cover the tricky cases, not just the easy ones. The paid module on few-shot and zero-shot learning goes deeper into picking examples that actually teach.

4. Step-by-step reasoning

Use it when: the task involves several steps, comparisons or calculations.

Asking the model to work through the problem in steps before giving a final answer often produces a more careful result, and it lets you see where the reasoning went wrong if it did.

I'm choosing between [OPTION A] and [OPTION B] for [PURPOSE].
My priorities, in order: [PRIORITY 1], [PRIORITY 2], [PRIORITY 3].

Work through this step by step: first compare the two options on
each priority, then note any tradeoffs, then give a recommendation
with a one-sentence reason.

Showing steps doesn't make the reasoning correct. Read the steps, especially any math, and check the numbers yourself if they matter.

5. Critique and revise

Use it when: a first draft is close but not there yet.

Ask the model to review its own draft against specific criteria, then rewrite it. The key word is specific. "Make it better" gives the model nothing to aim at.

Review the draft above against these checks:
1. Could a reader who knows nothing about [TOPIC] follow it?
2. Is every claim something I actually provided, or was it added?
3. Is anything repeated?

List the problems you find, then write a revised version that fixes them.

Check 2 is worth keeping in almost every version of this pattern. It invites the model to flag details it may have invented, although you should still verify them yourself.

6. Extraction to a table or JSON

Use it when: you have messy text and need organized data.

Give the model unstructured material and name the exact fields you want pulled out. Ask for a table if a person will read it, or JSON if it will go into a spreadsheet or another tool.

From the emails below, extract every event request.
Return a table with these columns: Name, Date requested,
Number of people, Special requests.
If a field is not mentioned, write "not stated". Do not guess.

Emails:
[PASTE EMAILS]

The "not stated" instruction matters. Without it, the model may fill empty fields with plausible guesses. Spot-check a few rows against the source before you rely on the table.

7. The audience persona

Use it when: you want to know how something will land with the people who read it.

Instead of giving the model an expert role, have it take the role of your audience and react to your work. This is a quick way to find confusing spots before a real reader does.

Read the flyer below as if you are [DESCRIBE AUDIENCE, e.g. a busy
parent who has never heard of our program]. Tell me:
- What you understood in the first five seconds
- What questions you still have
- What would stop you from signing up

Flyer: [PASTE TEXT]

A simulated reader is useful for spotting gaps, but it isn't research. It can't tell you what your actual audience thinks. Treat it as a first pass, then ask real people.

Combining patterns

The patterns stack. A good everyday prompt might be a template that sets a role, includes two examples, and ends with a critique-and-revise step. Start with one pattern, get it working, then add another only if the output still needs it.

Try this

Take 10 to 15 minutes.

1. Look at the table above and pick the problem that matches something you deal with regularly.
2. Copy that pattern's example and replace the brackets with your real details.
3. Run it and read the result carefully. Did it fix the problem you picked?
4. Add one more pattern on top (for example, a critique-and-revise step after an extraction) and run it again. Compare the two outputs.
5. Save the version you would use again, with brackets left in for the parts that change.

What to remember

• Patterns are reusable shapes for recurring problems, not magic words. They work because they give the model what a specific type of task needs.
• Templates make results consistent; few-shot examples make formats consistent.
• Roles and audience personas steer perspective, but they don't make the model an expert or a real reader. Check anything important.
• Step-by-step and critique-and-revise improve care and quality, but you still verify facts and numbers.
• Match the pattern to the problem, start with one, and stack more only when needed.

Where the course goes next

The paid modules build directly on these patterns. Few-Shot and Zero-Shot Learning covers choosing examples that teach; Prompt Chaining shows how to split big jobs into linked steps; Temperature and Output Control explains how to make results more predictable or more varied; Prompts for Content Creation and Data Analysis applies the patterns to everyday work; and Building a Prompt Library turns the prompts you save into a system you can reuse and share.