Prompt Engineering Techniques That Work in Any AI Chat

The prompt engineering techniques that work in any AI chat come down to five habits: be specific about the task, give the context the model can't guess, show an example of a good answer, structure the prompt with clear sections, and ask for the output format you want. Do those five and most weak answers get better without any tricks.

The rest of this page covers each habit with a template you can paste, plus the more advanced moves: chain of thought, prompt chaining, and iterating when an answer is off. The advice is model-neutral unless I say otherwise. Where a point comes from a specific vendor's docs, I name it.

Prompt engineering techniques list#

People ask how many prompt engineering techniques there are. There's no official count. Different docs group them differently. Anthropic's overview mentions clarity, examples, XML structuring, role prompting, thinking, and prompt chaining. Google's Gemini guide covers constraints, prefix completion, zero-shot versus few-shot, breaking prompts into components, and iteration strategies. Those overlap a lot, so here's a working list:

That's the whole toolbox. The sections below go through the ones that pay off most.

Be specific and give context#

A vague prompt forces the model to guess your audience, length, and goal. Google's guide puts it as: state your goal clearly and concisely, and explicitly explain any ambiguous terms or parameters.

Compare these two:

Weak:   Write something about caching.
Better: Explain HTTP caching headers to a junior frontend developer.
        Cover Cache-Control and ETag only. Max 200 words. No analogies.

The second one names the audience, the scope, the length, and one thing to avoid. Context works the same way. If the answer depends on your stack, your readers, or a document, put that in the prompt. The model can't see your screen.

A note on long inputs. Google's guidance for Gemini is to supply the large context (documents, code) first and put your specific question at the very end, then bridge with a phrase like "Based on the information above...". I find that order sensible for any chat tool, though I'd treat it as a default to test rather than a law.

One more point from the Claude docs: before you tune a prompt, define what success looks like and have some way to test against it. Otherwise you're just rewording and hoping.

Template 1: the specific task prompt#

Task: [WHAT YOU WANT DONE, ONE SENTENCE]
Audience: [WHO WILL READ OR USE THE RESULT]
Context: [FACTS THE MODEL CAN'T KNOW: STACK, CONSTRAINTS, BACKGROUND]
Constraints: [LENGTH, SCOPE, THINGS TO AVOID]
Output format: [BULLETS / TABLE / JSON / CODE BLOCK]

Why it's worded this way: each line answers one question the model would otherwise guess at. Labeled lines also make it easy to see which one you left empty when the answer disappoints.

Show examples (few-shot prompting)#

An example is often clearer than a paragraph of instructions. A prompt with no examples is zero-shot. A prompt with a few is few-shot. Google's docs say few-shot prompts are often used to regulate formatting, phrasing, scoping, or general patterning, and that you can sometimes remove instructions if your examples show the task clearly enough.

Two gotchas from the same guide:

• Keep the format identical across examples. Pay attention to tags, whitespace, newlines, and separators. If your examples disagree with each other, the output will too.
• Don't pile them on. Too many examples can cause the model to overfit its response to them. Start with two or three, varied, and adjust.

Template 2: few-shot classifier#

Classify each support message as one of: bug, billing, feature-request.
Reply with the label only.

Message: "The export button does nothing when I click it."
Label: bug

Message: "Can you add dark mode?"
Label: feature-request

Message: "[YOUR MESSAGE]"
Label:

Why it's worded this way: the instruction names the allowed labels, the examples fix the format, and ending on Label: invites the model to complete the pattern rather than chat about it. Google's docs call this a completion strategy, where you start the output and let the model continue.

Structure the prompt#

Once a prompt has instructions, data, and examples mixed together, the model can confuse which is which. Delimiters fix that. Google's guide recommends XML-style tags (like <context> and <task>) or Markdown headings, and says to pick one and stay consistent within a prompt. Anthropic's docs also list XML structuring among their core techniques.

<role>
You are a careful code reviewer.
</role>

<constraints>
1. Be objective.
2. Point to the exact line.
</constraints>

<context>
[PASTE CODE HERE]
</context>

<task>
List the three most serious problems.
</task>

The pasted code sits inside <context>, so the model treats it as material, not as instructions. That also helps if the pasted text happens to contain sentences that sound like commands.

The same Google guide suggests putting critical constraints, the role, and format requirements at the very beginning of the prompt (or in the system instruction, if your tool has one).

Here's a small script that assembles a structured prompt from parts and warns you about empty sections. It's plain Python, so you can adapt it for your own templates.

parts = {
    "role": "You are a careful code reviewer.",
    "constraints": "1. Be objective.\n2. Point to the exact line.",
    "context": "def add(a, b):\n    return a - b",
    "task": "List the most serious problem.",
    "format": "",
}

missing = [name for name, text in parts.items() if not text.strip()]
prompt = "\n\n".join(
    f"<{name}>\n{text}\n</{name}>" for name, text in parts.items() if text.strip()
)

print(prompt)
if missing:
    print("\nEmpty sections:", ", ".join(missing))

Ask for a format#

If you don't specify a format, the model picks one. Google's hummingbird example shows this: ask for an essay outline with no format and you get whatever the model likes. Start the outline yourself (I. Introduction followed by a bullet) and it continues in your pattern.

Practical ways to pin down the output:

• Name the container: table, numbered list, JSON, single code block.
• List the fields. For JSON, name the keys and say what to do with missing values. In Google's order example, giving a sample showed the model to omit items that weren't ordered.
• Say what to leave out, such as preamble or explanations.
• For complex JSON schemas, Google recommends using the Gemini API's structured output feature instead of describing the shape in prose. That applies if you're calling the API, not just chatting.
• Control length. Gemini 3 models give direct, efficient answers by default, so if you want more detail or a conversational tone, say so explicitly.

Template 3: format-first prompt#

[YOUR QUESTION OR TASK]

Return a markdown table with the columns: [COLUMN 1], [COLUMN 2], [COLUMN 3].
One row per [ITEM]. No text before or after the table.
If a value is unknown, write "unknown" instead of guessing.

Why it's worded this way: the column names are the schema, "no text before or after" removes the chatty wrapper, and the unknown rule gives the model a safe exit instead of an invented value.

Prompt engineering techniques for chatgpt, Claude and Gemini#

The five habits above carry over between tools. Differences show up mostly in tuning, not in basics. Anthropic notes that its Prompting best practices page is the living reference for Claude's latest models, and that its older GitHub tutorial was written for Claude 3 models, so follow the best practices page where the two differ. Google's guide has Gemini-specific notes, such as the verbosity default mentioned earlier. I haven't pulled OpenAI documentation for this page, so for ChatGPT I'd test the same habits and check OpenAI's own prompting docs for model-specific changes.

If you want hands-on practice, Anthropic points to a GitHub prompting tutorial and a lighter Google Sheets version. Those are the closest things to a free walkthrough. For a PDF, save the vendor pages themselves; they're updated more often than any third-party PDF.

Chain of thought and prompt chaining#

Chain of thought means asking the model to work through a problem in steps before it answers. Anthropic's overview lists "thinking" among its techniques, but the pack I'm working from doesn't give exact wording or settings, so I won't invent any. My advice, as advice: for math, logic, or tradeoffs, add a line such as "Work through the steps first, then give the final answer on its own line." If your tool has a built-in reasoning mode, try that before hand-writing the steps, and compare.

Prompt chaining is different. It splits one big task into several prompts, where each output feeds the next. Google's guide describes three patterns:

• Break down instructions: one prompt per instruction, routed by the user's input.
• Chain prompts: step one's output becomes step two's input.
• Aggregate responses: run parallel tasks on different parts of the data, then combine.

Template 4: two-step chain#

Step 1 prompt:
List every factual claim in the text below as a numbered list. Do not judge them yet.
<text>[PASTE TEXT]</text>

Step 2 prompt:
For each claim in the list below, mark it as "needs a source" or "common knowledge".
<claims>[PASTE STEP 1 OUTPUT]</claims>

Why it's split: each step has one job, so you can check the intermediate list before it feeds the next prompt.

When the answer is still wrong#

Google lists three iteration moves worth trying:

1. Rephrase. Different wording of the same request can produce different responses.
2. Switch to an analogous task. In their example, a plain classification question got a correct but wordy answer. Rewriting it as a multiple-choice problem got a short one.
3. Reorder the content. Move examples, context, and input around and compare.

Anthropic adds a reminder that not every failing result is a prompt problem. Latency and cost, for instance, can sometimes be improved more easily by picking a different model.

A habit I'd suggest if you want a "prompt journal": keep a plain text file with the prompt, the model, and a one-line note on what was wrong with the output. After a few weeks you'll see which of your own habits keep causing misses. It's just a log, nothing more.

Common mistakes#

• Burying the ask. A one-line question at the top of a wall of pasted text gets lost. Put the task last for long context, or first with clear tags.
• Mixing delimiters. Switching between XML tags, Markdown, and plain dashes in one prompt makes the structure harder to read for the model. Pick one.
• Inconsistent examples. If example outputs differ in format, expect the answer to differ.
• Overlong persuasion. Google's core principles say to avoid unnecessary or overly persuasive language. Capital letters and pleading rarely add information.
• Skipping the test. Changing wording without a way to judge the result is guessing. Write down what a good answer looks like first.
• Using prompts for a model problem. If the task is simply beyond a model, rewording won't fix it.

Quick checklist#

• Is the task stated in one clear sentence?
• Did I say who the answer is for?
• Is the missing context pasted in, not assumed?
• Are limits on length, scope, and style written down?
• Do I have two or three consistent examples if the format matters?
• Are instructions separated from data with one kind of delimiter?
• Did I name the output format, and what to leave out?
• For complex jobs, can I split it into steps?
• Do I know how I'll judge whether the answer is good?

For the vendor references, see Anthropic's prompt engineering overview and Google's prompt design strategies.

Quick answers

Saved you an hour? Send a tip.

USDC or ETH on Base. Keeps the notes free and the examples running.

Base

USDCETH

$2$5$10 Other amount in USDC, from 1 to 1000$

0x9dFD2Ee86182f92464b50809C6702B999a0Cd54f Copy

Open in wallet · 5 USDC

On a computer? Scan the code with your phone wallet, or copy the address.

USDC or ETH on Base works best. Other tokens on Base, Ethereum or Arbitrum also reach this address. Tips are optional and unlock nothing; every guide stays free.