The short version
Most prompts fail for the same reasons. The model has no idea who the audience is, no clear instruction about format, no examples to anchor on, and no signal about what a good answer looks like. Fix those four things and your output quality jumps before you touch anything more advanced.
This article is a working list of the ten techniques that produce the biggest improvements with the least effort. Use it as a checklist when a prompt is not behaving.
1. Name the audience explicitly
A prompt without an audience is a prompt without a calibration point. "Explain how DNS works" can produce anything from a five-year-old's metaphor to a network engineer's deep dive. State the reader: "Explain how DNS works to a junior backend developer who has never set up a domain."
The phrase you want is "for [specific reader]". It changes more than tone — it changes which concepts the model includes at all.
2. Replace adjectives with constraints
"Make it concise" is a wish. "Maximum 80 words, no adjectives, no introduction" is a constraint. Models follow constraints far better than adjectives because constraints are checkable.
Apply this to everything:
- "Make it friendly" → "Use second person. Use contractions. No exclamation marks."
- "Make it professional" → "Avoid contractions. Use full sentences. No hedging language."
- "Make it short" → "Three sentences. Each sentence under 20 words."
3. Put the most important instruction last
Modern language models attend to recent tokens more strongly than earlier ones. If a prompt has one critical instruction — "the output must be valid JSON," "respond in Spanish," "do not include disclaimers" — put it at the end, after all context and examples.
This is small and feels superstitious, but the effect is measurable on long prompts.
4. Give the model permission to refuse
A surprising number of bad outputs come from the model trying to answer when it should have stopped. Adding one line solves this: "If the source material does not contain the answer, reply with exactly the string NOT_FOUND and stop."
Without that out, the model will invent. With it, you get a clean signal you can branch on.
5. Use examples instead of descriptions
If you can show the model two real input-output pairs, do that instead of describing the style you want. One concrete example outperforms three paragraphs of adjectives.
Format it as:
Input: <real example input>
Output: <real example output>
Input: <another real example>
Output: <another real example>
Input: <the actual task>
Output:Stopping at "Output:" with nothing after it cues the model to continue the pattern.
6. Separate instructions from data
Mixing instructions and data in the same block of text confuses the model. Use clear delimiters. XML-style tags work especially well because most models have seen them during training.
<instructions>
Summarise the article below in three bullet points.
</instructions>
<article>
...
</article>This also makes the prompt easier for you to maintain. You can swap the data without touching the instructions.
7. State the output schema before the input
If you want JSON, describe the JSON shape before showing the input, not after. The model commits to a structure early and is less likely to drift mid-output.
Return a JSON object with these fields:
- title: string, max 60 characters
- summary: string, max 200 characters
- tags: array of 3 lowercase strings
Article:
...8. Decompose hard tasks
If a single prompt is doing three things — extract, classify, then summarise — it will do all three at medium quality. Split it into three prompts in sequence and each step will improve. This is the foundation of workflow-based AI: small, focused steps chained together.
The trade-off is more model calls. For anything that runs more than a handful of times, the quality gain is worth it.
9. Iterate against failures, not against ideals
When a prompt does not work, the temptation is to rewrite it. The faster path is to look at the specific failure cases — five or ten real outputs that went wrong — and ask: what would I have to say to prevent each of these specifically?
You end up adding two or three sentences to the existing prompt. You do not throw away the parts that already worked.
10. Keep a record of what changed
Every prompt that survives more than a week should have its history written down: what changed, why, and whether it helped. Without this, you will accidentally re-introduce mistakes you already fixed. With it, your prompt library becomes a long-term asset.
A simple convention is to keep three blocks next to each prompt:
- Version notes. "v3 — added schema, stopped truncating long inputs."
- Known failure modes. "Sometimes returns 4 tags instead of 3 when input is short."
- Last tested. A date.
How to use this list
The next time a prompt disappoints you, run through these ten techniques in order. Most of the time the fix is one of the first four. The remaining six are for when you are tuning a prompt that already mostly works and you want it to be reliable enough to ship.
The biggest mindset shift is treating prompts like code: short, specific, version-controlled, and improved one failure case at a time. That is also, not coincidentally, how teams who ship AI features without constant firefighting actually operate.