Prompt engineering basics: how to write a good prompt

Why the wording of a prompt matters

A language model does not know your situation. It only sees the text you send. When a prompt is vague, the model fills the gaps with the most typical answer, which is usually generic, too long or aimed at the wrong reader. Prompt engineering is mostly the work of removing guesses.

A helpful test: could a smart new colleague, who has never met you, do the task well from your message alone? If they would need to ask three questions first, the model needs those answers too. The official guides from OpenAI, Anthropic and Google give the same core advice in different words: be clear and specific, give context, show examples, say what format you want.

The six parts of a good prompt

Not every prompt needs all six parts, but checking this list fixes most weak prompts.

Put long input material between clear markers, such as XML-style tags or triple quotes, so the model can tell your instructions from the text it should process. This also lowers the risk that instructions hidden inside the input, for example in a pasted web page, are followed by mistake.

A before and after rewrite

Here is a typical weak prompt:

Summarize this article.

The model will produce a summary, but of what length, for whom and in what form? Here is the same request with the gaps filled:

You are helping a busy product manager decide whether to read a research article.

Summarize the article below for that reader.
- Start with one sentence: the main finding.
- Then 3 bullet points: method, key number, main limitation.
- Use plain English. Explain any technical term in a few words.
- Under 100 words in total.
- If the article does not state a limitation, write "No limitation stated".

<article>
{paste the article here}
</article>

What each part does:

• The first line sets the audience and purpose. The model now knows why the summary exists, so it chooses what to keep.
• The bullet structure fixes the format, so every summary looks the same and is easy to compare.
• The word limit stops the model from padding.
• The rule for a missing limitation tells the model what to do in an edge case, instead of inventing one.
• The tags separate the article from the instructions.

Show examples when words are not enough

Some requirements are hard to describe but easy to show: a tone of voice, a labeling scheme, a specific output style. Adding a few worked examples is called few-shot prompting. One example (one-shot) often helps a lot. Two to five varied examples usually cover the main cases.

Classify each support message as BILLING, SHIPPING, PRODUCT or OTHER.
Reply with the label only.

Message: I was charged twice for order 5521.
Label: BILLING

Message: The handle on my mug cracked after one week.
Label: PRODUCT

Message: Do you have a shop in Osaka?
Label: OTHER

Message: {new message}
Label:

Make your examples different from each other. If all of them are short and polite, the model may handle a long angry message badly. Also check that examples match the rules: the model copies examples more strongly than it follows written instructions.

Techniques that help in specific cases

• Ask for steps before the answer. For math, logic or multi-part decisions, asking the model to work through the problem before giving the final answer improves accuracy. This is known as chain-of-thought prompting. Many current models do this internally (often called reasoning or thinking modes), so a plain request for a careful answer may be enough.
• Split big tasks. Instead of "research, outline and write a report" in one prompt, run three prompts and check each output. This is called prompt chaining.
• Give a role only when it adds information. "You are a tax accountant in Vietnam" changes word choice and assumptions. "You are a world-class genius" adds nothing.
• Say what to do, not only what to avoid. "Write in short sentences" works better than "Don't be wordy".
• Allow "I don't know". Tell the model it may say the information is missing. This reduces invented facts, though it does not remove them.
• Ask for a machine-readable format when code will read the output, for example JSON with named fields. Most APIs can also enforce a JSON schema directly.

Test a prompt like code

A prompt that works on one example may fail on the next. If the prompt will be used again, or by other people, test it:

1. Write down what a good output looks like: length, format, facts that must be right.
2. Collect 10 to 20 real inputs, including difficult ones: very short, very long, off-topic, another language.
3. Run the prompt on all of them and read every output.
4. Change one thing at a time and run the whole set again, so you know which change helped.
5. Keep the final prompt and the test set together. When you switch models or a model is updated, run the set again.

This last step matters because the same prompt can behave differently on different models, and on newer versions of the same model. Prompt engineering guidance from model makers changes over time for this reason.

Common mistakes

• Too many goals in one prompt. Ten rules with equal weight get partly ignored. Put the most important rules first and keep the list short.
• Contradictions, such as "be detailed" and "keep it under 50 words". The model will satisfy one and break the other.
• Relying on capital letters or threats ("YOU MUST") instead of a clear reason. A short explanation of why a rule exists usually works better.
• Not separating input from instructions, so the model treats part of your document as a command.
• Trusting facts in the output. A well-written prompt still produces confident mistakes. Check names, numbers, quotes and links.