How to Write AI Prompts: A Complete Practical Guide

The one sentence that explains every bad output

A language model answers the question you asked, not the question you meant. That sounds obvious and it is the root of almost every disappointing result.

When you write "write a product description for our water bottle", you have a great deal of unstated context in your head: who buys it, where the text will appear, how long it should be, what your brand sounds like, which competitor you are trying to sound different from. The model has none of that. It fills the gaps with the statistical average of every product description it has ever seen, which is exactly what "generic AI output" is.

The skill of prompting is not knowing magic words. It is noticing what you have left unsaid. Everything below is a systematic way of noticing.

The five components of a working prompt

Almost every prompt that works contains these five things, whether or not the writer named them deliberately. Almost every prompt that fails is missing one.

• Role — who the model should be. "You are a paediatric nurse explaining to a parent" produces different vocabulary, different assumptions and a different level of hedging than the same question asked cold.
• Task — what to do, in one sentence, with no second instruction hiding inside it. If your task sentence contains "and then", you have two tasks.
• Context — what the model cannot infer: the audience, the purpose, the situation, the constraints of your world. This is the most commonly missing component by a wide margin.
• Constraints — length, tone, what to include, and crucially what to avoid. Exclusions are underused and unusually effective.
• Format — the exact shape of the answer. Sections, a table, a numbered list, JSON with named keys. Unspecified format is why the same prompt returns prose one day and bullets the next.

Write them in this order, not that order

Most people write a prompt front to back: role, then task, then whatever else occurs to them. There is a better order for thinking, even though the finished prompt still reads in the conventional sequence.

Start with the format. Ask yourself what the finished answer physically looks like — how long, what sections, what shape. This is uncomfortable because it forces you to decide what you actually want before you have asked for it, which is exactly why it works.

Then write the task in one sentence. Then add the context that a competent stranger would need to do the job. Then the constraints. Add the role last, because by then you know what kind of expertise the task calls for, rather than reaching for a generic "you are an expert" that does nothing.

• Format first — decide what the output looks like before you ask for it.
• Task second — one sentence, one job.
• Context third — what a competent stranger would need to know.
• Constraints fourth — length, tone, exclusions.
• Role last — chosen to match the work, not bolted on out of habit.

Specific beats descriptive, always

The single highest-leverage edit to any prompt is replacing adjectives with facts. Adjectives feel like instructions and are not: every reader, human or machine, resolves them differently.

"Write engaging copy" tells the model nothing, because engaging is a judgement about an effect on a reader it has never met. "Open with the specific problem the reader had this morning, use second person, and keep every sentence under twenty words" is checkable — you can look at the output and say whether it complied.

A useful test: for every requirement in your prompt, ask whether you could verify compliance by looking at the output. If you could not, the requirement is decoration and the model will treat it as such.

• "Professional tone" → "no contractions, no exclamation marks, no rhetorical questions".
• "Comprehensive" → "cover these four specific points, in this order".
• "Short" → "under 150 words".
• "Engaging opening" → "open with a concrete example, not a definition".
• "Modern design" → describe the actual attributes: spacing, palette, type weight.

Say what not to do

Negative constraints are the most underused tool in prompting, and among the most reliable. They work because they eliminate the specific failure modes you have already seen, rather than trying to describe success in the abstract.

The trick is to make them specific rather than general. "Do not be generic" is another adjective. "Do not use the words revolutionary, game-changing, seamless or leverage" is enforceable, and you can verify it in one glance.

Build your exclusion list from experience. Every time an output disappoints in a way you can name, that name becomes a line in your next prompt. Over a few weeks this list becomes the most valuable part of your prompt library, because it encodes your taste in a form a model can act on.

Give an example when words are not enough

Some things are far easier to demonstrate than to describe. Tone is the classic case: three paragraphs explaining the voice you want will underperform one short sample of it.

This is why showing an example — one or two, not twenty — is such a strong move. The model extracts the pattern, including aspects you could not have articulated, like rhythm and the level of hedging.

The failure mode to know about: models anchor on the example's subject matter as well as its shape. If your example is about coffee and your task is about insurance, say so explicitly — "match the structure and voice of the example, not its topic" — or you will get insurance copy that keeps reaching for coffee metaphors.

Length: say a number

Models are verbose by default because longer answers look more helpful. Without a limit you will get one.

Give a number, not an adjective. "Brief" means nothing; "under 200 words" is a constraint. Where structure matters more than words, count the units instead: "exactly five bullets", "three paragraphs", "no more than six rows".

One thing worth knowing: a length constraint competes with your content requirements. If you ask for six specific points in under 100 words, something gets dropped — usually a requirement, silently. When both matter, restate the must-include items after the length limit so they are the last thing the model reads.

The role: useful when it is real

Assigning a role works, but not for the reason people usually give. It is not that the model "becomes" an expert. It is that a specific role narrows the vocabulary, the assumptions and the level of explanation toward a coherent register.

That means a specific role helps and a vague one does not. "You are an expert" is close to meaningless because the model has no idea which expertise or which register. "You are a district nurse writing discharge notes for a patient going home alone" carries an enormous amount of implied context in eleven words.

Roles are also a way to get the criticism you actually need. "You are a sceptical reviewer looking for reasons this will fail" produces genuinely different output from "review this", because it licenses the model to be negative — which its default helpfulness otherwise suppresses.

Handling what the model does not know

Left to itself, a model faced with a gap fills it. It produces something plausible, because plausibility is what it is optimised for, and it does so without signalling that it was guessing.

You can change that behaviour with one instruction, and it is probably the highest-value single line you can add to any prompt where accuracy matters.

Decide once which behaviour you want and write it down: either the model asks you a clarifying question before proceeding, or it states its assumption explicitly and continues. Both are fine. Leaving it undecided is what produces confident invention.

• "If a detail you need is missing, ask one clarifying question before answering."
• "If you have to assume something, label it Assumption: and continue."
• "If you are not confident a claim is correct, say so rather than stating it plainly."
• "Do not invent names, numbers, dates or citations. Leave a marked blank instead."

A worked example, built step by step

Start with a prompt as most people would first write it: "Write an email to customers about our price increase."

Add format: "One email, under 180 words, with a subject line, three short paragraphs and no bullet points." Already the output is more usable, because it now has a shape.

Add context: "Our SaaS product is raising prices from $19 to $24 a month from 1 March. Existing customers keep the old price for six months. Most customers are small agencies who will feel this." The output stops being a generic price-increase template and starts being about your situation.

Add constraints: "Lead with the change and the date — do not bury it. Do not thank them for their loyalty in the opening. Do not describe the increase as an investment in the product. Acknowledge that it is unwelcome, in one sentence, without apologising twice."

Add the role: "You are the founder writing personally, not the marketing team." Five short additions, and the difference between the first and last output is not subtle. Nothing here was a clever trick; each addition simply supplied something the model could not have known.

Prompting for different kinds of work

The five components hold everywhere, but their relative weight shifts with the task.

• Writing: context and constraints carry the most weight. The model can write competently; what it cannot guess is your audience and your taste.
• Analysis: format matters most. Analysis without a specified output shape drifts into an essay when you wanted a decision.
• Code: constraints and exclusions dominate. State the language, the version, what libraries are allowed, and explicitly forbid placeholder comments — "// rest of implementation" is the single most common failure.
• Images: forget the five components. Image models read descriptors, not instructions. Describe subject, composition, lighting, medium and style, and drop verbs like "create" entirely.
• Video: describe motion, or you get a still picture that drifts. Name what moves, how the camera moves, and how long the shot is.
• Research: state your source standard and the recency window, and ask it to flag anything it could not source.

When the output is wrong, diagnose before you rewrite

The instinct after a bad result is to rewrite the whole prompt. That usually produces a different bad result, because you have changed five things and learned nothing.

Instead, name the failure first. Almost every disappointing output falls into one of a small number of buckets, and each points at a specific missing component.

• Too generic → context is missing. It does not know who this is for.
• Wrong length → no number was given, or the number is competing with unrestated content requirements.
• Wrong shape → format was not specified, or was specified only at the top of a long prompt.
• Made something up → no instruction covered missing information.
• Ignored an instruction → it was buried mid-prompt, or contradicted by another instruction elsewhere.
• Right content, wrong voice → describe the voice concretely, or show a short example instead of describing it.
• Answered a different question → the task sentence contained more than one task.

Contradictions are more common than you think

Prompts that have been edited several times accumulate instructions that quietly conflict, and the model has no way to resolve them — it simply satisfies one and drops the other, apparently at random.

The classic pair is "be concise" near the top and "explain your reasoning thoroughly" near the bottom. Another is asking for a formal register while providing a casual example. Another is demanding a strict word count alongside a long list of required content.

Before blaming the model, read your own prompt as an adversary and look for two instructions that cannot both be fully satisfied. When you find a pair, decide which one actually matters and delete the other, or state the priority explicitly: "if the word limit conflicts with covering all four points, keep all four points and go over."

Iterate in the conversation, then consolidate

You do not have to get a prompt right in one shot, and trying to is a slow way to work. Ask, look at what came back, and correct in a follow-up message: "closer, but drop the last paragraph and make the second point specific."

Conversational correction is fast because each message only has to carry one change, and because you are reacting to something concrete rather than imagining what might go wrong.

The step people skip is consolidation. Once the conversation has produced something good, write the single prompt that would have produced it directly, and save that. Otherwise you rebuild the same six-message conversation every time you do the task — which is precisely the work a saved prompt was supposed to eliminate.

Different models, same principles, different conventions

The five components are model-agnostic. The conventions on top of them are not, and knowing a few saves a lot of trial and error.

• Claude follows XML-style tags reliably, so wrapping distinct parts in <context>, <task> and <format> tags helps on long prompts. It also handles very long reference material well when that material comes before the instruction.
• ChatGPT responds strongly to Markdown structure — headers and numbered lists — and to an explicit statement of the output format.
• Gemini works well with the task stated first and constraints immediately after, and benefits from an example of the output shape.
• Open-weight models (Llama, Qwen, DeepSeek, Mistral) reward precision and punish hedging. Number every requirement and restate the format at the end.
• Reasoning-capable models do not need "think step by step" — they already do. What helps is telling them what to do with the reasoning: think first, then return only the final answer in the specified shape.

Build a personal prompt library, not a collection of tricks

The compounding value in prompting is not any individual prompt. It is the accumulation of two things: reusable structures for work you repeat, and a written record of what has failed for you before.

Turn a prompt into a template the second time you write something similar. Replace the specifics with fill-in fields and save it. A template used weekly saves more time than any amount of clever phrasing on a one-off.

And keep your exclusion list. The instructions that stop the specific failures you personally find irritating are worth more than any published list of prompt tips, because they encode your standards rather than someone else's.

The prompt patterns worth memorising

Beyond the five components, a handful of recurring shapes solve most of the problems people run into. They are worth knowing by name because once you recognise which one a task needs, writing the prompt takes seconds rather than several attempts.

None of them are clever. They are just the arrangements that keep working, and they compose freely — a task can use three of them at once.

• The reference-bound answer — paste the source, forbid anything outside it, require a gap marker when the answer is not there. For anything where being wrong is worse than being incomplete.
• The options-then-choose — "give me four genuinely different approaches, then say which you would pick and why". Better than asking for the answer directly, because the first idea is rarely the best one and this makes the alternatives visible.
• The critique pass — a second prompt whose only job is to find problems in the first output, with an instruction to report nothing if there are none. Cheaper and more reliable than asking for a perfect answer in one shot.
• The transform — "here is X, produce Y from it", with X pasted in full. The most reliable prompt shape that exists, because the model is reading rather than recalling.
• The constrained rewrite — "keep every fact and every outcome, change only the structure and wording". Stops the model quietly altering substance while it improves style.
• The extraction to a fixed shape — name every field, say what to put when a field is absent, and specify the format exactly. The alternative is output you have to reshape by hand every time.
• The role-free instruction — no persona at all, just the task, the constraints and the format. Worth trying whenever a persona-heavy prompt is producing padded output; it is often better.

The short version

If you remember nothing else: decide what a good answer looks like before you ask, name your audience, give a number for length, specify the shape of the output, and tell the model what to do when it does not know something.

Those five habits will do more for your results than any list of magic phrases, and unlike magic phrases they keep working when the models change.

Related articles