Prompting techniques aren't a curriculum to work through. Each one is the answer to a specific problem — and if you don't have that problem, the technique is just extra words.
Every list of prompting techniques has the same shape: a numbered inventory of named methods, each with a definition and an example, presented as things to learn. Chain of thought. Few-shot. Role prompting. Self-consistency. Tree of thought.
Almost nobody uses more than two of them, and the reason isn't laziness. It's that a technique only helps when you're having the problem it was built for. Learned as a list, they're trivia. Learned as answers, they're a small toolkit you'll actually reach for.
So this page is organized by the problem, not by the name. Find the thing that's going wrong; the technique is underneath it.
First, check it's a technique problem at all
Most disappointing answers are not waiting for a clever method. They're waiting for outcome, context and output — a result named, the facts that would change the answer supplied, the shape described.
Run those three before reaching for anything on this page. Techniques are what you add when the basics are in place and something specific is still off. Reaching for a technique first is how people end up with elaborate prompts that underperform simple ones.
The model doesn't know what "good" means here
You've described the style, the tone, the standard — carefully — and what comes back is close to nothing you'd have written. This is the most common technique-shaped problem, and description is not the fix. More description makes it worse.
Show examples instead. Two or three, varied in everything except the dimension you're demonstrating. This is what "few-shot" means, and it takes less space than the paragraph of tone notes it replaces. Zero-shot vs few-shot, and what examples teach by accident.
The trigger to remember: if you're on your third sentence of describing a quality, stop describing and start showing.
The answer is right but shapeless
Accurate, relevant, and three times longer than you wanted, in prose where you needed a table, with a closing summary you'll delete every single time.
Constrain it. A number for size, a rule for vocabulary, a required structure, and an explicit list of things never to include. Prohibitions are the highest-return half and the part people skip. How to add constraints.
The trigger: any time you catch yourself editing the same thing out of the output twice, that edit should have been a constraint.
You need a reaction, not a draft
Sometimes the thing you want isn't more writing. It's to know how the email will land, where the proposal loses someone, what objection comes first.
Give it a reader with a motive. Not "you are an expert reviewer" — a specific person with a specific reason to be unimpressed. "Read this as a CFO with ninety seconds who's looking for a reason to say no." When role prompting helps and when it's noise.
The trigger: you're about to send something and you're slightly nervous about it. That nervousness is a question a role can answer.
It keeps dropping one of your requirements
You've stated the requirement, restated it, put it in capitals, and the answer still ignores it. Emphasis isn't the problem — density is. Past a certain number of instructions in a single request, compliance gets unreliable, and the one that slips is rarely the one you'd have sacrificed.
Split the request. Run two prompts in sequence, with the first one's output as the second one's input. Draft, then edit. Generate, then filter. This is the technique with the worst name-to-usefulness ratio in the field — it gets called prompt chaining, and it's mostly just doing one thing at a time.
Concretely, a meeting-notes task that keeps losing the owner of each action item becomes two:
Prompt 1 — From the notes below, list every decision that was made and who owns it. No commentary, no formatting.
Prompt 2 — Here's that list. Turn the three with the earliest deadlines into a short update for the team. Under 100 words, no preamble.
Each prompt has one job. Neither can drop a requirement, because neither is carrying more than one. It's slower to type and faster to finish.
The trigger: four or more distinct instructions and a persistent miss.
What isn't a technique
Worth saying plainly, because a lot of what circulates under this heading doesn't survive contact with testing.
Magic phrases. "Take a deep breath." "Think step by step" pasted onto a task that involves no steps. These had real effects on older models and specific benchmarks; on a current model with a well-specified request, they mostly don't move anything. If you use one, test it with and without.
Incentives and threats. Offering a tip, claiming your job depends on it, insisting this is very important. There's nothing to receive an incentive. What these sometimes do is raise the perceived stakes in a way that produces longer, more hedged answers — which is usually not the improvement people are after.
Politeness, in either direction. Please and thank you cost nothing and change nothing. Being curt doesn't help either. Write however you prefer.
The test for anything you read about: run it twice, once with and once without, on a task you care about. Two minutes settles a question that a hundred confident posts online can't.
Choosing, in one question
When something's off, ask what kind of wrong it is.
Wrong content means the model lacked facts — that's context, not technique. Wrong character means it didn't know your standard — show examples. Wrong shape means it didn't know your format — constrain it. Wrong perspective means you needed a reader, not a writer — give it a role. And incomplete, repeatedly, means the request is carrying too much — split it.
Two of those five aren't technique problems at all, which is about the right proportion. Most of the time the fix is upstream of anything on this page.
The short version
Don't learn techniques as a list. Learn the four triggers: describing a quality for the third time, editing the same thing out twice, feeling nervous before sending, and watching a requirement get dropped again.
Each of those has one answer, and between them they cover almost everything that goes wrong after the basics are in place.