Prompt engineering is just being clear

Kill the mystique first

Prompt engineering has a silly name for a normal skill: writing a brief that a competent, literal, slightly over-eager stranger could follow without asking you a single question.

That stranger:

• is well-read but knows nothing about you, your company or last Thursday
• will never say "sorry, what did you mean?" - it will guess, confidently
• takes everything literally, including the bits you didn't mean literally
• has no taste of its own, so it defaults to the world's average taste

Every technique below is a way of removing something that stranger would have to guess.

Watch a bad prompt become a good one, one sentence at a time

Step through all six. Notice that nothing added is clever. It's who, why, what-not, what-shape, and an example. That's the whole discipline, and it works on every model, forever, because it is not a trick - it is information the model genuinely did not have.

The five ingredients, in the order they pay off

1. Role and audience. "You are writing for people who have never used a spreadsheet." One line kills a thousand wrong assumptions about vocabulary and depth.

2. The goal, not the task. "Get them to click one button" produces different, better writing than "write a landing page". Tell it what winning looks like and it can make its own cuts.

3. Constraints - where your taste actually lives. Length. Banned words. Tone. What must never appear. This is the highest-value sentence most people never write. Listing what you hate is faster than describing what you want, and works better.

4. Output shape. "Three bullets, each under 12 words. No intro, no summary." Otherwise you get a polite essay wrapped around the one line you needed.

5. An example. One good example outperforms a paragraph of description. Show a headline you love. Show the exact format of one row. It infers the pattern startlingly well - that is the one thing it is truly excellent at.

Things that genuinely work (and the reason why)

• "Think it through step by step first, then give the answer." Working out loud gives the model more intermediate text to condition on. It really does improve multi-step reasoning. It costs tokens and time - worth it for hard tasks, waste on easy ones.
• Give it the source instead of trusting its memory. Paste the policy. Attach the doc. A grounded answer beats a remembered one every single time.
• Ask for options, not an answer. "Give me three versions: safe, bold, weird." You get to exercise taste instead of negotiating with a single draft.
• Say what to do when it doesn't know. "If the document doesn't say, reply exactly: NOT IN DOC." Without that line, silence gets filled with invention. With it, you get an honest gap.
• Split the job. One prompt to extract, one to judge, one to write. Each is short and checkable. Trying to do all three at once is where quality goes to die.

Things that do not work (stop doing them)

• Being polite, or rude, or urgent. "This is very important to my career" is folklore.
• Piling on adjectives. "Amazing, world-class, cutting-edge" describes nothing and constrains nothing.
• Very long prompts full of rules that contradict each other. It will follow some of them. You will not be able to predict which.
• Arguing across ten messages. Rewrite the brief and start clean. Cheaper, faster, better.
• Hunting for a magic prefix you saw on social media. If it worked, it worked because it accidentally contained one of the five ingredients.

Where things stand (as of 2026)

The five ingredients in this lesson - role, goal, constraints, shape, example - have stayed stable across model generations and are unlikely to go out of date, because they're about clear communication, not about any particular model's quirks. What keeps changing is which shortcuts models respond well to: "think step by step" was a discovery, not a law of nature, and newer models sometimes do this automatically without being asked. What's still unreliable: knowing in advance, without testing, whether a given model needs you to spell something out or already infers it - this varies by model and by version. Because of that, treat any very specific prompting trick you read online ("always start with X", "never say Y") as something to test on the model you're actually using, dated to when you read it, rather than a universal rule.

How to read the docs and look things up

The most useful primary source for prompting technique is a provider's own "prompting guide" or "best practices" documentation, which they update as their models change - these are usually more reliable than social media threads claiming a secret phrase. A marketing claim sounds like "supercharge your prompts with this one trick"; a real guide shows worked before-and-after examples with an explanation of why the change helped, similar to the landlord email above. To test a prompting claim yourself: take the "before" version of a task you actually care about, apply the claimed trick, and compare outputs side by side - ten minutes is enough to see if it's snake oil. Keep a short dated log of prompts that worked well for recurring tasks; this becomes the reusable brief that Level 6 builds on, and it ages far better than any single tip you read.

Write your own - the four-question warm-up

Before you type anything, answer these out loud. It takes twenty seconds and it is the actual skill:

1. Who is this for?          (one sentence, a real person)
2. What should happen next?  (the thing that counts as success)
3. What must never appear?   (your taste, stated as bans)
4. What does done look like? (format, length, an example)

Then just... write those down as the prompt. That is it. That is the technique that people sell courses about.

A worked before-and-after

Before: "Write a professional email to my landlord about the heating."

After:

You're writing as me: a tenant of four years, always paid on time, currently annoyed but not burning any bridges - I want this fixed, not a fight.

Situation: heating has been dead for 6 days. I reported it on the 3rd by text. No reply.

Goal: a specific visit date this week, in writing.

Under 120 words. No "I hope this email finds you well". No legal threats, but do mention it has been six days and that I've kept the messages. Plain, firm, warm.

End with a direct question about a date.

Same model. Same three seconds. One of these you send; the other you rewrite yourself. Notice you didn't learn any syntax - you just stopped leaving things unsaid. Which is precisely the subject of the last level.

Check yourself

• Which of the five ingredients do you personally skip most often?
• Why does listing banned words work better than describing the tone you want?
• What single line stops a model from inventing an answer when the document is silent?

Recap: what changed in your head

• You know prompt engineering is just writing a brief a literal stranger could follow.
• You know the five ingredients: role, goal, constraints, shape, example - in that order of payoff.
• You know banning what you hate works better than describing the tone you want.
• You know arguing across ten messages is worse than rewriting the brief once.
• You have a four-question warm-up you can actually use before typing anything.