How to Write Better Prompts (With Before-and-After Examples)

Most prompting advice is a list of instructions without reasons: "be specific," "assign a role," "use examples." Fine, but why do those work? Without the mechanism you cannot adapt the technique to a new situation.

This guide gives nine techniques as before-and-after pairs, each with the reason it works. The reason always comes back to the same thing: an AI assistant predicts plausible continuations of text, so your job is to make the text you want the most plausible thing that could come next.

1. Replace topics with tasks

Before

Write about remote work.

After

Write a 250-word section for a company handbook explaining our expectation that remote employees overlap at least four hours with UK time. Audience is new hires. Tone: warm but unambiguous. Explain the reasoning, don't just state the rule.

Why it works. "Remote work" is a topic, and the most plausible continuation of a topic is a generic overview — because that is what the internet contains most of. The second prompt constrains length, genre, audience, tone, and purpose, which collapses the space of plausible outputs down to roughly the thing you wanted.

A useful checklist for any writing request — you rarely need all six, but name the ones that matter:

2. Say what you are trying to achieve, not just what to produce

Before

Write a follow-up email to a client who hasn't replied.

After

Write a follow-up to a client who hasn't replied in 12 days. Context: we sent a proposal, they were enthusiastic on the call, then went quiet. I suspect budget approval is stuck internally. Goal: give them an easy way to tell me it's delayed without feeling awkward. Don't create false urgency.

Why it works. The first version has one plausible answer: the generic "just circling back" email. The second gives the model a situation model — a stalled internal approval and a relationship worth protecting — so it can reason about what would actually help. Stating intent lets it make decisions you did not explicitly specify.

3. Show the pattern instead of describing it

Before

Turn these features into benefit statements.

After

Turn each feature into a benefit statement matching this pattern exactly:

Feature: 256-bit encryption at rest Benefit: Your files stay unreadable even if someone walks out with the drive.

Feature: Offline mode Benefit: The train losing signal stops being your problem.

Now do these: (1) Two-factor authentication (2) Automatic version history (3) Single sign-on

Why it works. This is few-shot prompting, and it is the highest-leverage technique in the list. Your examples become part of the text the model is continuing, so matching them is literally the most probable next output. Two or three examples convey voice, length, and structure more precisely than a paragraph of description ever could — note how the examples above teach a dry, slightly wry register that would be hard to specify in words.

4. Give it the source material

Before

What does GDPR say about how long we can keep customer data?

After

Here is our data retention policy: [paste]. Here is the relevant GDPR article: [paste]. Does our policy conflict with the article? Quote the specific lines that support your answer.

Why it works. This is the single most important reliability technique, and it is not really about prompting — it is about where the facts come from. In the first version the facts must come from the model's compressed memory of training data, which is where fabrication happens. In the second they come from text in front of it. Asking it to quote the supporting lines makes the difference checkable: if the quote is not in your pasted text, you have caught the error instantly.

Any time accuracy matters, convert a recall question into a reading-comprehension question.

5. Ask for reasoning before the conclusion

Before

Which of these three vendors should we pick?

After

Compare these three vendors against our criteria. For each: state how it performs on cost, migration effort, and support. Note where our information is incomplete. Only after that, give a recommendation and say what would change your mind.

Why it works. Two reasons, one mechanical and one practical. Mechanically, each token is generated in sequence, so a conclusion produced first cannot be informed by analysis produced afterwards — reasoning first genuinely improves the answer on multi-step problems. Practically, reasoning is auditable and a bare conclusion is not. "Say what would change your mind" is a cheap addition that surfaces the assumptions the recommendation rests on.

6. Assign a role — but a specific one

Before

You are a helpful expert. Review my code.

After

Review this function the way a reviewer who has been paged at 3am by this service would. Prioritise failure modes under load and unclear error handling over style. Ignore formatting.

Why it works. Roles work by shifting which patterns in training data get activated — vocabulary, priorities, level of detail. "Helpful expert" is not a real category of writing, so it shifts almost nothing. "Someone who has been paged at 3am" implies a concrete value ranking: reliability over elegance. The specificity is what does the work, not the word "expert."

7. Constrain by exclusion

Before

Make this landing page copy better.

After

Tighten this landing page copy. Rules: no superlatives, no "revolutionary" or "seamless," no claims about users or results we haven't measured, keep every heading under 8 words. Preserve the three feature names exactly.

Why it works. "Better" has no direction, so the model defaults to the most statistically common register for landing pages — which is exactly the inflated marketing voice you were trying to escape. Naming the specific patterns to avoid is far more effective than asking for a vague improvement, because it makes those patterns less probable rather than leaving them as the default.

The "no claims we haven't measured" rule is worth stealing. It is the cheapest guard against a model inventing flattering statistics.

8. Stage complex work instead of asking once

Before

Write a technical migration plan for moving our database to Postgres.

After — three separate turns:

Turn 1: Before drafting anything, list the questions you'd need answered to write a useful migration plan. Don't write the plan yet.

Turn 2: [answer its questions] Now propose a phased structure — phase names and goals only, no detail.

Turn 3: Expand phase 2 into concrete steps, including rollback.

Why it works. A single-shot request forces the model to invent your circumstances, and it will invent conventional ones. Asking for its questions first surfaces exactly which assumptions it was about to guess at — and reading that list is often more valuable than the plan itself, because it shows you what you had not specified. You also get to correct course at each stage instead of discovering a wrong premise buried in paragraph nine.

9. Iterate with diagnosis, not just direction

Before

Make it better. / Try again. / More concise.

After

The structure works. Two problems: paragraph 2 asserts a 40% improvement we never measured — cut the number and keep the claim qualitative. And the closing is hedged to the point of saying nothing; commit to one recommendation.

Why it works. "Better" and "try again" give the model no information about the gap between what it produced and what you wanted, so it resamples semi-randomly and you burn turns. Naming the specific defect and the desired correction turns revision into a targeted edit. This is the technique that most separates people who find AI useful from people who find it frustrating — the first draft is rarely the deliverable, and the quality of your critique determines the quality of the second draft.

Two things that do not work

"Are you sure?" This does not verify anything. Agreement is a plausible continuation of being challenged, so a model will often abandon a correct answer under mild pressure. It tests agreeableness, not accuracy. If you need to check something, check the source.

Politeness bargaining. Offers of tips, threats, urgency, and elaborate flattery do not meaningfully improve output quality. They add tokens that dilute your actual instructions. Being clear beats being persuasive, because there is nobody to persuade.

A prompt template worth reusing

Not magic — just the six dimensions in a fixed order so you stop forgetting one:

TASK:      What to produce, as a verb.
CONTEXT:   The situation. Why this exists. What you already tried.
SOURCE:    Paste the material rather than relying on recall.
FORMAT:    Structure and length.
CONSTRAINTS: What to avoid. Which words are banned. What must stay exact.
CHECK:     "Quote the lines supporting each claim" or "flag anything you inferred."

That last line is the one most people skip and the one that catches the most errors. Asking a model to mark what it inferred versus what it read makes the boundary between your facts and its guesses visible.

Practising this in PhantomAI

The SOURCE step is the one PhantomAI is built around: you can attach a document or paste a URL and ask questions against its actual contents rather than the model's memory. When a question genuinely needs current information, web search grounds the answer in retrieved pages. And once a prompt like the template above is working, the prompt library saves it so you are not rewriting it every week.

None of that removes the need to verify. See how to fact-check AI output for the workflow, and limitations of AI assistants for what prompting cannot fix.