Ask for "a blog post about coffee" and you get a polite grey page of generalities. Ask for a 700-word post for people who just bought their first espresso machine, comparing drip, French press, and moka pot, with a short buying checklist at the end, and the answer changes shape entirely.
The assistant did not get smarter between those two requests. It got clearer instructions. Prompt engineering sounds technical, but the skill underneath is ordinary: say what you want, who it is for, and what shape the result should take. Four ingredients get you most of the way there.
Why vague requests come back vague
You know a bad answer when you see it. It is accurate, clean, and useless. That happens for a predictable reason: every detail you leave out is a detail the assistant fills in for you, and when it fills in, it reaches for the middle — the average length, the average tone, the most familiar example.
Generic in, generic out. So the goal is not to hunt for magic words. It is to remove the guessing. Write the request the way you would brief a freelancer you are paying by the hour, and the first draft improves before you write a second one.
The four-part structure to reuse
Nearly every reliable request contains four parts. You will not always need all four, but when an answer disappoints, one of them is usually missing.
- Role. Who should be answering — a technical editor, a patient teacher, a copywriter for a small shop.
- Context. The situation: who the output is for, what they already know, what already exists.
- Constraints. Length, format, tone, what to include, what to leave out.
- Examples. One sample of the style, structure, or level of detail you want.
Arrange them in whatever order reads naturally. Labeling the parts helps once a prompt gets long, but the information matters far more than the formatting.
Role and context: who is speaking, who is listening
Role sets the vantage point
"Act as a technical editor who works with small hardware companies" produces different vocabulary and different warnings than "act as a friendly blogger." Keep it specific but short; a paragraph of invented backstory adds nothing useful. And remember what a role can and cannot do: it changes framing and emphasis, not credentials. For medical, legal, or financial decisions, keep a qualified professional involved.
Context is where most people write too little
"Write a product description" is a coin flip. "Write a product description for a 40-litre hiking backpack aimed at people who cycle to work in the rain" is a finished brief. Add what already exists, too: "we have a headline, write only the three bullets underneath it."
Constraints: the quickest win
Constraints are the part beginners skip, and they are the fastest way to improve an answer.
- Length: "under 150 words," "exactly five bullets."
- Format: a table, numbered steps, headings, plain paragraphs, no bullet points.
- Tone: direct, warm, formal, no jargon, explain any term on first use.
- Audience level: assume no prior knowledge, or skip the basics entirely.
- Boundaries: do not invent figures, say when something is uncertain, ask questions before starting.
- Shape: lead with the recommendation, then give the reasoning.
Two or three are plenty. A list of twelve becomes a checklist that gets half-followed, and you will not know which half.
Examples beat adjectives
If you can show one sample, you can drop three descriptions. "Make it punchy" means nothing on its own. Paste a sentence you like and write "match this rhythm." The same trick works for structure: hand over the skeleton of an email you have sent before and ask for the same sections in the same order.
No sample handy? Describe the target in plain terms: "written for someone skimming on a phone, roughly twenty words per sentence."
Before and after: the same request, rewritten
Here is a request most of us have typed at some point.
Write something about our new app for tracking gym workouts.
And here is the same request with the four parts in place.
Act as a product marketer who writes for people who dislike fitness jargon.
Context: we sell a workout-tracking app for people training at home three times a week, not for bodybuilders. Most of our readers have tried an app before and quit within a month.
Task: write the opening section of a landing page, 150 words maximum.
Constraints: plain English, no superlatives, no exclamation marks, one sentence explaining what the app does. Start with the reader's problem, not with our product.
Example of the rhythm I want: "You tried. It did not stick. That is usually the app's fault, not yours."
Put the two side by side and the gaps are obvious: audience, length, tone, starting point, and the thing to avoid. Notice that the second version also says where to begin, which is often what separates a usable draft from a rewrite.
Writing it took under a minute. It saves three rounds of "shorter, please, and less salesy."
Keep the prompts that work
Save your best requests in a plain notes file, one per task — a weekly update, a product description, an awkward email. Replace the specifics with brackets: [audience], [length], [thing to avoid]. Next time, fill in the brackets and send.
Two habits make that file more useful over time. First, refine instead of restarting: when an answer is close, reply with exactly what to change, using the same words you used the first time. Second, ask for a diagnosis — "what information would have made this better?" The reply usually names the constraint you forgot.
Start with your next request. Add a role, one line of context, two constraints, and a sample if you have one. That is the whole method, and it fits in a minute.
Photo: StartupStockPhotos / Pixabay
