How prompting actually works
The mental model behind every good prompt — and the four parts that turn a vague question into a useful answer.
A model can only work with what is on the page. Everything you leave out, it guesses.
The one-sentence mental model
A language model does not know what you want. It reads your words and continues them in the most plausible way. That is the whole machine. Everything that makes a prompt good follows from it.
So the question is never “what should I ask?” It is “what would a competent stranger need to know to do this well?” A stranger cannot see your screen, your team, your deadline or your taste. If it matters to the answer, it has to be in the prompt.
This is why the same request can produce a throwaway answer one day and a genuinely useful one the next. The model did not change. The context did.
Write a blog post about productivity.
Write a 700-word blog post about why time-blocking fails for people with reactive jobs (support, sales, ops). Audience: knowledge workers who have already tried and abandoned time-blocking. Tone: direct, no hustle-culture clichés. Include one concrete alternative and one honest caveat.
The second prompt names the length, the angle, the reader, the tone, and what to include. None of that is extra politeness — each line removes a decision the model would otherwise make badly.
The four parts of a working prompt
Almost every strong prompt has the same skeleton: role, task, context, format. You do not need labels or headers — you just need all four present somewhere.
Role sets the frame: who is answering. Task is the verb: what to actually do. Context is everything the model cannot infer: the audience, constraints, background, source material. Format is the shape of the output: length, structure, medium.
When an answer disappoints, one of the four is usually missing. Answer too generic? Missing context. Answer the wrong shape? Missing format. Answer hedging and shallow? Missing role. Answer off-target entirely? The task verb was ambiguous.
You are an experienced technical writer. Rewrite the release note below so a non-technical customer understands what changed and why they should care. Context: our users are small-business owners, not engineers. They do not know what a webhook is. The change is a real improvement but sounds boring in engineering terms. Format: two short paragraphs, no jargon, no bullet points, under 120 words. Release note: [paste here]
Summarize the text below for someone who has 30 seconds and needs to decide whether to read the whole thing. Three bullets max, plain language, lead with the decision-relevant fact. [paste here]
Say what you want, not what you don't
“Don’t be verbose” is weaker than “under 100 words.” “Don’t sound like AI” is weaker than “short sentences, no em-dashes, no phrases like ‘in today’s fast-paced world’.” Negative instructions describe an enormous space of things to avoid; positive instructions describe the one thing to hit.
Use negatives only for specific, nameable failures you have actually seen. A ban on one clichéd phrase works. A ban on “being generic” does not.
Show, don't only tell
The fastest way to communicate taste is an example. One sample of the output you want teaches more than three paragraphs describing it — tone, structure, level of detail and vocabulary all travel with the example at once.
This is worth the copy-paste. If you have a previous piece of work you were happy with, paste it and say “match this voice.” If you do not, write two lines by hand in the style you want and say “continue in exactly this register.”
Here is a paragraph I wrote that I am happy with: [paste your paragraph] Match this voice — same sentence rhythm, same level of formality, same willingness to be blunt — and write the next section, which should cover [topic].