CCAO-F · module 4 of 7 · 14% of the exam

Prompting and task execution

Weight: 14 percent of the exam. Tests whether you can diagnose why a Claude.ai response missed, and pick the change that actually fixes it.

What the exam expects

Almost every question in this domain hands you a disappointing result and asks what to change. The wrong answers are rarely absurd. They are the things busy people genuinely try: regenerate and hope, add "be creative", paste more background, switch to a bigger model, repeat the instruction three times. The skill being tested is diagnosis.

Four ingredients account for nearly every fix in this domain:

1. Specification. Audience, purpose, format, length, constraints. Missing specification produces generic, wrongly shaped, or wrongly targeted output.
2. Examples. Missing or unrepresentative examples produce inconsistent formatting and skewed classifications.
3. Structure. Instructions buried in pasted material, or a single turn asked to do four jobs, produce responses that answer the wrong question or cannot be corrected.
4. Reusable configuration. Repeated context that belongs in a Project or a custom skill, being retyped every session.

The framing worth carrying into the exam: treat Claude as a capable new colleague with no institutional knowledge and no memory of your norms. Anything you did not say, they do not know. The standard clarity test follows directly, and it appears on the exam: hand your written prompt to someone outside your team and ask them to do the task from it alone. If they cannot, the model will fail for the same reason.

Specification: what to state, and how

The default failure is a prompt containing a verb and a noun. "Write something about our new reporting feature" gives the model nothing to work with, so it fills the gap with generic marketing language and plausible sounding benefits the product may not have.

State these explicitly:

• Purpose and audience. What is this for, and who reads it. This governs vocabulary, depth, and what can be assumed.
• Format and structure. If a downstream consumer needs a table with named columns in a fixed order, say so precisely. "Well organised and easy to scan" hands the format decision back to the model, which is what produced narrative prose the first time.
• Length, as a shape. "400 words" is often overshot. "Four paragraphs of roughly 100 words each" is something the model can hold while writing. Separating drafting from cutting into an explicit second step also works well.
• What good looks like. Success criteria, or the standard the output will be judged against.
• What to do when information is missing. Frequently omitted and frequently tested. Without an instruction, a model building a forecast from a spreadsheet missing one row will produce a complete forecast with a plausible figure filling the gap. Instruct it to flag anything it cannot find rather than estimate.

Two style rules matter. First, say what you want rather than listing what to avoid: five prohibitions describe an enormous space of acceptable outputs without pointing at any of them, while "short declarative sentences in active voice with concrete commitments and dates" points directly. Second, when giving corrective feedback, name the defect and the fix. "Make it better" leaves the model optimising the surface it can see, which is why the wording changes and the buried lede stays buried.

Examples: the highest leverage single addition

Examples communicate format and judgment more precisely than description does. Three to five well chosen examples is the standard guidance, and they matter most for two failure modes.

Inconsistent formatting across a batch. When ten records come back in three shapes, the fix is worked input and output pairs, not the instruction "be consistent" (which does not say consistent with what) and not a prose description of the format (which is what already failed).

Skewed classification. A single example anchors the model toward that example's category. If one billing complaint is the only example, unrelated emails start landing in billing. The correction is a representative set covering the categories the task will encounter, ideally including a boundary case. Note the wrong diagnoses the exam offers here: reducing the taxonomy, moving the example later in the prompt, or declaring the task unsuitable for a chat interface.

Structure: where instructions go and how work is staged

Separate instructions from source material. A 40 page document pasted into a message with a one line request appended is a structural trap: the instruction is easy to lose in the volume. Put the instruction first, delimit the source clearly as its own block, and number the deliverables when there is more than one. Repeating the same instruction three times at the end is noise, not emphasis.

Stage multi step work. A single prompt asking for research, analysis, seven drafted sections, house style, and an executive summary gives you nothing to correct until everything is finished, so a wrong direction costs the whole report. Break it into stages with checkpoints: outline first, review and correct, then sections, then synthesis. The opposite overcorrection is also wrong: seven disconnected chats with no shared context produce seven inconsistent voices.

Give analytical tasks room to reason. For a recommendation among options, ask for the comparison against the stated criteria before the conclusion. This improves the answer and gives you something checkable. Asking for the conclusion first yields a justification written to support an answer already committed to.

Keep threads focused. Everything earlier in a conversation is available context. A two hour thread that drifted from budget variance into headcount planning into memo drafting will keep pulling in the abandoned figures. Telling the model to ignore the earlier material sometimes helps but does not remove it; a fresh chat carrying only what the current task needs is the reliable fix. Similarly, when 20 turns of refinement start reintroducing corrections you already made, consolidate every accumulated requirement into one explicit checklist and ask for a single revision that satisfies all of it.

Analyse large corpora in two passes. Sixty interview transcripts in one message yields generic themes with no traceability. Extract in a fixed structured format per interview, then synthesise themes from the extracts while keeping the interview references.

Projects, skills, and where context belongs

This is the product knowledge portion of the domain, and the exam tests the boundaries between the three containers.

Projects are available on every plan including Free, capped at five on Free. Paid plans add retrieval that scales large knowledge bases, and Team and Enterprise add sharing with view or edit permission levels, which is what makes a Project a standard for a group rather than a personal convenience.

Project knowledge is a curated reference set, not an archive. Loading six years of superseded board packs alongside the current one produces responses citing outdated figures. Prune to what is current, and state in the project instructions which source takes precedence when documents disagree. "Add everything so the model can judge relevance" is the instinct that causes the problem.

Skills package reusable guidance: a voice, an output format, or a repeatable procedure, written as instructions with optional reference files, enabled once and then applied automatically when a request matches the work they describe. Because a skill can carry real examples of finished work, including published writing samples as reference files is the right answer whenever someone knows their voice when they see it but struggles to describe it, which is a common scenario stem.

The most tested boundary: a skill is not a place for volatile facts. Pricing tables, product catalogues, and competitor comparisons crammed into a skill are in the wrong container, because they are knowledge that changes independently of the guidance, and a skill is applied when Claude judges it relevant rather than guaranteed in every chat. Equally, a 12 page voice guide belongs in project knowledge with the standing directions in project instructions, not pasted at the top of every chat.

Related deliverables follow one pattern: shared source material lives once in a Project, and each deliverable gets its own chat. Duplicating the source across three Projects means correcting it in three places and watching the copies diverge.

Iteration and self review

Iteration is a skill the exam tests directly. Effective iteration is specific, incremental, and preserves what already works. The failure modes:

• Regenerating the same prompt hoping for a better roll, when the missing information is still missing.
• Discarding a mostly good draft and starting over, when one sentence of feedback would fix it.
• Asking the model to rate its own work out of ten with no criteria supplied, then treating the number as a gate.

Self review works when the criteria are supplied. Handing Claude your nine point internal standard and asking it to check its draft against each point and state where it falls short surfaces obvious gaps before your review. It does not replace your review, and any option suggesting it does is wrong in this domain for the same reason it is wrong in the governance domain.

For work that must be faithful to source documents, require per claim attribution back to the specific document and section, and require an explicit statement when something is not found. That turns an unverifiable comparison into a checkable one.

How to think through the question

Domain 4 scenarios follow a stable shape: a described attempt, a described disappointment, and four candidate fixes. Work backwards from the symptom.

Signal words in the scenario.

• "Generic", "vague", "not what I meant" points at missing specification.
• "Inconsistent", "different formats", "some did, some did not" points at missing or unrepresentative examples.
• "Ignored my instruction", "summarised the whole thing instead" points at structure, usually an instruction buried in pasted material.
• "Every time", "every chat", "15 times a week" points at reusable configuration, meaning a Project or a skill.
• "Kept pulling in", "reintroduced", "two hours in" points at accumulated context, meaning consolidate or start fresh.
• A confident number, figure, or citation appearing where the input did not have one points at a missing instruction about gaps.

Reasoning procedure.

1. Name the symptom in one phrase before reading the options.
2. Map the symptom to the missing ingredient: specification, examples, structure, or configuration.
3. Ask what the question wants: the single most effective change, the root cause, or the better approach. "Most improves" wants one change, so an option that fixes something real but not the stated symptom is out.
4. Eliminate options that add volume without adding information: longer prompts, repeated instructions, more background, more regenerations.
5. Eliminate options that reach for a product lever when the prompt is the problem, and options that abandon the task rather than fix it.
6. Among the survivors, prefer the one that changes the input the model actually acts on, and that works the next time as well as this time.

Worked example. A brand manager pastes a 12 page voice and tone guide at the start of every chat before asking for copy, 15 to 20 times a week, and the pasting is eating her time. What should she change?

Step 1: the symptom is repeated manual re entry of stable material, not poor output quality. Step 2: "every chat, 15 to 20 times a week" maps to reusable configuration. Step 3: the question asks what she should change, so I want the structural fix. Step 4: condensing the guide to three bullets saves typing by discarding most of the guidance, trading away the quality she is protecting. Step 5: one long running chat avoids the pasting but creates the accumulated context problem this domain warns about. The custom skill option is the strongest distractor because skills do capture reusable voice guidance, but a skill is applied when judged relevant, while this recurring body of work wants the deterministic scope of a Project holding both the reference material and the standing directions. Step 6: the remaining option, a Project with the guide in project knowledge and the standing directions in project instructions, fixes the cause and keeps working every week.

Exam traps

• Regenerating instead of specifying. Variation between attempts feels like a free retry, but it cannot supply information the prompt never contained.
• Reaching for a bigger model when the brief is empty. The most capable model still does not know what your feature does. Model choice is Domain 5 territory; this is a specification failure.
• Believing longer prompts are better prompts. Effective prompts often are longer, but length from padding buries the instruction. Length correlates with quality, it does not cause it.
• Repeating an instruction for emphasis. Three copies of the same sentence add noise. Structure (instruction first, delimited source, numbered deliverables) is what makes an instruction land.
• Putting facts in a skill. Skills hold reusable guidance, not volatile reference data. Pricing, catalogues, and reference data belong in project knowledge or the prompt.
• Putting task specifics in project instructions. This week's competitor, deadline, or stakeholder question changes every run, so it belongs in the chat. Standing rules belong in the project.
• Loading everything into project knowledge. More sources make conflicts harder to resolve, not easier. Curate, and state precedence.
• Listing prohibitions instead of the target. Five things to avoid do not describe what you want. Say the thing you want.
• Giving vague feedback. "Make it better" produces rewording. Name the defect and the fix.
• Trusting an unanchored self assessment. A score out of ten with no criteria supplied encodes nothing. Give the model the standard, and keep your own review.
• Splitting related work into isolated chats. Isolation removes shared context that the deliverables need. Shared source in a Project, separate chats per deliverable, is the pattern.
• Letting the model fill gaps silently. Without an instruction to flag missing inputs, plausible figures appear where data was absent.

Quick reference

• Specify: purpose, audience, format, length as a shape, success criteria, and what to do when information is missing.
• Examples: three to five, representative of the full range, especially for formatting consistency and classification.
• Structure: instruction first, source material delimited, deliverables numbered.
• Stage multi step work with checkpoints; ask for reasoning before conclusions on analytical tasks.
• Long or drifted threads: consolidate requirements into a checklist, or start a clean chat with only what is needed.
• Large corpora: structured extraction per item, then synthesis over the extracts, preserving references.
• Projects: available on all plans, five maximum on Free, RAG scaling on paid, sharing with view or edit permissions on Team and Enterprise.
• Project knowledge holds reference material; project instructions hold standing rules; the chat holds task specifics.
• Skills package reusable voice, format, and task guidance; write the instructions and include real examples as reference files.
• Iterate with specific corrective feedback; self review works only against supplied criteria and never replaces human review.
• Clarity test: if a capable outsider cannot perform the task from your written prompt, neither can Claude.