Prompt Engineering

Test and revise your prompt in rounds

A method for improving prompts by changing one thing at a time and comparing outputs. For anyone who gets mediocre results and wants a repeatable way to fix them.

Copy page as markdown
GuideAdded 2026-11-08Free

A first draft prompt rarely gives you what you want. Most people respond by rewriting the whole thing at once, then guessing which change helped. Iteration is the opposite habit: you change one element, run it again, and compare. Over several rounds the prompt gets sharper and you learn what actually drives the output.

What it is

Iteration means treating a prompt as a draft you test, not a message you send once. You write a version, look at what comes back, name the specific weakness, and adjust a single part of the prompt to address it. Each round gives you evidence. After a few rounds you have a prompt that holds up and a short list of changes that made the difference.

When to use it

Use this when a prompt almost works. The output is close but too long, too vague, missing a step, or wrong in tone. It also pays off when you plan to reuse a prompt many times, since a small gain compounds across every future run. Skip it for one-off questions where any reasonable answer will do.

How to use it

  1. Write a plain first version. State the task, the audience, and the format you want. Do not polish yet.
  2. Run it and read the output closely. Write down one sentence describing the biggest problem. Be specific: not "bad" but "lists features without saying who they help".
  3. Change one thing in the prompt that targets that problem. Add a constraint, swap an example, or reorder the instructions. Leave everything else alone.
  4. Run it again and compare the two outputs side by side. Did the change fix the problem? Did it break something else?
  5. Keep the change if it helped, revert it if it did not, then repeat from step 2. Stop when the output meets your bar or when changes stop moving it.

Keep a short log of each round. Two columns are enough: what you changed and what happened. This stops you from circling back to a version you already rejected.

A worked example

Suppose you want a prompt that turns meeting notes into a client update email. Your first version says: "Turn these notes into an email to the client." The result is accurate but reads like a transcript, with every internal detail exposed.

Round one. The problem is too much internal detail. You add: "Only include decisions and next steps. Leave out internal debate." The email tightens up, but the tone is stiff.

Round two. The problem is tone. You add: "Write to a client who has worked with us for a year. Warm but brief." Now it reads well, though it opens with a long greeting.

Round three. The problem is the opening. You add: "Start with the decision, then the next steps." The email now leads with what the client cares about.

The final prompt is three sentences longer than the first, and every added sentence earned its place. You also know why each one is there, which means you can adapt it for a different client without starting over.

What a good result looks like

You have a prompt that produces usable output on the first run, a short record of what each change did, and a clear sense of which instructions are load-bearing. If you later need a variant, you adjust from a known good base instead of guessing from scratch.

what it isGuide

A method for improving prompts by changing one thing at a time and comparing outputs. For anyone who gets mediocre results and wants a repeatable way to fix them.

Prompt Engineering
next stepfree

Read this page, then check whether AI assistants can read yours: one scan, six pillars, a score.