How to Write Better Prompts

A badly written prompt wastes your time. A well-written one can replace hours of manual work. The difference is not talent or luck. It is knowing what information the model needs to produce a useful response, and giving it that information in a form the model can use. This post teaches you how to do that systematically.

Most people who use AI tools have had both experiences. The frustration of a response that missed the point entirely. The satisfaction of an output that saved you an afternoon. The gap between those experiences is almost always in the prompt, not in the model. The model is the same either way. What changed is how the task was described.

This post covers the five practical levers that improve prompt quality, introduces the CLEAR framework as a structure for applying them, and shows you before-and-after comparisons so you can see the difference in concrete terms. If you want to go deeper, the free course at Prompt Engineering Fundamentals builds on everything here with structured exercises and evaluation techniques.

Why Most Prompts Fail

The single most common reason prompts fail is that they ask for an output without giving the model enough information to know what a good output looks like. The model has to fill in the gaps, and it fills them with what it has seen most often in training data, not with what you actually need.

Here is a simple example. "Write a summary of this document" is a valid instruction. But it leaves unanswered: How long? For what audience? What format? What should be included vs. excluded? What is the purpose of the summary? The model will make choices on all of those dimensions. Those choices may or may not match yours.

The fix is not to write longer prompts for the sake of length. It is to include the specific information the model needs to make the right choices. That is a different thing. A prompt can be long and still leave out the crucial detail. A prompt can be short and still communicate everything the model needs.

The model fills gaps with what appeared most often in its training data. Your job is to give it enough information that it does not have to guess.

The CLEAR Framework

The CLEAR framework gives you a checklist of five dimensions to consider before sending any prompt. Not every prompt needs all five. But checking each one before you submit saves the round-trip of getting a useless response and having to ask again.

You do not need to apply all five to every prompt. A quick factual question needs none of them. A complex content generation task may benefit from all five. The value of the framework is that it gives you a quick checklist to run before you submit, so you catch the missing piece before it costs you a wasted response.

Before and After: Seeing the Difference

The most direct way to understand what better prompting looks like is to compare weak and strong versions of the same request. Here are three pairs.

Example 1: Summarizing a document

The weak version leaves format, length, audience, and focus all unspecified. The strong version constrains all four. The model now knows what to include, what to leave out, how long to be, and who it is writing for. The output from the strong prompt will almost always be more immediately usable.

Example 2: Writing an email

The weak version will produce a reasonable email, but it may suggest rescheduling, may be too long, and may include explanations you do not want to give. The strong version specifies every dimension that matters for this specific use case.

Example 3: Explaining a technical concept

The weak version will produce a technically accurate explanation pitched at an unclear level. The strong version specifies the audience, the method (analogy), the constraints (no math notation), and the length. The output serves a specific reader rather than a generic one.

Be Specific, Not Long

A common mistake is conflating specificity with length. Adding more words to a prompt does not automatically improve it. What improves it is adding the right words: the constraints, context, and format specifications that tell the model what you actually need.

In practice, this means replacing vague words with concrete ones. "Make it professional" tells the model less than "avoid jargon, use short paragraphs, and address the reader as a peer." "Make it shorter" tells the model less than "cut this to under 150 words, keeping only the three main points." The concrete version gives the model a verifiable target. The vague version gives it a direction without a destination.

Specificity also means being explicit about what you do not want. If you know the model tends to add caveats you find unnecessary, say "do not include disclaimers." If you want bullet points and not paragraphs, say so. Negative constraints are just as useful as positive ones.

Give Context Before the Task

Most people write prompts in the order they think: task first, then context if the model asks for it. This is backwards for language models. The model reads your prompt sequentially and begins forming its response direction early. Context that appears at the end influences the output less than context that appears at the beginning.

A better ordering is: context first, then the task. "I am writing a proposal for a manufacturing company that has never used AI before. The audience is skeptical of technology claims. Write a one-paragraph introduction that leads with the business benefit, not the technology." The context establishes the frame. The task fits inside it.

This is especially important when you include a document or reference material. Put the relevant material before the instruction, not after. "Here is the transcript [transcript]. Identify the three main concerns raised by the client." That ordering ensures the model processes the transcript with the instruction in view.

Use Examples to Show, Not Just Tell

When a task has a specific format, tone, or structure you want, the fastest way to communicate it is to show an example. Describing a tone in words is imprecise. Showing a sentence written in that tone is not. Brown et al. (arXiv:2005.14165) showed that even one or two examples can dramatically improve the consistency of model outputs on structured tasks.

You do not always need examples from the exact domain. If you want the model to write short, punchy product descriptions in a specific style, you can give it two examples in that style from any domain. The model will apply the pattern to your actual product. This is few-shot prompting in practice, and it is one of the most reliable techniques available without any model fine-tuning.

Examples are especially valuable when you are asking the model to produce structured output: JSON, tables, formatted lists, or any template with a specific schema. Showing one complete example of the output structure removes ambiguity about field names, nesting, ordering, and format.

Chain Steps for Complex Tasks

When a task requires multiple reasoning steps or multiple distinct sub-tasks, asking for everything in a single prompt often produces worse results than breaking it into steps. This connects to a research finding documented by Wei et al. (arXiv:2201.11903): asking a model to show its reasoning step by step, rather than jumping directly to a conclusion, substantially improves accuracy on problems that require multi-step logic.

In practice, chaining looks like this: instead of "analyze this contract and tell me the three biggest risks and how to mitigate them," you might first ask "identify the clauses in this contract that deal with liability and termination," then in a second prompt ask "given these clauses, what are the three biggest risks for the buyer?" The second prompt is cleaner because the first prompt already did the extraction work.

Chaining also helps when you need to validate intermediate results. If you ask for analysis in one step and recommendations in the next, you can check the analysis before accepting the recommendations. For high-stakes tasks, that intermediate verification step can prevent errors from compounding.

Specify the Output Format

Format instructions are easy to add and consistently improve usability. If you need a JSON object, say so and show the schema. If you need a numbered list, say so. If you need prose with specific headings, name the headings. If you need a table with specific columns, specify the column names.

Models default to the format they have seen most often for similar content. For many tasks, that default is prose paragraphs. If you need something different, you have to ask. The cost of specifying the format is a sentence or two. The cost of getting the wrong format is reformatting the output manually, which is exactly the kind of work you were trying to avoid.

Format instructions also help with length. "Respond in a JSON object with two keys: 'summary' (one sentence) and 'risks' (an array of strings)" is a complete format specification. The model knows exactly what to produce. There is no ambiguity about length, structure, or what to include.

Iterate: The First Prompt Is a Draft

Experienced prompt engineers treat the first version of a prompt as a draft, not a finished product. They look at the output, identify what was missing or wrong, and revise the prompt to address it. After two or three iterations, most prompts converge on a version that works reliably.

The key discipline is to update the prompt itself when you get a bad output, rather than accepting the bad output and moving on or just asking again with the same prompt. If the model produced something too long, add a length constraint. If the tone was wrong, add a tone specification. If a key element was missing, add an instruction to include it. Each iteration makes the prompt more precise and less dependent on the model guessing correctly.

This iterative approach also produces reusable prompts. A prompt that you have refined over several iterations to work reliably on a specific task is an asset. You can save it, share it with colleagues, and use it as a starting point for similar tasks. The effort of refinement compounds over time.

Knowledge Check

A badly written prompt wastes your time.
A well-written one can replace hours of manual work.

The difference comes down to 5 things (the CLEAR framework):
C - Context: what does the model need to know about your situation?
L - Length: how long should the output actually be?
E - Examples: can you show one good output instead of just describing it?
A - Audience: who is this for, and what do they already know?
R - Role: what perspective should the model take?

Most weak prompts fail on C and A. Fix those two and most prompts improve immediately.

Full guide with before/after examples: https://arjunjaggi.com/blog/how-to-write-better-prompts