Home › Study guides › CCAO-F › Domain 1 › Lesson 1.1

CCAO-F · Domain 1 · 14% of the exam · Lesson 1.1 · 18 min read

The building blocks of an effective prompt

Why a one-line request gets a generic answer, the six parts of a good brief, and how the same brief works for a customer notice and a spreadsheet formula.

Written against objective 1.1 of the official CCAO-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

1.1.1 Why a one-line request gets a generic answer

Picture a Monday morning. You run operations at a regional parcel-delivery company, and your main depot moves across town next week. For about a week, deliveries to three postcode areas will arrive a day late. Customers need to hear about it before they start calling. You open Claude and type: "Write an email to customers about delivery delays."

Claude answers in seconds with a polite, well-built email. It apologises for "unforeseen circumstances", warns of delays of "3 to 5 business days", offers 10% off the next order and closes with a warm line about valued customers. It reads well. It is also wrong in almost every detail that matters. The move was planned, the delay is one day, you cannot offer a discount, and the email never says which areas are affected.

Nothing went wrong inside Claude. It did exactly what the request allowed. Claude knows a great deal about how delay notices are usually written, but it knows nothing about YOUR depot, YOUR customers or YOUR rules on compensation unless you put them in front of it. Every gap in a request is a question Claude still has to answer. With nothing to go on, it answers with the most plausible guess. A plausible guess is fine for a greeting; it is a problem for dates, areas and promises.

So the skill in this lesson is not clever wording. It is briefing. A prompt is everything you give Claude for one request, and an effective one reads like a brief to a capable colleague on their first day. Anthropic's own prompting guide makes the same comparison: treat Claude as a brilliant new employee who has not yet learned how your organisation works. A good brief states the job, the background, who it is for, the facts to use, the limits, and what a good result looks like.

1.1.2 The six parts of a good brief

Here is the question behind most prompting problems at work, and behind many exam questions too: when an answer comes back generic or wrong, what was missing from the request? Almost always, it is one of six things. Once you know them, you can check any prompt in under a minute, yours or a colleague's.

None of the six is exotic. Together they are what a good manager says when handing work to someone new. The first three tell Claude what you are trying to achieve. The last three stop it from guessing. Notice that OUTPUT includes how you will judge the result. These are your success criteria: the tests a good answer must pass, such as "a reader knows in ten seconds whether they are affected". Stating them helps twice: Claude can aim at them, and you get something concrete to check the draft against when it comes back.

Here is the brief with all six parts. Look at the facts list, which now holds real dates and areas, and at the final sentence. It tells Claude what to do when a detail is missing, instead of letting it guess.

Write an email to our home-delivery customers about a short delay.

Context: our main depot moves to a new site on 14 October. Until 21 October, deliveries to three postcode areas will arrive one day later than usual. We want customers to hear this from us before they need to call.

Audience: home customers, not business accounts. They mainly want to know whether they are affected and when their parcel will arrive.

Facts to use (use only these):
- Affected areas: NE1, NE2, NE4
- Dates: 14 to 21 October
- Delay: one day later than the usual delivery date
- Tracking links keep working as normal

Constraints: under 150 words, calm and plain, no jargon. We are not offering credits, because the delay is short and planned; to reassure customers, point them to live tracking instead.

Output: a subject line, then the email body. A reader should be able to tell within ten seconds whether they are affected. If you need a detail that is not listed above, write [CHECK] instead.

1.1.3 Say what to do, and why

Look again at the constraints in that brief. They could have been written as a list of don'ts: don't be formal, don't use jargon, don't offer compensation. It is tempting, because it is how we often think about rules. It also works less well than you would expect.

A "don't" tells Claude what to avoid but not what to aim for. It also comes without its purpose, so Claude has nothing to go on when a case comes up that you did not foresee. "Don't offer compensation" blocks the words "10% off", but a draft might still hint that the company "will make it up to you". It is like telling a teenager "no parties while we're away": you have banned the party, not the twenty friends who just came round to watch a film. Explain that the neighbours complained about the noise last time, and the film night is covered too.

Anthropic's prompting guide recommends two habits that close this gap. Tell Claude what to do instead of only what not to do. And explain why an instruction matters, because Claude can generalise from the explanation. Once the brief says the delay is short and planned, and that tracking is the reassurance to offer, Claude has the purpose behind the rule. It is then far less likely to slip in an implied promise.

The same thinking covers missing information. Without guidance, Claude may fill a gap such as a helpline number with something that looks right. Giving it explicit permission to say what it does not know, or a marker like [CHECK] that you can search for before sending, turns an invisible guess into a visible question. Anthropic's documentation lists this permission among its basic ways to reduce made-up details, often called hallucinations. It costs one sentence.

1.1.4 Keep your instructions apart from your material

Often the facts you need are already written somewhere: a memo from the depot team, a customer's email, last year's notice that customers liked. Pasting them in is the right instinct. The trouble starts when everything lands in one undivided block, because Claude then has to work out where your instructions end and the pasted text begins.

Suppose the depot memo includes a colleague's note: "Can we say sorry for the inconvenience and give 10% off?" That is a suggestion someone made, not your decision. In one block of text, Claude has no reliable way to tell the difference.

The fix is to label each part. Clear headings, such as "Instructions" and "Depot memo", are often enough. When a prompt mixes instructions, pasted documents and examples, Anthropic's prompting guide also recommends tags. A tag is a short label in angle brackets placed before and after a piece of text, such as <memo> at the start and </memo> at the end. Wrapping each kind of content in its own tag reduces misreading. The tag names are yours to choose; pick descriptive ones and use them consistently.

Examples deserve the same care. When a tone or layout is hard to describe, showing one often works better than any adjective. But Claude pays close attention to examples and can pick up their details as well as their style, so say what to take from each one. Here the instructions ask for last year's tone and layout, and name the memo as the only source of facts.

<instructions>
Draft the customer email about the depot move. Match the tone and layout of the example, but take every fact from the memo, not from the example. Sam's note in the memo suggests a discount; we are not offering one, because the delay is short and planned.
</instructions>

<memo>
Depot move 14 Oct. NE1, NE2, NE4 one day late until 21 Oct.
Note from Sam: can we say sorry and give 10% off?
</memo>

<example>
(last year's holiday notice, pasted in full)
</example>

For a task you repeat often, a single example can make every result look alike. Anthropic's prompting guide suggests three to five varied examples for best results, each close to your real use.

1.1.5 The same brief works for technical tasks

The exam objective says business AND technical tasks, and the second kind is where guessing does the most damage. The same Monday, finance asks you for the on-time delivery rate per route, calculated from the dispatch spreadsheet. You are not a spreadsheet expert, so you ask Claude: "Give me a formula for the on-time rate."

Claude will write a formula. It has to guess which spreadsheet tool you use, which column holds which date and what counts as "on time". It also has to guess how to treat edge cases: the unusual rows, such as cancelled or failed parcels, that a rule has to handle on purpose. A wrong guess here does not look wrong. The formula runs, a percentage appears, and nothing tells you it is counting the wrong column. That is why technical requests need the same six parts, with MATERIAL and CONSTRAINTS made exact.

The last row matters most. You may not be able to read the formula, but you can count three routes by hand and see whether the formula agrees. Pick routes that include a Cancelled and a Failed parcel, because edge cases are where a wrong guess shows. Asking for a way to test the result keeps you in charge of the answer.

The formula also shows where your role ends. If finance later wants the figure to update itself from the dispatch system every night, that is no longer a prompt. It is an integration, a connection between two systems that someone has to build and look after. The exam guide leaves that kind of build to Claude Architects and Developers: an Associate recognises the need and hands it over.

1.1.6 The exam traps

Every trap in this objective is a way of avoiding the brief. Questions usually describe a disappointing result and offer several ways forward. The right one adds what was missing.

• ✗ Sending a one-line request and hoping Claude knows what you mean. ✓ Brief it: task, context, audience, material, constraints, output. Claude fills every gap with a plausible guess.
• ✗ Fixing a generic answer by asking for it to sound "more professional". ✓ Add the information that was missing. The problem was the brief, not the wording.
• ✗ Switching to a more capable model because the answer was vague. ✓ Fix the prompt first. No model can know your depot dates until you provide them.
• ✗ Writing only "don't" rules. ✓ Say what to do instead and why, so Claude can apply the purpose to cases you did not list.
• ✗ Pasting material and instructions in one undivided block. ✓ Label the parts, and say which text is the source of facts and what to take from any example.
• ✗ Adding "be accurate" as the cure for invented details. ✓ Supply the facts and say what to do when one is missing. A plea for accuracy adds no information.

1.1.7 Put it together: brief Claude for a real task

You now have the whole method. Claude fills gaps with guesses, and a brief closes them in six parts. Rules work better with a target and a reason, labelled material keeps instructions and sources apart, and technical tasks need the same brief with exact inputs and a way to test. The quickest way to make it stick is to watch a brief work, then take one part away.

The rest of Domain 1 builds on this brief. Task decomposition (1.2) splits a request that is too big for one brief into steps you can check one at a time. Iteration (1.3) is how you improve a brief when the first answer is close but not right. Prompting by task type (1.4) tunes the six parts for analysis, research, drafting and brainstorming. And in Domain 5, the parts of a brief that repeat on every request move into Project instructions, so you stop retyping them.

Key takeaways

• ✓ Claude only knows what is in front of it; every gap in a prompt gets filled with a plausible guess.
• ✓ An effective prompt covers six parts: task, context, audience, material, constraints, and output with success criteria.
• ✓ A generic or wrong answer usually means a part is missing; add it rather than rewording the request or switching models.
• ✓ Say what to do and why, and tell Claude what to do when a detail is missing, so gaps show up as questions instead of guesses.
• ✓ Label pasted material and examples so Claude can tell them from your instructions, and say what to copy from an example.
• ✓ Technical tasks use the same brief with exact inputs, definitions and edge cases, plus a way to test the result.

Check your understanding

4 questions written for this lesson, then one from the CCAO-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• Prompting best practices
• Prompt engineering best practices
• Getting better results (Claude 101)
• Effective prompting techniques (AI Fluency)
• My prompt isn't giving me a helpful answer
• Reduce hallucinations
• The CCAO-F exam guide, summarised