Most advice about writing prompts describes a good prompt after the fact — "be clear," "be specific," "provide context" — without telling you how to get there before you've already seen the output. Here's the one technique that consistently changes results more than any wording trick: showing the model an example of what you want beats describing it, almost every time.
Show it, don't describe it
Compare two prompts asking for the same thing. First: "Write a product description for a water bottle, make it punchy and modern." Second: "Write a product description for a water bottle in this style: 'Built for the trail, not the desk. 24-hour cold retention. One hand, one twist, done.' Short sentences. No adjectives that don't earn their place." The second prompt doesn't describe "punchy" — it demonstrates it, and the model pattern-matches to the actual rhythm and word choice instead of guessing what you mean by a vague adjective. If you have even one sentence of the tone you're after, use it as the instruction instead of trying to name the tone.
The first response is a draft of the conversation, not the final answer
Treating a chat like a vending machine — one input, one correct output, start over if it's wrong — throws away the tool's actual strength. If the output is 80% right, the fastest fix is rarely a better first prompt; it's telling the model exactly what's wrong with what it just gave you ("the tone is right but it's too long, cut it by half" or "this misses that our audience is technical, add the actual mechanism"). Each correction narrows the target faster than trying to specify everything perfectly up front, because now the model has a concrete wrong answer to correct against instead of an abstract instruction to guess at.
A constraint beats more context, most of the time
Piling on background information ("here's our brand guidelines, our audience, our last five emails...") feels thorough, but it often produces vaguer output, because the model now has more directions it could reasonably go. A hard constraint does more work with less text: a word count, a required structure ("three bullet points, then one sentence"), a persona ("write this as a reply from a support agent, not marketing copy"), or a forbidden move ("don't use the word 'seamless'"). Constraints narrow the output space directly; context just describes a space and hopes the model narrows it the way you would.
When you actually do need more context
Context earns its place when the task requires information the model has no way to infer — your actual pricing, a specific person's name and role, a decision you already made that the model can't guess. It doesn't earn its place as a substitute for telling the model what you want the output to look like. If you're pasting in three paragraphs of background before every request, check whether one example sentence would have replaced most of it.
The actual habit to build
Before typing a description of what you want, ask whether you have an example of it instead — a sentence, a similar output from somewhere else, even a rough version you wrote yourself. If you do, lead with that. If you don't, write the vaguest possible first attempt, look at what's wrong with the result, and correct that specific thing. Two rounds of "here's what's wrong, fix this part" will get you further than one perfectly-worded attempt at describing something you haven't seen yet.