Prompting and Task Execution

Prompting and Task Execution is 14% of the CCAO-F blueprint, roughly 8 of the 60 questions. It is the domain candidates most often assume they can skip, because everyone who has used Claude has written a prompt. The exam does not reward that assumption. It is not testing whether you can phrase a question politely, and there is no prompt syntax to memorise. It tests whether you can look at a piece of work — a newsletter piece, a supplier report, a course rebuild, forty product descriptions — and see what the request is missing before you send it.

The recurring shape of these questions is a professional who got a fluent, competent, useless answer. The copy reads well and could describe any organisation. The summary is accurate and evenly weighted when what was needed was the three clauses that changed. Nothing is wrong; nothing is theirs. Almost every correct answer here comes from the same move: put into the request the thing only the human knows — who is reading it, what decision it feeds, what the source material is, and what a good one looks like. The wrong answers usually offer a second lap of the same vague request, or a way to make Claude explain itself instead of doing the work again with more to go on. Expect to choose between iterating and restarting, between describing a standard and showing one, and between one large request and a sequence of checkable ones.

What the exam actually tests

• —Diagnosing why a fluent answer is unusable — what the request failed to supply, not how it was worded
• —Specifying audience, purpose, length, format and source material rather than asking for 'better'
• —Showing a worked example instead of describing a standard in the abstract
• —Decomposing a multi-part deliverable into steps whose output can be checked before the next runs
• —Stating what you want rather than stacking up what you do not want
• —Recognising when a long conversation has drifted and a clean restart beats another correction

A request is a brief, not a wish

"Write something about our youth programme for the newsletter" reliably produces 600 words of warm, generic copy, because nothing in the request distinguishes this programme from any other. The fix is not a more forceful adjective. It is supplying what Claude cannot infer: who reads the newsletter, what you want them to do or feel, how long the piece runs, and the specifics — the numbers, the names, the one anecdote that could only be yours. An option offering to make the piece "more specific and engaging" restates the symptom; an option supplying the participant detail and the word count treats the cause. Generic output is almost always a generic brief.

Show the shape; do not only describe it

A style guide describes an output in the abstract. An example shows it. When forty product descriptions must share a length, an order of information and a tone, sending the style guide alone tends to produce forty defensible interpretations of it. Writing one description the way it should be done, then asking for the rest to match it, collapses that variance, because the model now has the target rather than a description of it. On the exam, an option supplying a completed example usually beats one adding more written rules, and certainly beats one repeating the guide at the top of every request.

Say what you want, not what you do not want

"Don't make it too formal, don't make it too long, don't use jargon, don't sound like a robot" is a request with no target in it. Every constraint is negative, so the acceptable output is defined only by its edges, and what comes back tends to be cautious and shapeless — often exhibiting the very qualities the list tried to exclude, because naming a thing repeatedly keeps it in view. Convert each prohibition into a positive specification: warm and direct, under 200 words, plain language a new starter would follow. Options adding another "don't" to the stack are distractors; the one naming register, length and audience is the answer.

One deliverable per request

A single message asking Claude to summarise a client call, draft the follow-up email, build a risk list, propose an agenda and recommend attendees will produce all five, and most of them thinly. Attention is finite and a bundled request spreads it. The exam-correct pattern is sequential: complete the summary, check it, then draft the email from the checked summary. A sequence gives you a place to intervene — if the summary missed the commercial point, everything downstream would have inherited that miss, and you caught it at step one. Bundling also hides which part of the request caused a poor result.

Anchor a rebuild to the original

Asking outright for the eight-week version of a twelve-week course produces a plausible plan that quietly drops content nobody agreed to lose. The reliable pattern makes the change visible: ask what the twelve weeks currently cover, decide what must survive, then request the shorter version against that list. Similarly, when you are unsure what a stakeholder wants covered, asking for an outline and confirming it is cheaper than reviewing a finished briefing built on the wrong assumptions. Work that is checkable where the decision is made beats work only checkable at the end.

Where candidates go wrong

How to study this domain

Work backwards from failures rather than forwards from rules. Take five things you have actually asked Claude for and, for each, write down the four facts a competent colleague would have needed: who reads this, what it is for, how long it should be, and what the source material is. Most weak prompts are missing at least two. Doing this five times builds the reflex the exam rewards — spotting the absent constraint quickly, under time pressure.

Then practise the three transformations that account for most correct answers here. Convert a list of prohibitions into positive specifications. Convert a described standard into a worked example. Convert a five-part request into an ordered sequence with a checkpoint after the first step. Do each on a real task and note how the output changes; the difference is large enough to remember. Finally, sit practice questions from this domain and watch for options offering another iteration of the same vague ask, or asking Claude to explain itself. Those two patterns are distractors far more often than answers.

Common questions