Prompt engineering, from a prompt that works

What a working prompt is actually made of

Every prompt that returns something usable carries four things, even when the person writing it does not know their names. First the context: where the model stands in the work, who it writes for, what it already knows and what it does not. Second the task: exactly what to do, with a concrete verb. Third the constraints: what must not appear in the answer. Fourth the output shape: what the answer comes back as, how many parts, headings or none, a table or paragraphs.

Most people write the first three, more or less. The fourth is where the time goes, because when you do not state a shape the model picks one, and it usually picks whichever shape was most common in the text it learned from: an intro, a bulleted list, a conclusion. Then you sit there rearranging it.

Constraints carry one point that gets said too rarely: a negative constraint is weaker than a positive one. "Do not be promotional" is a sentence everyone reads differently. "Use no superlatives such as best or highest quality" is a rule you can hold an output against afterwards. The test is simple: if you cannot say how you would check that a rule was followed, that rule is not finished yet.

The same four parts on a real example

Here is a prompt people really write, and if it looks a little embarrassing it is because all of us have written a version of it:

write me some text for my site about brake pads. make it SEO friendly.

The model writes something. Eight hundred words, an introduction about how important brakes are, a list of pad types, and a conclusion saying that choosing the right pad matters a great deal. None of it is wrong and none of it belongs on a shop category page.

The same request in four parts:

Context: I run an online car parts shop and this text is for the "brake pads" category page. The buyer usually knows their car model but not which pad fits it.

Task: write 200 words that help the buyer choose the right pad for their car.

Constraints: no prices, because ours change weekly. Recommend no brand. Use no superlatives such as best or highest quality.

Output shape: three consecutive paragraphs, no headings, no lists.

The difference between these two outputs is not a difference of model. It is the same model. What changed is that in the second version the model no longer makes the four decisions it made for you in the first.

One note on length: models treat "200 words" as approximate, not exact. If the exact number matters, count it in the output and correct in the next round; insisting harder in the prompt does not fix it. The reason goes back to how the thing works, which the lesson on large language models covers: a model does not count words, it guesses the next token.

How to fix a first prompt in three rounds

Your first prompt is incomplete, and that is not a personal failing. Until you see an output you cannot know which part of your request was ambiguous; ambiguity is something only visible from outside. So the real work starts at round two, and it has one rule: change exactly one thing per round. If you change three things and the result improves, you have learned nothing and next time you start from zero again.

On that brake pad text, three real rounds look like this. Round one comes back in the right shape but explains what a brake pad is instead of helping anyone choose. The problem is not in the constraints, it is in the task: the model read "help them choose" as "teach them". So we sharpen the task and nothing else.

Round two does help you choose, but it assumes the reader knows the part number. That one is a context problem rather than a task problem: we never said what the buyer knows and does not know. One line goes into the context. Round three is usually the thing you wanted.

One habit worth more than the prompt itself: do not throw the wrong outputs away. Those two unusable answers from rounds one and two are your test set. Next time you change the prompt, or the model changes under you, they are how you tell better from merely different.

And a warning: if three rounds have not got you there, the problem is probably not the prompt. Either the information the task needs is not in the prompt at all, or you have asked for something this kind of tool cannot do. Rounds four and five are just time.

Which prompts to keep, and where

Any prompt you will use a second time is worth saving. The place to save it is a plain text file on your own machine, not the product internal memory. Three reasons: it moves between tools, it survives a change of subscription, and you can put the old and new versions side by side and see exactly what changed.

The prompt alone is not enough, though. Keep two other things next to it: the five real inputs you tested it on, and one output you accepted. Without those, what you saved is a paragraph; with them, it is something you can measure again next month.

Name the file after the task, not the tool. "Customer message summary" still means something in a year; "chatgpt prompt 2" does not.

One thing does not belong in that file: client data, passwords, tokens, account numbers. Prompts get copied and passed around work groups, and that is exactly where they leave your hands.

When you paste a long text, where does the question go

This is one of the few details vendors have written explicit guidance about, and Persian tutorials mostly leave it out. Google guidance for Gemini says that when you supply a large amount of context, a document or a block of code, put all the context first and place your specific question or instruction at the very end of the prompt. The same page says to put essential behavioural constraints, the role definition and output format requirements at the very beginning of the prompt or in the system instruction.

So the suggested order for a long prompt is: the main rules, then the whole text, then the question. The common habit is the exact reverse: people write the question and then paste fifteen pages under it.

An honesty note: we have not measured this on this server. It is Google own guidance for Google own model, and other vendors frame it differently. If your work involves long texts regularly, run your five test inputs once with the question first and once with the question last, and judge for yourself. It takes ten minutes and the answer is yours rather than a quotation from us.

Those magic prompts people sell

Our position is plain: most of those "500 golden prompts" packs are worthless, and the reason is technical rather than moral. A good prompt is tied to three things, none of which belongs to the seller: your specific task, your real inputs, and the model you use today. No prompt carries those three with it.

The second point is worse. Those prompts tend to be long, because length reads as professional, and they are full of rules nobody tested. An untested rule is not harmless: it takes up the model attention and it sometimes contradicts another rule in the same prompt. Cutting a crowded prompt down usually works better than adding to it.

Third, none of those packs ships a test. They show you an output, not a method for saying this prompt beats that one. Anthropic own documentation puts a condition before the prompt engineering chapter: have your success criteria and a way to test against them first, then go and improve the prompt. The same page says not every problem is best solved by prompting; sometimes the answer is a different model.

A prompt library is worth having, though, as long as it is yours. Five prompts written for your own real work and tested on your own inputs beat five hundred bought ones. That is not a nice sentiment: those five were built out of your actual failures, and the five hundred were built out of nothing.