Prompt engineering tips go out of date; best practices do not. A tip is "use this phrase"; a practice is "state the result you want," and that one has worked on every model since the first chat interface and will work on the next. The ten below are practices in that sense. Each comes with the reason it works, because knowing the reason is what lets you apply it to a prompt nobody has written yet.
1. State the result, not the topic
"Help me with my presentation" is a topic. "Write the speaker notes for slides 3 to 7, two sentences each, in plain speech" is a result. A model aims at a result and wanders around a topic.
Before: "Tell me about email marketing for a bakery." After: "Write a three-email welcome sequence for a bakery's newsletter, each under 120 words, first email sent the day someone signs up."
Models weight the final instruction most. The format is the instruction you most need followed exactly, so it goes at the end, as a template rather than a description where there is more than one part. This single change fixes more prompts than any other.
3. Replace adjectives with rules
"Concise," "professional," "engaging" mean the model's average. "Under 150 words," "no exclamation marks," "one idea per paragraph" mean one thing. Go through a prompt and swap every quality word for the rule you actually mean.
Before: "Write a professional, concise summary." After: "Write a summary under 100 words, no adjectives, past tense, for a reader who has not seen the document."
4. Separate the material from the instruction
When the prompt contains a document, data or a draft, it goes in its own labelled block after the instruction. Run together, instructions and material blur, and the model discusses the prompt instead of doing the task. Labelled, the model works on the material.
5. Give the context the model cannot guess
Who the output is for, what it is about, what has already been tried, what the constraints are. A model without context fills the gaps with averages, and the average of everything is the generic text people complain about. One sentence of real context changes every sentence of the answer.
6. One example beats a paragraph of description
For format and tone, a single good example in its own block does more than any amount of explaining. Say the example shows the shape only, or the model will reuse its content. Three examples rarely beat one and cost more; test your task's number rather than assuming.
7. Tell it what to do with gaps
The expensive failure is the confident answer to a question you did not ask. Add a rule: if something needed is missing, say what it is and stop; or state the assumption and mark it. Which rule depends on whether a person reads the output before it is used.
8. Ask for the plan on anything with steps
"List your steps before you start." The misunderstanding shows up in the plan, where it costs one line, instead of in the output, where it costs the whole thing. In a product, the plan and the execution can be two calls.
9. Keep the prompt as short as the task allows
Long prompts fail by dropping instructions at random, and which one drops changes between runs. Keep the rules that have failed in testing; cut the ones that never have. An instruction that never fails is either obvious to the model or untested, and either way it is costing attention.
This is the practice that makes the other nine stick. Five varied inputs, a written description of a good output, a score per output, one change per version, a log. Without it you have opinions about your prompts; with it you have a prompt that works on ten different inputs and a record of why. The prompt optimization guide walks through the method.
How these differ from tips
Each practice above is model-agnostic because it is about how the model reads a prompt rather than what the model knows. Tips, such as a magic phrase that makes a particular version of ChatGPT more careful, work until the next release and then quietly stop. If you want the longer list with worked examples, the 12 best practices for prompt engineering goes deeper on each. And every prompt in the prompt library is written to these ten practices, so editing one of them is the fastest way to see the practices applied to a real task.
A prompt that uses all ten
Task: write a reply to the customer email below. Context: we are a small software company; the customer's export failed twice; we fixed the cause this morning; we do not offer refunds for a single failed export but we can extend their trial by two weeks. Material: [email pasted here]. Rules: apologise once, specifically; explain the fix in one sentence; offer the extension; no 'we value your feedback'; under 150 words. If the email asks for something not covered above, say what it is and stop. Format: subject line, then the email body, nothing else.
Result stated, context given, material separated, rules instead of adjectives, a gap rule, format last, and short enough to hold. Run it on five real customer emails, score the replies, and change one thing. That is the whole practice.
For the full set of practices with examples, read 12 best practices for prompt engineering.
