Most prompting advice is cargo cult. People found a phrase that worked once, wrote it down, and now there are lists of forty “power prompts” circulating that mostly do nothing.
A smaller set of techniques reliably changes output quality. They work for an understandable reason, which is the useful test: if nobody can tell you why a technique should work, it is probably folklore.
The core idea everything else follows from
A model is continuing a document. Your prompt establishes what kind of document this is, and it continues in the manner that document implies.
That framing predicts most of what follows. A vague prompt describes a generic document, so you get generic text. A prompt that establishes a specific situation, audience and format describes a specific document, and you get that instead.
You are not issuing commands. You are setting up a context in which the good answer is the likely continuation.
The techniques that actually work
1. Say what it is for
The single highest-value habit, and the most commonly skipped.
Write about our new feature.
versus
Write a 150-word changelog entry for our new bulk export feature. Audience: existing customers, technically comfortable, they already know what export does. Tone: matter-of-fact, no marketing language. Cover what changed and what they need to do differently — nothing else.
The second is not “better written”. It eliminates dozens of decisions the model would otherwise make badly, because with no information about audience or format, the average of all possible answers is the safest one — which is why unspecified prompts produce that recognisable middle-of-the-road tone.
2. Give it the material
Pasting in the actual document, code, or data changes the task from recall to read, and recall is where fabrication comes from.
This is worth more than any phrasing trick. A mediocre prompt with the real source beats an elegant prompt without it, every time.
3. Show one example
Two sentences of “here is the style I want” is worth several paragraphs of describing it. One good example usually beats three mediocre ones, and the format of your example matters more than its content — if the examples are bullet lists, you are getting bullet lists.
Watch for over-copying: if all your examples share an incidental feature, the output will have it too.
4. Let it work before it answers
For anything with reasoning — maths, logic, diagnosis, planning — asking for the reasoning before the conclusion genuinely improves the conclusion. The model is generating one token at a time with no scratchpad; the visible reasoning is the scratchpad.
This is the real basis of “think step by step”. It is not a magic phrase; it just requests that the working comes before the answer. Asking for a conclusion first and justification after gets you a guess plus a rationalisation.
Newer reasoning models do this internally and need the instruction less. It still does not hurt.
5. Constrain the output shape
“Answer in three bullets.” “Return only valid JSON, no commentary.” “Maximum 100 words.” “Use a table with these columns.”
Free-form output drifts toward padding — the preamble, the caveat, the summary of what it just said — because that is what the training data does. A specified shape removes it.
6. Say what you don’t want
Models default to hedging, throat-clearing, and enthusiasm. If you do not want those, say so.
No introduction. No summary at the end. Do not restate the question. Do not hedge — if you are uncertain say so once, briefly, and move on.
Bluntly effective, and reusable across almost everything.
7. Permit uncertainty
If you are not confident about something, say so rather than guessing.
Without this, a guess and a fact come out in the same confident register. It does not eliminate fabrication, but it makes the confident-wrong answer noticeably less common.
8. Iterate rather than restart
The most common mistake is rewriting the whole prompt when one part was wrong. Say what to change:
Good structure. Second point is wrong — we do not support SSO. Cut it and expand the third.
You keep everything that worked. This is also just faster.
9. Split the task
One prompt that outlines, drafts, and edits produces a mediocre version of all three. Three prompts produce three good ones, and you can fix the outline before any drafting happens — which is where most rework comes from.
10. Start fresh when it goes wrong
Once a conversation contains a bad answer, that answer is context, and the model is continuing a document in which it has already done the thing badly. Corrections often produce apologetic variations of the same mistake.
Open a new conversation with a better prompt. Faster than arguing.
What does not work
“You are a world-class expert with 20 years of experience.” Assigning a broad persona does very little on modern models. Specifying audience and format does a lot. “Explain this to a developer who knows Python but not ML” works because it says what the output should be — the useful part was never the roleplay.
Politeness, threats, or offering money. Perennially popular, no reliable effect. Be polite because you want to, not as technique.
“Don’t hallucinate.” The model cannot detect the state you are asking it to avoid.
“Are you sure?” Produces agreement or apology depending on your tone, not verification. Check it yourself, or ask the same question in a fresh conversation and compare.
Enormous stacked prompts. Twenty instructions produce inconsistent adherence to all twenty. The important ones get diluted. Five instructions that matter beat twenty that mostly do not.
Emphatic capitals and exclamation marks. IMPORTANT!!! adds nothing that stating the requirement once does not.
A structure worth reusing
Not a magic template — a checklist of the things worth specifying.
[Task] One sentence. What you want, concretely.
[Context] The material. Paste the actual document, code, or data.
[Audience] Who reads this and what they already know.
[Format] Length, structure, and what to leave out.
[Example] One sample of the style, if you have one.
[Bounds] What to avoid. Permission to say "I don't know".Worked example:
Rewrite the error message below so a non-technical user knows what to do.
Current message:
"ERR_CONN_REFUSED: upstream timeout at gateway (503)"
Audience: small business owners using our billing dashboard. Non-technical.
Format: two sentences maximum. Plain language. Say what happened and the one
thing they should do next. No apology paragraph, no error code.
If you need information I have not given you to write this well, ask instead
of guessing.That last line is worth adding to a lot of prompts. It converts a confident wrong answer into a question, which is a much better outcome.
Where prompting stops being the answer
Sometimes the prompt is not the problem.
- It lacks information. No phrasing fixes a missing document. Give it the material.
- The task needs current facts. Prompting cannot retrieve; you need search, or you need to paste the current source in yourself.
- The context is full. Long conversations degrade. Start fresh with a summary rather than fighting it.
- You are doing it forty times a week. That is a workflow, not a prompt. Save it, template it, or automate it.
The short version
Say what it is for. Give it the material. Show one example. Ask for the working before the answer. Specify the shape. Say what you don’t want. Allow “I don’t know”. Iterate instead of restarting. Split big tasks. Start fresh when it derails.
Ten habits, no incantations. Most people already know two or three of them, and adding the rest is worth more than any list of forty magic prompts.