Prompting & Task Execution

Prompting & Task Execution is 14% of the exam, roughly eight or nine items, and it tests writing rather than engineering. Each question puts a vague business request in front of you and asks what would turn it into work Claude can actually do well: naming the reader, fixing format and length, stating the constraints in checkable terms, supplying the source material, or showing one example of what good looks like.

The exam's favorite wrong answer is the polite non-change. Telling Claude to be more detailed or more strategic when the real defect is that nobody said who is reading the document or how long it should be will not move the output. Its second favorite is starting over: deleting a near-miss draft and re-prompting from scratch instead of pointing at the two paragraphs that are wrong.

The idea that unlocks the domain is this. A confident, generic answer is almost always a symptom of an underspecified request, not a weak model. Claude fills every gap you leave with the most average plausible thing. Close the gaps and the mush disappears.

• Name the reader first. The same facts written for the CFO and for the implementation team are two different documents. Audience decides tone, depth and what gets cut.
• Fix format and length in the request. Say one page, five bullets, no preamble, table with owners. Not "keep it brief."
• State constraints, not adjectives. A constraint can be checked: under 200 words, no acronyms, must mention the September deadline. "Compelling" cannot be checked, so it changes nothing.
• Supply the source material. If the facts live in a contract, a transcript, a deck or a spreadsheet, provide them. Internal context is not knowable unless you give it.
• Show one example of good. A short sample of the structure and tone you want moves output further than a paragraph describing them.
• Give the purpose, not just the task. "So the steering committee approves the budget" tells Claude what to emphasize when it has to trade something off.
• Put the ask up front, background after. A request buried under three paragraphs of context gets answered loosely.
• One prompt for a bounded deliverable; a conversation for anything with judgment calls, unknowns or dependent stages.
• Decompose big work into checkable stages — themes, outline, one section, full draft, polish — and approve each stage before the next.
• Ask for the artifact you will ship. If you need a risk table with owners and dates, ask for that, not for "thoughts on risk."
• Iterate on what is nearly right. Quote the weak passage, say what is wrong and what it should say instead. You keep the 80% that worked.
• When the answer must be checkable, ask for it in a checkable shape — assumptions listed, sources named, the arithmetic shown.

• A revision the current draft already satisfies changes nothing. "Make it better" and "add more detail" are the classic examples. Name the defect and the target.
• Asking for everything at once — research, analysis, deck, email and FAQ in one request — returns a shallow version of each.
• Assuming internal knowledge. Codenames, org charts, pricing tiers, last quarter's numbers and what was agreed on Tuesday are not available unless supplied.
• Stacking adjectives instead of constraints. "Professional, strategic, punchy" is unmeasurable. A word count and a named reader are not.
• Confusing length with depth. "Write 2,000 words" pads. "Answer these five questions" deepens.
• Contradicting yourself in one request — comprehensive but one page, formal but conversational. Say which constraint wins.
• Restarting instead of steering. A new chat throws away the context that made the last attempt close, and usually reproduces the same gap.
• Never showing house style, then being disappointed it is missing. If you have a good past example, paste it.
• Accepting a draft because it reads well. Fluency is not accuracy; polished mush is still mush.
• Over-correcting. Rewriting the whole request when adding one constraint would have fixed it makes the next result harder to diagnose.
• Letting Claude guess rather than flag. Ask it to list what it would need from you, and it stops inventing the missing pieces.
• Treating a judgment-heavy task as a one-shot. If you would have briefed a junior colleague and then reviewed their outline, do that here too.

SCOPE — the order to build a request in, and a reminder that what you are really controlling is the scope of the task.

• S — Source. Supply the material. Paste the transcript, attach the contract, give the numbers. Never assume internal facts are known.
• C — Context. Who reads this and why. Audience and purpose decide almost everything downstream.
• O — Output. Format and length, stated in checkable terms: one page, five bullets, a table with owners, no preamble.
• P — Pattern. One example of what good looks like — a past deliverable, a sample paragraph, the structure you expect.
• E — Edit. Treat the first result as a draft. Quote the weak part, name the change, keep the rest.

When an answer comes back confident and generic, walk SCOPE and find the letter you skipped. It is almost always S or C.