Quick Navigation
Foundation techniques — these apply to almost every prompt you write
- 1. Clarity — say exactly what you want
- 2. Role — give the model a persona
- 3. Context — feed it what it needs
- 4. Examples — show, don't just tell
- 5. Format — shape the output
- 6. Constraints — tell it what not to do
- 7. System prompts — set the stage
- 8. Iteration — prompting is a loop
Reasoning techniques — for complex, analytical, or multi-step tasks
- 9. Chain of Thought — make it reason out loud
- 10. Tree of Thought — explore before committing
- 11. Self-Consistency — vote on the best answer
- 12. Step-Back — zoom out first
- 13. Least-to-Most — build up from simple
Advanced techniques — for production systems, agentic workflows, maximum quality
Before we start — the one thing to get straight
Most people, when they get a bad output from AI, blame the AI.
Most of the time, the problem is the prompt.
Not because they used the wrong tool or the wrong model. Because they handed AI a vague task and expected a precise result — the same way you'd hand a new colleague a one-sentence request and expect them to read your mind about everything you didn't say.
AI doesn't read minds. Every gap in your prompt is a gap the model fills with its own assumptions. The 19 techniques in this guide are 19 different ways to close those gaps — deliberately, repeatably, and at a level of quality you can actually use.
Here's how they're organised:
flowchart TD
A["Prompt Engineering\n19 Techniques"] --> B["Foundation\nAlways useful"]
A --> C["Reasoning\nComplex tasks"]
A --> D["Advanced\nProduction and agentic"]
B --> B1["Clarity · Role · Context · Examples"]
B --> B2["Format · Constraints · System Prompts · Iteration"]
C --> C1["Chain of Thought · Tree of Thought · Self-Consistency"]
C --> C2["Step-Back Prompting · Least-to-Most"]
D --> D1["Prompt Chaining · Generated Knowledge · Self-Critique"]
D --> D2["Meta-Prompting · ReAct · Emotional Prompting"]
You don't need all 19 every time. Foundation techniques apply to almost every prompt. Reasoning techniques apply when the task has real complexity. Advanced techniques apply when you're building systems or need maximum quality.
Start with the foundation. Add the rest as the task demands.
Try it yourself — The prompt baseline
Take one prompt you've used recently that gave a disappointing result. Paste it here. Now identify what's missing:
| Element | Present? | What's missing |
|---|---|---|
| Clarity — specific ask | Yes / No | |
| Role — who should AI be? | Yes / No | |
| Context — background info | Yes / No | |
| Examples — show what good looks like | Yes / No | |
| Format — what should output look like? | Yes / No | |
| Constraints — what to avoid | Yes / No |
Rewrite the prompt with the missing elements. Run it. Compare the output.
Foundation Techniques
These eight techniques apply to almost every prompt you write. If your AI outputs are consistently disappointing, the fix is almost always in this tier.
1. Clarity — say exactly what you want
This sounds obvious. It almost never is.
The single most common reason AI output is generic, off-target, or frustrating is not that AI is bad — it's that the prompt was vague. When you leave something unspecified, the model doesn't flag it and ask. It fills the gap with whatever is most common in its training data. That default is rarely what you wanted.
Compare these two prompts:
"Write something about marketing."
"Write a 200-word LinkedIn post for a B2B SaaS company, aimed at CTOs, announcing a new AI feature that reduces deployment time by 40%."
The second prompt isn't longer because of padding. Every additional word is closing a gap that the first prompt left open — the format, the length, the platform, the audience, the topic, the angle. Each gap you close is a gap the model no longer has to guess.
Three questions that make any prompt clearer:
- What exactly do you want? (the task)
- Who is it for? (the audience)
- What does good look like? (the standard)
Answer those three in every prompt and you've eliminated most of the guesswork.
For the curious: Technically, a vague prompt produces a flat probability distribution over possible outputs — the model has many equally plausible directions to go. A specific prompt narrows that distribution sharply toward the output you actually want. More constraints = higher probability that the output matches your intent. That's the mechanism underneath all of prompt engineering.
Try it yourself — The clarity rewrite
Take one vague prompt you've used. Rewrite it using the three questions: what exactly do you want, who is it for, and what does good look like? Run both prompts. Compare the outputs. The difference is the value of clarity.
2. Role — give the model a persona
The same question gets very different answers depending on who's answering it. "Explain recursion" from a computer science professor sounds different from the same explanation from a senior engineer briefing a junior colleague on their first day — which sounds different again from a patient parent explaining it to a curious ten-year-old.
When you assign a role, the model shifts its tone, vocabulary, depth, and framing to match. It's not acting — it's sampling from a different part of everything it learned. The training data contains vast amounts of text produced by or about people in different roles, and the role assignment activates the patterns associated with that particular kind of expert.
Useful role patterns:
- "You are an expert [domain] consultant"
- "You are a sceptical editor who finds weaknesses"
- "You are a patient teacher explaining to someone with no background in this"
The role shapes everything that follows — tone, depth, what the model assumes you already know, what it explains and what it skips. It's one of the highest-leverage single additions to any prompt.
One caveat: roles work best when they're rich with training data. A "senior cardiologist" or "experienced software architect" will produce a noticeably different response than an obscure or made-up role that the model has seen few examples of.
Try it yourself — The role test
Take one prompt you use regularly. Run it three ways: no role, generic role ("You are an expert"), and specific role ("You are a sceptical editor"). Which role produced the best output? That's your default role for this task.
3. Context — feed it what it needs
AI has no memory between sessions and no knowledge of your specific situation. Without context, it answers a generic version of your question. With context, it answers your question.
This is the technique most people consistently underuse, and it has the most direct impact on output quality. If you've ever looked at an AI response and thought "this completely missed the point" — the most common reason is that you didn't give it enough context to know what the point was.
flowchart TD
subgraph NC["Without Context"]
Q1["'How should I respond to this email?'"]
Q1 --> R1["Can't help meaningfully.\nAnswers a generic version.\nNo email, no situation, no constraints."]
end
subgraph WC["With Context"]
Q2["'Client is unhappy about a delay on a software project.\nHere is the email: [pasted text].\nI want to apologise sincerely without admitting legal fault.\nOur relationship with this client is important.'"]
Q2 --> R2["Specific, situation-aware draft.\nTone calibrated · Legal nuance considered.\nRelationship preserved."]
end
Context types that almost always improve output:
- Your role — "I'm a product manager at a fintech startup"
- The goal — "I need this to convince sceptical executives who are sceptical of AI"
- Background — paste in the relevant document, code, data, or email
- Constraints — "We cannot offer refunds; the client is in Germany"
A practical habit: before sending any prompt, ask yourself — what would a new colleague need to know to do this task well? Whatever comes to mind, put it in the prompt.
One thing worth knowing: context has a limit. Every model has a context window — the maximum amount of text it can hold in focus at once. For long documents, you may need to summarise or chunk before pasting. But for most everyday tasks, the constraint is how much context you think to provide, not how much the model can handle.
4. Examples — show, don't just tell
Describing what you want in words is harder than it sounds. Showing it is almost always easier and more effective.
When you include examples of the kind of output you want, the model reverse-engineers your standard — tone, format, length, style, level of detail — and matches it. This works because the model is extraordinarily good at recognising patterns and reproducing them. One good example teaches it more about your standard than a paragraph of description.
The spectrum looks like this:
- Zero-shot — task description only. Model uses its own defaults. Works for generic tasks.
- One-shot — task description plus one example. Model approximates your standard.
- Few-shot — task description plus two to five examples. Model matches your standard closely — tone, format, length, and all.
flowchart TD
Z["Zero-Shot\nTask description only"]
O["One-Shot\nTask + 1 example"]
F["Few-Shot\nTask + 2–5 examples"]
Z --> ZR["Model uses its own defaults\nRarely matches your standard"]
O --> OR["Model approximates your standard\nOne pattern to match"]
F --> FR["Model matches your standard\nTone · format · length · style all calibrated"]
The most powerful form: input-output pairs. Show the model an example of what you'd give it, followed by what you'd want back. Two or three good examples of this kind will calibrate it more precisely than almost any description.
Quality matters more than quantity. Two great examples beat ten mediocre ones — because mediocre examples teach the model a mediocre standard.
5. Format — shape the output
A great answer in the wrong format is still a usability failure. If you need a comparison table and you get four paragraphs, you've gotten a bad output — even if the content is accurate.
If you don't specify format, the model chooses based on what's most common in its training data for that type of task. That default is often a dense paragraph. Dense paragraphs are rarely what anyone needed.
flowchart TD
CONTENT["Same Content — different containers"]
CONTENT --> F1["Dense paragraph\nHard to scan"]
CONTENT --> F2["Bullet list\nEasy to scan · can lose nuance"]
CONTENT --> F3["Table\nIdeal for comparison"]
CONTENT --> F4["Numbered list\nIdeal for steps"]
CONTENT --> F5["Markdown\nIdeal for documents"]
CONTENT --> F6["JSON\nIdeal for code and APIs"]
Specifying format takes five seconds and saves multiple rounds of reformatting. Include it in any prompt where the output will be longer than a paragraph.
Common format instructions that work well:
- "Respond in markdown with H2 headers for each section"
- "Give your answer as a table with columns: Option | Pros | Cons | Verdict"
- "Return only a JSON object with keys: title, summary, tags"
- "Limit to five bullet points, each under twenty words"
- "Write in short paragraphs with no headers — this is for a casual email"
The right format depends on how the output will be used. A comparison → table. A sequence of steps → numbered list. A document for executives → short paragraphs with headers. Code to be parsed programmatically → JSON.
6. Constraints — tell it what not to do
Knowing what you want is not enough. You also need to tell the model what to avoid — because without negative constraints, it defaults to its most common training patterns. And those patterns often include things you'd rather not have.
The most persistent defaults worth knowing about: models tend to start with a preamble (restating the task or introducing the topic). They add caveats ("please consult a professional for..."). They use corporate jargon ("leverage," "synergize," "circle back"). They end with a summary or conclusion. They hedge everything.
None of those are necessary for most tasks. And none of them will disappear unless you explicitly say so.
Some constraints worth keeping in rotation:
- "Do not start with an introduction — begin directly with the content"
- "Do not add disclaimers or recommend consulting a professional"
- "Write in plain language — avoid 'leverage', 'synergy', 'ecosystem'"
- "Do not repeat back what I asked — just answer"
- "Do not speculate — only use information I've provided"
Pair constraints with positive instructions. "Write in plain prose, no bullet points" is stronger than "no bullet points" alone — the positive instruction gives the model a direction, and the constraint removes the temptation to default.
7. System prompts — set the stage
Repeating your role, context, and constraints in every prompt is inefficient. It's also inconsistent — different team members will write those parts differently, producing different outputs from the same underlying need.
System prompts solve this. They let you define the model's persistent behaviour — its persona, its rules, its defaults — once, before the conversation begins. Everything that follows happens inside that frame.
flowchart TD
SP["System Prompt\n'You are a precise legal document reviewer.\nYou identify ambiguous language and flag missing clauses.\nYou do not give general legal advice.\nYou respond in bullet points grouped by risk level:\nHigh · Medium · Low.'"]
SP --> U1["User: Review this NDA."]
SP --> U2["User: Check this employment contract."]
SP --> U3["User: Any issues with this SLA?"]
U1 --> OUT["Every response:\nBulleted · Risk-grouped · Specific\nNo general advice · Consistent\nacross every user and every session"]
U2 --> OUT
U3 --> OUT
A good system prompt has five parts:
- Persona — who the model is and at what level of expertise ("You are a senior data analyst")
- Audience — who it's talking to ("You are talking to non-technical project managers")
- Behaviour rules — how it should respond ("Always ask one clarifying question before advising")
- Format defaults — the structure of its outputs ("Respond in markdown with headers")
- Hard constraints — what it must never do ("Never speculate beyond the data provided")
System prompts are where teams go from ad-hoc AI use to reliable, repeatable workflows. If your team's AI outputs vary wildly depending on who's prompting — a shared set of system prompts is the fix.
8. Iteration — prompting is a loop
Expecting a perfect result from a first prompt is like expecting a perfect first draft. It occasionally happens. It's not the plan.
The best prompt engineers treat prompting as a dialogue — they evaluate the output, identify what's missing or wrong, and refine until they get what they need. This isn't a failure of skill. It's the actual process.
flowchart LR
A["Write Prompt"] --> B["Get Output"]
B --> C{"Good Enough?"}
C -- Yes --> D["Done"]
C -- No --> E["Identify the Gap\nToo generic?\nWrong tone?\nWrong format?\nMissed the point?"]
E --> F["Apply the Fix\nAdd context · Adjust role\nAdd format · Add constraint"]
F --> A
The diagnostic that makes iteration faster: when the output isn't right, identify why before reaching for a fix. The six most common problems and their causes:
| Problem | Likely cause | Fix |
|---|---|---|
| Output is too generic | Not enough context | Add background, goals, audience |
| Wrong tone or style | No role or example | Add role + one-shot example |
| Wrong format | No format instruction | Specify format explicitly |
| Misses the point | Task was ambiguous | Restate the task more precisely |
| Adds unwanted content | No negative constraints | Add "do not include X" |
| Inconsistent results | Prompt is underspecified | Add constraints until behaviour stabilises |
Each technique in this guide is a lever you can pull during iteration. Iteration is how you discover which lever is missing.
Reasoning Techniques
These five techniques improve accuracy on complex, multi-step, or analytical tasks. The difference between using them and not using them is most visible when the stakes are high.
9. Chain of Thought — make it reason out loud
Here's something most people don't realise about LLMs: they don't natively "think through" a problem before answering. They predict the next token. Without guidance, they go from your question directly to an output — skipping the intermediate reasoning that would catch errors.
Chain of Thought changes that. When you ask the model to reason step by step before giving a final answer, it generates intermediate reasoning steps that actually condition a better final answer. The scratchpad is real — it changes what the model produces.
flowchart LR
subgraph WITHOUT["Without Chain of Thought"]
P1["Problem"] -->|"One hop\nHigh error rate"| ANS1["Shallow answer\noften wrong"]
end
subgraph WITH["With Chain of Thought"]
P2["Problem"] --> S1["Step 1\nIdentify factors"] --> S2["Step 2\nAnalyse tradeoffs"] --> S3["Step 3\nWeigh evidence"] --> ANS2["Well-reasoned answer\nlower error rate"]
end
The trigger is simple. Add any of these to your prompt:
- "Think step by step before answering"
- "Before answering, list your assumptions"
- "Show your reasoning, then give your conclusion"
- "What are the key factors? Then give a recommendation."
This works on: maths, debugging, decisions with tradeoffs, argument analysis, and any problem with multiple interacting factors. For simple factual questions, it's overkill. For anything complex, it's usually the highest-value single addition to any prompt.
10. Tree of Thought — explore before committing
Chain of Thought follows one reasoning path. Some problems need multiple paths explored before you commit to one.
Tree of Thought asks the model to generate several different approaches, evaluate each one, and then select and develop the best. It mirrors what a thoughtful human does on hard problems: sketch a few directions, evaluate which one is most promising, then go deep on that one.
flowchart TD
P["Problem\n'Reduce infrastructure costs by 30%.'"]
P --> A["Approach A\nMigrate to cheaper cloud tier"]
P --> B["Approach B\nRight-size idle resources"]
P --> C["Approach C\nMove to reserved instances"]
A --> A1["Risk: service degradation\nImpact: medium · Timeline: 2 months"]
B --> B1["Risk: low\nImpact: high · Timeline: 2 weeks"]
C --> C1["Risk: medium\nImpact: high · Timeline: 1 month"]
A1 --> E{"Evaluate all branches"}
B1 --> E
C1 --> E
E -->|"Best: low risk + high impact + fast"| W["Fully develop Approach B"]
Use Tree of Thought when: the problem has multiple valid starting points, you're making a high-stakes decision, or Chain of Thought keeps giving you one-dimensional answers that feel like they're missing something.
The simplest implementation: in one prompt, ask the model to generate three distinct approaches, evaluate each on feasibility, risk, and impact, then select and develop the strongest one.
11. Self-Consistency — vote on the best answer
A single Chain of Thought run is influenced by the randomness built into how the model samples its outputs. Run the same prompt once and it might get it right. Run it again and it might take a different path to a different conclusion. Neither run is "the truth" — they're samples from a distribution.
Self-Consistency takes advantage of that. Run the same prompt multiple times, collect the answers, and take the majority vote. The most frequent answer across several independent reasoning paths is almost always more reliable than any single run.
flowchart LR
Q["Same Prompt\nrun 5 times"]
Q --> R1["Run 1 → Option B"]
Q --> R2["Run 2 → Option B"]
Q --> R3["Run 3 → Option A"]
Q --> R4["Run 4 → Option B"]
Q --> R5["Run 5 → Option B"]
R1 --> V{"Majority Vote"}
R2 --> V
R3 --> V
R4 --> V
R5 --> V
V --> ANS["Option B\n4 of 5 agree\nHigh confidence"]
This is especially useful for: maths problems, logic puzzles, classification tasks, and any question with a verifiable right answer where a single wrong run would be costly.
12. Step-Back — zoom out first
LLMs sometimes fail on specific questions because they dive into the detail before establishing the right framework. They pattern-match to the first plausible interpretation of your question and run with it — even when a broader view would produce a better answer.
Step-Back addresses this by asking a more general version of your question first, establishing the conceptual framework, and then applying that framework to your specific problem.
Step-Back is valuable whenever you're debugging, diagnosing, analysing failures, or when the model keeps jumping to the wrong conclusion. The first prompt establishes the map. The second finds your location on it.
13. Least-to-Most — build up from simple
Asking a model to solve a complex problem in one step often produces shallow answers. Not because the model can't handle the problem, but because it skips important sub-problems in the rush to produce an output.
Least-to-Most decomposes the complex problem into a sequence of simpler ones, solved in order from easiest to hardest. Each answer builds on the previous. The final answer is far more complete than if you'd asked the whole thing upfront.
flowchart TD
GOAL["Complex Goal\n'Build a data pipeline: clean, transform,\nload customer records into our warehouse'"]
S1["1. Define a clean record\nWhat fields are required?"]
S2["2. Identify transformations needed\nWhat does raw CRM data require?"]
S3["3. Write a function for one record\nClean it in Python"]
S4["4. Extend to batch processing\nHandle records efficiently"]
S5["5. Add production concerns\nError handling · Logging · Monitoring"]
GOAL --> S1
S1 -->|"scaffolds"| S2
S2 -->|"scaffolds"| S3
S3 -->|"scaffolds"| S4
S4 -->|"scaffolds"| S5
S5 --> DONE["Complete, well-grounded solution\nNo steps skipped"]
The two-phase approach: first, ask the model what sub-problems need to be solved to tackle the main problem. Then solve them in order, feeding each answer into the next prompt.
This mirrors good engineering practice. You don't build the roof before the walls. You don't write the code before you understand the data model. Least-to-Most enforces that discipline.
Advanced Techniques
These six techniques are for production systems, agentic workflows, and situations where you need maximum output quality. They're worth learning after the foundation is solid.
14. Prompt Chaining — one task per prompt
Complex tasks cannot be done well in a single prompt. Either the model loses track of the constraints partway through, or the context window fills up, or errors compound invisibly and appear only at the end where they're hard to trace.
Prompt Chaining breaks the task into a sequence of focused prompts where the output of each becomes the input of the next. Each prompt is small, focused, and verifiable. Errors are caught early, at the stage where they happened, rather than buried in a long output that has to be entirely rewritten.
Four principles that make chains work:
Single responsibility — each prompt does exactly one thing. If a prompt is doing two jobs, split it.
Explicit handoff — always paste or inject the previous output clearly. The model has no memory between prompts.
Checkpoints — review the output at each stage before passing it forward. A flawed output in step two creates a flawed foundation for every step that follows.
Error isolation — if output three is wrong, fix prompt three. Don't revise the whole chain.
Prompt chaining is the foundation of most production AI workflows. When someone says they've built an "AI system" that does something complex reliably — there's almost always a chain underneath it.
15. Generated Knowledge — prime before you ask
Sometimes the model has everything it needs to answer your question well — but it doesn't surface the most relevant knowledge before diving into the answer. The result is a response that's technically competent but misses the framework that would have made it genuinely useful.
Generated Knowledge addresses this by asking the model to surface relevant facts, principles, or considerations first — and then asking your actual question using that knowledge as context.
flowchart TD
Q["'Should we use microservices or a monolith\nfor our new product?'"]
subgraph WITHOUT["Without Generated Knowledge"]
DR["Ask directly"] --> GEN["Generic pros/cons list\nNo situational awareness"]
end
subgraph WITH["With Generated Knowledge"]
S1["Step 1 — Surface the factors\n'What are the most important technical\nand organisational factors for this\narchitecture decision?'"]
S1R["Team size · Deployment independence\nData coupling · Operational maturity\nIteration speed · Domain boundaries"]
S2["Step 2 — Apply to your situation\n'Given those factors, and given:\n5 engineers · early stage · single domain\nno platform team — what is right for us?'"]
OUTR["Specific, well-reasoned recommendation\ngrounded in the right framework"]
S1 --> S1R --> S2 --> OUTR
end
Q --> WITHOUT
Q --> WITH
The caution: generated knowledge can be wrong. The model is recalling from training data, not looking things up. For conceptual reasoning about well-established topics, it works well. For recent or highly specific factual claims, pair it with RAG or independent verification.
16. Self-Critique — make it review itself
The model's first output often has flaws it could catch if asked to look. This isn't inconsistency — it's a real capability difference between generation mode and evaluation mode. The model can often detect in review what it didn't avoid in generation.
Self-Critique takes advantage of that. After getting an initial output, ask the model to critique it against specific criteria. Then ask it to revise based on its own critique.
flowchart LR
T["Task"] --> G["Round 1\nGenerate initial output"]
G --> C["Round 2\nCritique:\nVague claims? Missing info?\nWon't land with the audience?"]
C --> R["Round 3\nRevise based on critique"]
R --> Q{"Good enough?"}
Q -- Yes --> DONE["Final Output"]
Q -- No --> C
The critique prompt matters. Vague critique ("is this good?") produces vague improvement. Specific critique produces specific improvement. Some criteria worth having ready:
- "Identify any claims that might be factually wrong or unsupported"
- "Find sentences that are ambiguous or hard to understand"
- "What important points are missing?"
- "Would a sceptical CFO find this convincing? Why or why not?"
- "What could be removed without losing meaning?"
In production systems, this can be automated: generate → critique → revise → score → accept or loop. In daily use, a single critique round is often enough to catch the most significant issues.
17. Meta-Prompting — ask it to write the prompt
Writing a good prompt is harder than it looks. Sometimes you know what you want but not how to ask for it in a way that will actually work.
Meta-Prompting turns this around: ask the model to help you design or improve the prompt itself. Models are trained on vast amounts of text about writing, communication, and — increasingly — prompt engineering itself. They can apply that knowledge to improve your prompts the same way they can edit any piece of writing.
Meta-Prompting is especially useful when your iteration loop is stuck — you've tried several variations and can't work out what's wrong. Ask the model to diagnose. It often spots the issue faster than another round of trial and error.
18. ReAct — reason and act together
Standard AI assistants are closed systems. They answer from what they learned during training — which means they have a knowledge cutoff, can't access live data, and can't verify their own outputs against the real world.
ReAct opens that up. It interleaves two types of steps: Reason (think about what to do) and Act (use a tool — search the web, run code, call an API). The model reasons about what it needs, takes an action to get it, observes the result, and reasons again — repeating until the task is done.
For multi-step tasks, the loop continues until the task is complete:
flowchart LR
T["Thought\nWhat do I know?\nWhat do I need?"] --> A["Action\nTool call"]
A --> O["Observation\nTool result"]
O --> CHK{"Task complete?"}
CHK -- No --> T
CHK -- Yes --> ANS2["Final Answer"]
ReAct is the backbone of AI agents — systems that don't just answer questions but take actions: browsing the web, writing and running code, calling APIs, reading files, and interacting with external services. When you hear about "autonomous AI" or "AI that can use a computer" — ReAct (or something built on the same principle) is almost always what's underneath.
19. Emotional Prompting — set the stakes
This one is counterintuitive, which is why it belongs at the end.
Research has found that adding language communicating the importance or stakes of a task measurably improves output quality. Not by much on its own. But measurably.
The proposed explanation: the model's training data contains vast amounts of high-stakes professional writing — careful, thorough, precise. Stakes-framing language may activate those patterns, shifting the model toward the kind of careful attention those examples demonstrate.
Patterns that communicate stakes effectively:
- "This is going to our most important client"
- "A mistake here could affect thousands of users"
- "I know you can do an excellent job on this"
- "Apply the same rigour a senior partner would bring"
One important caveat: Emotional Prompting is an amplifier, not a foundation. It enhances a good prompt. It doesn't fix a bad one. If your prompt is missing clarity, context, or role — add those first. Stakes language layered on top of a well-constructed prompt is where it earns its place.
How to choose — the decision framework
You don't need all 19 techniques in every prompt. You need the right ones for the task in front of you. Here's how to decide:
flowchart TD
START["You need to write a prompt"]
START --> Q1{"Is output\nformat important?"}
Q1 -- Yes --> F["Add Format + Constraints"]
Q1 -- No --> Q2{"Will this be\nused repeatedly?"}
F --> Q2
Q2 -- Yes --> SP["Add System Prompt"]
Q2 -- No --> Q3{"Is the task\ncomplex or analytical?"}
SP --> Q3
Q3 -- Yes --> COT["Add Chain of Thought"]
Q3 -- No --> QUAL{"Need to\nmaximise quality?"}
COT --> BRANCH{"Multiple valid\napproaches?"}
BRANCH -- Yes --> TOT["Add Tree of Thought"]
BRANCH -- No --> SC{"High-stakes\nor critical?"}
TOT --> SC
SC -- Yes --> SCON["Add Self-Consistency\nrun multiple times + vote"]
SC -- No --> QUAL
SCON --> QUAL
QUAL -- Yes --> CRIT["Add Self-Critique\ngenerate · judge · improve"]
QUAL -- No --> DECOMP{"Can this break\ninto sub-tasks?"}
CRIT --> DECOMP
DECOMP -- Yes --> CH["Use Prompt Chaining\nor Least-to-Most"]
DECOMP -- No --> TOOLS{"Needs external\ndata or tools?"}
CH --> TOOLS
TOOLS -- Yes --> RA["Use ReAct"]
TOOLS -- No --> DONE
RA --> DONE["Layered, purposeful prompt\nwith exactly the right techniques"]
The framework in practice:
Foundation first. Clarity, Context, and Role make every other technique work better. Get these right before adding anything else — most prompting problems are foundation problems. Reasoning is a switch you flip. For any complex task, "think step by step" is the highest-value single addition to most prompts. It takes three seconds to add and regularly changes the quality of the output noticeably. Iteration is the meta-skill. No prompt is final. Write, evaluate, refine, repeat. The fastest path to a great output is a fast feedback loop, not a perfect first prompt.
Cheat Sheet — all 19 techniques
| Technique | Plain English | Technical name |
|---|---|---|
| Clarity | No gaps, no guessing | Prompt specificity |
| Role | Cast the right character | Persona / role prompting |
| Context | Don't make it guess what you know | Context injection / grounding |
| Examples | Show the destination, not just the direction | Few-shot prompting |
| Format | Specify the container before the content | Structured output specification |
| Constraints | Fence the garden, not just plant the seeds | Negative prompting |
| System Prompt | Standing orders before the mission begins | System message |
| Iteration | Your first prompt is a hypothesis | Prompt refinement / evals |
| Chain of Thought | Slow down to speed up accuracy | CoT prompting |
| Tree of Thought | Branch first, commit second | ToT prompting |
| Self-Consistency | Ask five times, trust the majority | Majority vote over CoT runs |
| Step-Back | Zoom out first, then zoom in | Abstraction-first prompting |
| Least-to-Most | Solve the easy parts first, stack them into the hard answer | Decomposition prompting |
| Prompt Chaining | One task per prompt, outputs become inputs | Pipeline / sequential prompting |
| Generated Knowledge | Warm up the relevant facts before the main question | Knowledge priming |
| Self-Critique | Generate, judge, improve | Reflection / Constitutional AI |
| Meta-Prompting | Ask the expert to write the brief | Automatic Prompt Engineering |
| ReAct | Reason → act → observe → reason again | Agentic tool-use loop |
| Emotional Prompting | Stakes raise standards | Affective / stakes framing |
How to know if this landed
You'll know this has landed when someone gets a bad output and diagnoses why — wrong format, missing context, no role — and fixes the right thing. When their prompts include role, context, format, and constraints without being reminded. When they add "think step by step" to complex tasks automatically and treat every AI interaction as a loop, not a transaction. When they've built a small library of prompts that work for their most common tasks through iteration, not luck. When they know when to use one technique and when to stack several. And when someone on their team gets a bad output, they can read the prompt and identify what's missing.
What the prompt rewrites always reveal
The most consistent thing I observe in prompt engineering workshops is that people come in thinking they have a technique problem and leave realising they have a foundation problem.
The single-sentence prompts — "summarise this," "write an email about X," "help me think through Y" — are almost universal at the start. By the end of day one, those same people are writing prompts that specify the audience, the format, the tone, what to avoid, and how they want the model to approach the task. The outputs are noticeably different. Not because they've unlocked some advanced technique. Because they've stopped leaving gaps.
The Chain of Thought moment is usually the most dramatic. I pick a task with genuine complexity — a multi-factor decision, a debugging problem, an argument analysis — and run it twice: once with a plain prompt, once with "think step by step." The difference in reasoning depth is visible on screen. People stop using single-step prompts for complex tasks immediately after seeing it.
The iteration habit takes longer to build. It's not that people don't understand it — it's that most people still treat a bad output as a failure rather than a data point. The mindset shift from "the AI got it wrong" to "my prompt was missing something" is the one that changes long-term behaviour. Once it clicks, the improvement is compounding — every bad output teaches you something about the prompt, which improves the next one.
The shared prompt library that teams build during the session is often the most immediately valuable output. Within a few weeks, the prompts that work for common tasks have been tested, refined, and are being used by everyone on the team. That's when AI starts to feel like a reliable tool rather than an inconsistent one.
Book a Workshop
Ready to make your team genuinely effective with AI — not just aware of it?
or
2-day workshop + 1 month follow-up includes interactive sessions on all 19 techniques across three tiers, live prompt rewrites using participants' own real work, team system prompt design for your most common workflows, a shared prompt library built during the session, prompt chaining and ReAct workshops for engineering teams, and follow-up office hours for production prompt challenges.