Chapter 10: Prompt Engineering and the CLEAR Method
⚡ FAST TRACK
“Prompt engineering” might not be the best name for a simple thing
The term suggests a highly technical discipline. It is not. There is no magic phrasing, no keyword that unlocks a better model, and the collections of “1,000 power prompts” circulating online are largely worthless, because a prompt written for a generic reader cannot contain the thing that actually determines quality, which is your specific situation.
What is really going on is more ordinary and more useful: you are briefing someone.
If you handed a task to a capable new assistant with no knowledge of your world, you would tell them the background, what you want, who it is for, how long it should be, and what “good” looks like. You would probably show them an example. You would expect to give feedback on the first attempt.
That is the entire skill. The rest of this chapter makes it systematic.
The gap you already found
Earlier, you ran two versions of the same request: the lazy one and the detailed one. You saw the difference.
Here is what changed. The lazy prompt described a category of task. The detailed one described your actual situation. A model given a category responds with the statistical center of everything ever written about that category, which is by construction generic. A model given a situation has something to work with.
Almost all prompt improvement is adding back the information you left out because it was obvious to you.
CLEAR
Five elements. Not a rigid template: a checklist for what to include when an answer comes back generic.
C: Context: the situation, and what you already have
L: Limits: length, format, scope, and what to avoid
E: Examples: show the standard rather than describing it
A: Audience: who receives this, and what role you want the model to take
R: Refine: the correction pass, which is part of the method, not an afterthought
C: Context
The highest-value element, and the one most often missing.
Include: what you are actually trying to accomplish, the relevant background, the constraints you are operating under, what has already been tried, and any material you already have.
The common failure is assuming shared knowledge. The model does not know your industry’s conventions, your organization’s history, your customer’s temperament, or the fact that this is the third time you have raised the issue.
Weak: Write a follow-up email to a client who hasn’t responded.
Strong: I’m a freelance bookkeeper. A client of two years hasn’t responded to two invoices or three emails over five weeks. They’ve always paid on time before, and I suspect something is wrong rather than that they’re avoiding me. I want to be paid without damaging the relationship. Write a third email.
Same task. The second one can only be answered well because it contains the information that determines what “well” means.
A useful test: would a competent stranger be able to do this task from what I have written? If not, the model cannot either.
L: Limits
Length, format, structure, scope, and prohibitions.
Models default to long, comprehensive, and heavily formatted, because that is what human raters tended to prefer during training. If you want something else, say so.
• Under 150 words.
• Three paragraphs of prose. No bullet points, no headings.
• A table with four columns: option, cost, time required, biggest risk.
• Only the email body. No subject line, no explanation, no offer to revise it.
• Don’t mention the merger.
• Don’t use the words “leverage,” “robust,” or “delve.”
Negative constraints are underused and highly effective. So is constraining scope: Give me only the three highest-impact items, not a complete list.
E: Examples
Showing beats describing, especially for tone and style, where words like professional or friendly mean almost nothing.
• Paste two of your own past emails: Match this voice.
• Paste a competitor’s page: This structure, our content.
• Show a good and a bad instance: More like A, less like B, and tell me what distinguishes them.
• Give one completed item and ask for more: Here’s how I filled out the first row. Do the remaining twelve.
That last pattern is the single most reliable way to get consistent formatting across a list, and it works far better than describing the format you want.
If you have no example, invert it: Before you write it, describe what an excellent version would do differently from a mediocre one. Then have it write the excellent one.
A: Audience
Two things: who reads the output, and what role the model should occupy.
Who reads it determines vocabulary, assumed knowledge, length, and tone. For my board, who know the industry but not the technical details produces something entirely different from for new hires on their first day.
The role is genuinely useful when it carries real information: respond as an experienced employment attorney reviewing this for risk narrows the response toward a specific body of material and a specific set of concerns. But it is weaker than most guides claim. Assigning a role does not confer expertise the model lacks, and it does not make the output reliable. Chapter 9 still applies in full.
Skip the elaborate personas. You are a world-class expert with 30 years of experience adds nothing that review this for legal risk does not.
R: Refine
The other four elements build the first request. This one accepts that the first request will not be the last, and treats iteration as part of the method rather than as evidence of failure.
Use the five steering moves: constrain, redirect to the good part, ask for options, turn it against its own answer, make it interview you.
Two refinements worth building into your habits:
What did you assume about my situation that I didn’t tell you?
What’s the weakest part of this?
And when you have arrived somewhere good:
Write a reusable version of the prompt that got us here, with blanks where the specifics change.
A full worked example
Where most people start:
Write a proposal for a new project.
After C: Context:
I manage IT for a 60-person accounting firm. Our document management system is nine years old, unsupported since last year, and we’ve had two outages during tax season. I want to propose replacing it. The managing partner is cost-conscious and has rejected two previous technology requests as premature.
After L: Limits:
…One page. Lead with the risk, not the technology. Include a cost range and a phased option. No vendor names yet.
After E: Examples:
…Here’s a proposal that succeeded with him last year: match its structure and its directness: [paste]
After A: Audience:
…The reader is the managing partner: financially conservative, not technical, and primarily concerned with billable disruption during tax season. Write it the way a trusted operations director would.
Then R: Refine:
Good structure. The risk paragraph is too soft; he’s rejected two of these already, so make the consequence of another tax-season outage concrete. And what are you assuming about our firm that I haven’t told you?
Ninety seconds of specification, and the difference between a generic document and something that might actually be approved.
When you do not need all five
For most quick work, you need Context and Limits and nothing else. Cut this email to half the length, keep the deadline and the apology is a complete, well-formed prompt.
Reach for the full checklist when the first answer came back generic, when the stakes justify the effort, or when you will reuse the prompt.
| Symptom | Missing element |
| Generic, could apply to anyone | Context |
| Too long, wrong format, over-structured | Limits |
| Right content, wrong voice | Examples |
| Wrong level: condescending or over-technical | Audience |
| Close but not right | Refine: don’t restart |
Four common mistakes
Politeness as a substitute for specificity. Please and thank you are fine and cost nothing. They do not improve output. Detail does.
Overloading a single prompt. Asking for a plan, a budget, a timeline, a risk assessment, and a communication strategy at once yields five shallow sections. Do them in sequence within one conversation, where each builds on the last.
Vague quality words. Make it professional. Make it engaging. Make it pop. These carry almost no information. Say what you actually mean: shorter sentences, no jargon, open with the problem rather than the background.
Starting over instead of steering. When an answer is seventy percent right, the fastest path is a ten-word correction, not a rebuilt prompt. Rewriting from scratch discards the seventy percent that worked.
Build a library, not a memory
The prompts that will serve you best are the ones you wrote for your own recurring work.
Keep a document. Every time a prompt produces something genuinely good, save it with the specifics replaced by blanks. Within a couple of months you will have a dozen that fit your actual job better than anything in any published collection, including this book’s.
The CLEAR worksheet in the Bonus Resource Library gives you a structure for this, and Chapter 27 assembles it into a working system.
Exercise 10.1: Rebuild the prompt from Chapter 3
Retrieve the two answers you saved in Exercise 3.1. Rewrite the weak prompt using all five CLEAR elements and run it.
Put all three answers side by side. This comparison is the most persuasive argument for the method, and you produced it yourself.
Exercise 10.2: Constrain aggressively
Take any request you have made recently and add three hard limits: a word count, a format prohibition, and a banned word or phrase.
Most people find the constrained output better than the unconstrained one — not merely shorter.
Exercise 10.3: Start the library
Find one task you do at least monthly. Build a CLEAR prompt for it, run it, refine it until the output is genuinely good, then ask the tool to produce a reusable version with blanks.
Save it. That is entry one.
Learn More About Artificial Intelligence
Learn more about the CLEAR, TRUST and LEARN methods for Artificial Intelligence