Skip to content
MaximumAI
← All articles
promptingtechniquesquality

Prompt Writing Techniques That Actually Help (With Examples)

Practical prompt engineering techniques that improve LLM output: clear task framing, context, examples, structure, output formats, step-by-step reasoning and testing.

There’s a lot of prompt folklore around: magic phrases, elaborate personas, tips that worked once on an older model. Most of what reliably helps is less exotic. Good prompts look a lot like good briefs for a capable new colleague: clear goal, relevant context, an example of what good looks like, and an explicit description of the output you want.

Below are the techniques that consistently pay off, each with a before/after example. Provider documentation from the major model vendors recommends most of them, and they tend to transfer across models.

1. State the task and the goal clearly

Vague requests get generic answers. Say what you want, who it’s for and why.

Before

Write about our new feature.

After

Write a 120-word announcement of our new CSV export feature for existing
customers. Audience: operations managers who currently copy data manually.
Goal: get them to try the export this week. Mention it's on the Reports page.

The “after” version answers the questions the model would otherwise guess at: length, audience, purpose and key fact.

2. Provide the context the model can’t know

The model doesn’t know your product, your customers, your style guide or what you tried last week. Include what’s relevant — and only what’s relevant. Extra context costs tokens (see how to cut API costs) and can distract.

Useful context often includes:

  • Who the end user is and what they already know
  • Constraints: tone, banned words, legal requirements, reading level
  • Definitions of internal terms
  • Source material the answer must be based on

3. Show examples (few-shot prompting)

One to a few well-chosen examples of input → output are often the fastest way to pin down format and style. Examples communicate things that are hard to describe in words, like tone or the exact level of detail.

Classify each review as positive, negative or mixed.

Review: "Fast shipping, but the lid cracked on day two."
Label: mixed

Review: "Exactly as described, works perfectly."
Label: positive

Review: "{review}"
Label:

Tips:

  • Make examples varied, so the model doesn’t copy surface details from one example.
  • Include a tricky case if there is one (like the “mixed” example above).
  • Keep examples consistent with your instructions; contradictions confuse.

4. Structure long prompts with clear sections

When a prompt contains instructions, reference documents and user input, separate them clearly. Headings or XML-style tags both work well:

<instructions>
Answer the question using only the policy below. If the policy doesn't
cover it, say so and suggest contacting support.
</instructions>

<policy>
{policy_text}
</policy>

<question>
{user_question}
</question>

Separation helps the model distinguish your instructions from content it should only read — useful for quality, and a basic defence when the content comes from users or the web. For long documents, a common pattern is to put the material first and the question at the end; see our context window guide.

5. Specify the output format exactly

If code will parse the output, say so and describe the format precisely. Better still, use your provider’s structured output or JSON schema feature where available.

Before

Extract the company and date from this text.

After

Extract the company name and invoice date. Return only a JSON object:
{"company": string, "invoice_date": "YYYY-MM-DD" or null}
No explanation, no markdown.

This also reduces output tokens, which are usually the most expensive part of the bill.

6. Say what to do, not just what to avoid

“Don’t be verbose” is weaker than “Answer in at most three sentences.” Positive, concrete instructions give the model a target. When you do need a prohibition, pair it with the alternative: “Don’t guess order numbers; if none is present, return null.”

7. Give the model room to think on hard problems

For multi-step reasoning — maths, planning, debugging, weighing options — asking the model to work through the problem before giving a final answer often improves accuracy. Many current models have built-in reasoning modes that do this automatically; for others, you can ask for reasoning explicitly and separate it from the answer:

Think through the problem step by step inside <reasoning> tags,
then give only the final answer inside <answer> tags.

Trade-off: reasoning adds output tokens and latency. Use it where it measurably helps, not by default on simple tasks like classification.

8. Tell the model how to handle uncertainty

Models tend to produce an answer even when they shouldn’t. Give them an explicit way out:

If the answer isn't in the provided documents, reply exactly:
"I couldn't find that in the documentation."

This reduces confidently wrong answers and makes failures easy to detect in code.

9. Use the system prompt for stable rules

Put durable instructions — role, tone, constraints, formatting rules — in the system prompt, and the per-request task in the user message. Keeping the system prompt stable has a cost bonus too: an identical prefix across requests is what makes prompt caching work where providers support it.

10. Break big tasks into steps

One prompt that researches, drafts, critiques and formats is hard to debug. A chain of smaller prompts — extract facts, then draft, then check against the facts — is easier to test, and each step can use the model size that suits it.

What usually doesn’t matter much

  • Magic phrases and threats or bribes. Effects are inconsistent across models and versions; clear instructions do more.
  • Elaborate personas. A one-line role (“You are a support agent for an accounting app”) can help set context; paragraphs of backstory rarely do.
  • ALL CAPS and repeated emphasis. With modern models, heavy emphasis can cause over-application of a rule. Use it sparingly.

Test prompts like code

A technique only “works” if it improves results on your task. Treat prompt changes like code changes:

  1. Keep prompts in version control.
  2. Run your eval set before and after each change.
  3. Change one thing at a time so you know what helped.
  4. Re-test when you switch models — prompts don’t always transfer perfectly.

Quick reference

TechniqueFixes
Clear task + goalGeneric, off-target output
Relevant contextWrong assumptions
Few-shot examplesInconsistent format or tone
Sections / tagsMixed-up instructions and content
Exact output formatParsing failures, wasted tokens
Positive instructionsVague compliance
Room to reasonErrors on multi-step problems
Uncertainty pathConfident wrong answers
Stable system promptInconsistency, cache misses
Task decompositionHard-to-debug mega-prompts

Prompt tips that hold up across models — with before/after examples — are a core part of what we’re building at MaximumAI.