A prompt engineering guide: the techniques that still work, with examples

In 2023 the most quoted prompt in the world was five words long: "Let's think step by step." It worked, because models that wrote out their reasoning made fewer slips.

On today's models that line is mostly redundant, and on one it can backfire. Claude's newest models think before answering whatever you write; Anthropic says that on Fable 5.1, Mythos 5.1, Fable 5, Mythos 5 and Opus 5.5 "thinking is always on", controlled by an effort setting. For Opus 5.5 it goes further: prompts that push the model to reproduce its internal reasoning in the response "might be declined" with a reasoning_extraction refusal (Anthropic, Prompting Claude Opus 5.5). Google says of Gemini 3 that it is not necessary to make the model show its reasoning steps in the response (Gemini API prompt design strategies). OpenAI exposes the same dial as reasoning effort, with medium as "the recommended balanced starting point" and the warning that "higher reasoning effort isn't automatically better" (OpenAI, Using GPT-5.5).

Everything else in the classic toolkit has survived. What changed is the reason for it. You no longer prompt to make the model reason harder; you prompt so that it reasons about the right thing, with the right material, and hands back something you can check.

We read the current prompting guides from Anthropic, OpenAI and Google side by side. Where all three agree, we'd treat the technique as settled. Where they differ, the difference is usually about the model, not the principle.

Two disagreements are worth knowing. On examples, Google is the most insistent and also warns that too many make the model "overfit" to them; Anthropic's engineers prefer a few diverse, canonical examples over a "laundry list" of edge cases (Effective context engineering for AI agents). On placement, OpenAI's older guide hedged with instructions at both the start and the end of long context; Anthropic and Google both say the question goes last.

The ninth technique, grounding the model in sources and giving it permission to say "I don't know", has its own guide: prompts that cite sources.

No technique tells you which sentences in the result to trust. Count connects to Claude and labels each claim by what it rests on, so you can see whether a technique actually helped.

Three before-and-after pairs. The tasks are illustrative; the techniques are the ones in the table.

A weekly ops summary: be specific, say why

Before:

Summarise this week's support tickets.

After:

Summarise the support tickets below for the Monday ops meeting. The audience is team leads who have five minutes, so they need what changed, not a tour of every ticket.

Give: the three issues with the most new tickets this week versus last week, with counts for both weeks; any issue mentioned by more than two enterprise customers; anything that looks like an outage. Count with the code tool, not by reading.

If a ticket has no category, list how many there were rather than guessing.

<tickets>
[paste export]
</tickets>

The "why" (five minutes, team leads) tells the model what to drop. Counts for both weeks make "most new" checkable. The uncategorised line stops a quiet guess from inflating one bucket.

Classifying feedback: show, don't describe

Label each piece of customer feedback as one of: pricing, onboarding, bug, feature request, other.

<examples>
<example>"Took us three weeks to get SSO working" → onboarding</example>
<example>"The export button does nothing in Safari" → bug</example>
<example>"Would pay more for an API" → feature request</example>
<example>"Too expensive for a team of four" → pricing</example>
</examples>

If a comment fits two labels, give both and say which is primary. Use "other" rather than forcing a fit.

Four short examples, one per label that's easy to confuse, wrapped in tags so they don't read as instructions. That follows Anthropic's advice to keep examples "relevant", "diverse" and "structured".

A research brief: material first, question last

<documents>
[paste the three analyst reports, each with its title and date]
</documents>

Using only the documents above, compare how each report sizes the market for [product category]. For each, give the figure, the year it refers to, and the method in one line. Then say where they disagree and which assumption drives the gap. If a report doesn't give a method, say so.

The documents sit above the question because Anthropic reports that queries at the end "can improve response quality by up to 30 percent in tests". The "year it refers to" clause exists because market-size figures are routinely quoted without one.

The commonest mistake in a work prompt is asking for five things at once: find the data, clean it, analyse it, chart it, write it up. The model will try. It will also make every decision in that chain without telling you which ones it made.

Google's advice is blunt: "create one prompt per instruction" and chain the steps. Anthropic says the most common chaining pattern is "self-correction: generate a draft → have Claude review it against criteria → have Claude refine". You can do this in a chat window with three messages:

1. Draft the summary using the rules above.

2. Now review your draft against these criteria, one line each: every number has a source; every comparison names both periods; no claim goes beyond the data. List any failures. Don't rewrite yet.

3. Fix only the failures you listed.

The middle step is the useful one. It turns a vague "check your work" into named criteria the model can fail visibly, and it gives you a list to read before you accept the final version.

Here's an uncomfortable finding for anyone who thinks prompting is mostly wording. Apple researchers added one plausible-sounding but irrelevant clause to grade-school maths problems. Accuracy fell by up to 65%; GPT-4o dropped from 95.2% to 63.1% (Mirzadeh et al., GSM-Symbolic, 2024). Real work prompts are full of irrelevant clauses: the column nobody uses, the note about last year's reorg.

The flip side is that good technique can make a wrong answer look better. A well-structured prompt gets you a well-structured response, with headings, a table and a confident summary, whether or not the numbers in it are right. Polish is what the techniques are best at. That's why the vendors pair them with verification: OpenAI's GPT-5.5 guide asks the model to "run the most relevant validation available", and Anthropic's hallucination guide ends with "Always validate critical information" (Anthropic, Reduce hallucinations).

A two-minute check on any prompted answer

1. Strip the noise and rerun. Delete anything from the prompt that isn't needed for the task. If the answer changes, the extra text was steering it.
2. Look for the decisions. Which definitions, filters or periods did the model pick? If it didn't say, ask: "What choices did you make that I didn't specify?"
3. Recompute one number from the source, by hand or in a spreadsheet.
4. Run it twice. Anthropic notes that inconsistencies across repeated outputs "could indicate hallucinations".

Point two is where most errors hide, and it's what Count is built for: connect it to Claude or ChatGPT and it separates each claim from the assumption, source or model memory it rests on, so you can see the choices the model made without asking for them.

Some prompt habits outlived the models they were written for.

• Capital-letter threats. "CRITICAL", "YOU MUST", "NEVER". Anthropic says newer Claude models are more responsive to the system prompt and may now over-apply such rules; plain language works. OpenAI says to reserve ALWAYS and NEVER for true invariants.
• Prefilled answers. Starting the model's reply for it was a favourite trick for forcing JSON. From Claude 4.6 models, prefilled assistant turns "are no longer supported"; use structured outputs instead.
• Thinking-budget hacks. Long "think about X, then Y, then Z" scaffolds now duplicate what the effort setting does. On Claude 4.7 and later, the old budget_tokens parameter returns an error.
• The mega-prompt. OpenAI's advice for GPT-5.5 is to "avoid carrying over every instruction from an older prompt stack". If a rule was added to fix a 2024 model's quirk, test whether you still need it. How to optimise a prompt covers doing that systematically.

The techniques that last are the ones a sharp new colleague would also need: a clear brief, a reason, an example, and the material in order.

What are the main prompt engineering techniques?

What is few-shot prompting?

Is chain-of-thought prompting still useful?

What is AI prompt engineering?