Quick Reference: Domain 7 — Troubleshooting and Optimisation

Every item in this domain starts after something has gone wrong. The tested skill is naming the cause of a poor result, not writing a good request in the first place; candidates lose marks by reaching for a fix before naming a cause.

• The one-sentence diagnostic: did that happen once, or does it happen every time? A bland summary from one under-briefed request is a prompt problem, fixed by a better brief.
• The tell is the word every: the same wrong tone, format or assumption in every output from the same Project means the setup is producing the defect, so the correction belongs in the Project's instructions or knowledge once. Changing it is Domain 5's work; recognising that it needs changing is yours.
• The per-instance patch is the trap: hand-correcting each output pays the same cost forever and leaves the cause in place.

On the exam: run the routing question before reading the options. When the stem says every output has the defect, the keyed answer fixes the configuration once; the distractor rewrites today's prompt.

Six causes cover nearly everything, and each has its own fix. Starvation is by far the most common.

Long-chat costs, as documented: the chat eventually hits its length limit, and longer conversations that trigger automatic context management consume more of your usage limit. No official source says long chats get slower or that Claude confuses topics; the case for starting fresh rests on what is documented.

On the exam: re-sending an overloaded list with the missed items in capitals supplies nothing new; the documented remedy is structural.

The Help Center names this objective's symptoms, and half the diagnosis is recognising which one is in front of you, because each has a different fix.

• Incorrect or misleading responses, including fabricated quotes that look right: Claude is not a singular source of truth, so scrutinise high-stakes claims and review cited sources.
• Hallucinated capability: working-looking links that fail, or a claimed email send. Claude has no access to email or any software not explicitly integrated, so the diagnosis is fabricated capability, not a delivery to chase.
• Too-brief responses are a prompting problem: retool the prompt, and give Claude the previous prompt and response so it picks up where it left off.
• Error messages are not quality defects: a capacity notice means wait briefly and retry. A length-limit message means chunk the content, summarise key sections, or start a new conversation. Rewording the request answers a question the system never asked.
• The escalation reflex is the domain's favourite trap: a vague brief fails at every tier, so a more capable model or higher effort buys the same generic answer at more cost. Escalate only when a sound brief shows the task genuinely needs depth (effort, extended thinking) or current outside information (web search, Research).

The point of a systematic adjustment round is knowledge you can reuse, not merely a different result. Three parts, each of which earns exam items:

• Change one thing at a time. Change only the audience line and the draft improves: that lesson transfers. Change the wording, the model and the example in one round: one of three things worked, nobody knows which. The exam dresses the bundled change up as decisiveness.
• Hold the test input fixed. A new prompt tried on a new document tells you nothing, because two things moved. Editing an earlier message branches the chat with its own artifacts, so each round starts from the same input and can be read against its predecessor.
• State the criterion before you look. "Better" is not a criterion; "an attendee can find the start time in five seconds" is. A criterion stated in advance stops your judgement drifting towards whatever the new draft happens to do well.

Reader reactions are results: a colleague saying the tone is off, or the same clarifying question asked three times, locates the gap more precisely than re-reading the text yourself.

Know when to stop: the third failed adjustment round is a signal to go back to 7.1's cause list and re-diagnose, not an invitation to reword harder. Honesty note: no Anthropic article teaches the one-variable, fixed-input, stated-criterion method; the Help Center's advice stops at giving Claude feedback and asking for rewrites, and the rest is ordinary professional method resting on the exam guide's objective wording.

The difference between optimising and fiddling is a number. About ten minutes of preamble, three or four times a week, justifies moving the preamble somewhere permanent; "the reporting workflow feels clunky" justifies nothing yet except timing it. Improve what you have observed, and claim no saving you did not measure.

The repeated-overhead test: anything you type, explain or attach at the start of every similar conversation is overhead, and recurring overhead belongs where it only has to exist once.

Boundary notes: spotting which piece belongs at which level is the tested skill; writing the configuration is Domain 5's work, and optimising the business process around Claude is Domain 4.2's ground.

• Batch related requests: the documented guidance is to group multiple related tasks or questions in a single message rather than fragmenting them across exchanges, and to be specific and concise so rounds of clarification never happen.
• Name your files: in a large Project, retrieval decides which material Claude actually works from. Well-named files help Claude understand and retrieve the right information, alongside referencing documents by name and grouping related documents in the same Project. Renaming a file so a stranger could tell what it contains is a real optimisation with a documented mechanism.
• Match the settings to the work: higher effort produces more thorough responses but takes longer and uses more of your usage allowance. Routine reformatting at maximum effort pays for depth it never uses, and deep analysis rushed at a low setting underserves the task. The choice itself is Domain 3.3's; it appears here symptom-first, when a pattern of slow, over-worked responses to routine work is itself the measurement.
• The proportion rule: a twenty-minute task performed once a year earns no Project, saved form or afternoon of setup. The arithmetic never pays back, and the maintained artefact quietly goes stale between uses.

On the exam: look for the measurement. The keyed answer moves measured, recurring overhead to where it exists once, or declines a setup that costs more than it saves; distractors optimise something untimed, or optimise everything indiscriminately.