Prompt Engineering Is Just Clear Thinking

The slogan is nearly right. What makes prompting hard is not expressing yourself clearly — it is that a prompt forces you to decide things you would normally leave a colleague to work out.

Penhale Mutual's correspondence drafter writes the first letter a claimant receives. The instruction it shipped with was one line: draft an acknowledgement letter for this claim.

It produced good letters. Warm, correctly formatted, accurate about the claim details. Eleven of them went out before somebody noticed that four mentioned the policy excess and seven didn't.

Nobody had decided whether an acknowledgement letter should mention the excess. It's a real question — telling people early is honest and reduces later disputes; telling people early also reads as defensive when they've just had a fire. It had never been argued about, because for twenty years each handler had made the call themselves, in the moment, from context nobody had ever written down.

The model made that call eleven times. It made it differently depending on how the claim was phrased.

The unit is the specification, and the failure is not vagueness

The received wisdom is vague prompt, vague answer. That is not what happens, and the mistake matters.

A vague prompt returns a confident, specific answer to a question you didn't ask. The output is well-formed and complete; it simply resolves your ambiguity in a direction you never chose. That's why bad prompts survive review — there is nothing on the page that looks unfinished.

So the useful frame isn't clarity of expression. It's decision coverage. A prompt is a specification, and every decision it leaves open is one you have delegated — not to the model's judgment, which it doesn't have, but to whatever is most common in the material it learned from. Penhale didn't delegate the excess question to a machine. They delegated it to the average of every acknowledgement letter on the internet.

The test you can run: take a prompt you use and list the decisions it does not make — audience, length, what to omit, what to do when a fact is missing, what tone to hold when the news is bad. That list is what you have delegated, and you can read it back as a specification you never wrote.

The four elements, read as decisions removed

The standard advice — context, task, format, constraints — is right, and it's usually taught as a checklist of things to include. It's more useful as an inventory of what each one stops the model deciding for you.

Element	The decisions it removes	Left open, the model picks
Context	Who reads this, what they already know, what situation it lands in	The most generic plausible reader
Task	What the output is for, and therefore what it must contain	An operation that matches the verb you used
Format	Structure, length, whether it's scannable	Prose of moderate length, because that's the default of the genre
Constraints	What to leave out, what never to say, what to do when unsure	Nothing is excluded, and uncertainty renders as confidence

The fourth row is the one that goes missing and the one that costs. "What to do when a fact isn't in the file" is a decision every handler makes daily and almost no prompt states. Left open, the model's default is to produce something anyway, in the same register as the parts it knows.

The test: for a prompt you rely on, find the row above it doesn't cover. Then find an output where the model's default for that row was wrong. It will not take long.

A role is a hundred decisions in three words

You are a senior claims handler writing to a distressed claimant is genuinely effective, and it's worth being precise about why: a role is a compression. It sets vocabulary, register, what gets emphasised, what gets omitted, and how bad news is framed, all at once, in fewer words than stating any one of them.

That's the appeal, and it's also the risk. A role makes many decisions simultaneously and shows you none of them. When a role-prompted output is wrong, it's hard to say which of the compressed decisions went the wrong way, so people re-roll the role — try "empathetic senior handler" — which is guessing at a bundle rather than fixing a term.

The workable discipline is to use the role for tone and stance, and to state the load-bearing decisions explicitly anyway, even when the role would probably have covered them. Penhale's prompt now names the role and says the excess is mentioned only where the claim value is near it. Redundant on most claims. Decisive on the ones that matter.

The test: remove the role from a prompt you use and see what changes. Everything that changes was being decided by three words — check whether you'd have chosen the same way.

The decisions come from the feature, not from the prompt

This is where prompting stops being a writing skill.

Penhale's excess question could not be answered by anyone writing the prompt. It's a policy question about what the company tells claimants and when, and it needed a decision from the people who own claimant communications. The prompt was where the absence became visible, which is a useful property, but the prompt was never the place to resolve it.

That's the honest relationship between this skill and the rest of the work. Discovery is where those decisions are supposed to get made, and acceptance criteria are where the ones that must always hold get written as invariants. A prompt that carries a decision nobody senior has agreed to is a policy set by whoever last edited a text box.

The test: for each decision in your prompt, name who would have to approve it if it were written in a process document instead. Any that require someone other than you are on loan, not owned.

When clarity isn't the problem

Writing a better prompt is the first move and, past a point, the wrong one:

• The information isn't in the input. No wording makes a model report a fact it was never given. If the answer lives in another system, that's a retrieval or scope problem, and prompt iteration will produce increasingly confident inventions.

• The decision is genuinely contested. If two experts disagree about what the output should say, the prompt can't settle it. Escalate; don't average.

• The task is several tasks. A prompt asking for analysis, then implications, then a summary spreads attention and does each worse. That's structural, not a wording defect.

• You're on iteration eight. Past a handful of honest attempts, continuing to rewrite is usually avoidance of a harder finding — missing context, an unclear requirement, or a feature that shouldn't be built this way.

• The variance is the problem. If the same prompt gives materially different answers run to run, that's not something wording fixes.

The test: ask what you would have to know for a perfect prompt to produce the right answer. If the answer is a fact the model was never given, stop editing and go get the fact.

What to change this week

Don't rewrite a prompt. Audit one.

Take the prompt your team most depends on and list every decision it leaves open. Then, for the two or three that would actually matter if the model chose wrong, find out whether anyone has ever decided them. Usually one has been decided and never written down, and one has never been decided at all — and the second is the interesting one, because it has been getting decided, silently, on every request.

Then write those two decisions into the prompt explicitly, even if the role probably covers them. Redundancy in a specification is cheap; a policy nobody agreed to is not.

Penhale's acknowledgement prompt is eleven lines now. Nine of them are decisions somebody made in a meeting, including the excess rule. The letters are no warmer than they were — they're just consistent, and when one is wrong there's a line to point at. Getting there is a loop, not a rewrite.