Quick Reference: Domain 7 — Troubleshooting and Optimisation

Every question 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 choosing 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 request that gave too little information is a prompt problem, fixed by a better brief.
• The clue 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 repeats the same cost forever and leaves the cause in place.

On the exam: run the routing question before reading the options. When the question says every output has the defect, the right answer fixes the configuration once. The wrong option rewrites today's prompt.

Six causes cover nearly everything, and each has its own fix. Context starvation, a request without the context it needs, 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. Anthropic's Academy adds that the quality of Claude's answers can get worse in a very long conversation. A new chat with a short summary can then do better.

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 investigate.
• Too-brief responses are a prompting problem: revise the prompt, and give Claude the previous prompt and response so that it continues from the point where it stopped.
• Error messages are not quality defects: a capacity notice means wait briefly and retry. A length-limit message means split the content into parts, summarise key sections, or start a new conversation. Rewording the request does not address what the message is about.
• The escalation reflex is the domain's favourite trap: a vague brief fails with every model and every effort level, so a more capable model or higher effort produces 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 is tested by exam questions:

• Change one thing at a time. Change only the audience line and the draft improves: that change applies to other tasks that fail for the same reason. One change does not give a better draft than a bundled change. It tells you which change worked. Change the wording, the model and the example in one round: one of three things worked, nobody knows which. The exam makes the bundled change look decisive.
• Hold the test input fixed. A new prompt tried on a new document tells you nothing, because two things changed. Choose a typical input. Edit your first message and send it again, so each round starts from the same input. A request to rewrite the last draft starts from the old draft. One good result is not proof: run the old and the new wording on the same input before you adopt the new one.
• 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 wrong, or the same clarifying question asked three times, locates the gap more precisely than re-reading the text yourself.

Know when to stop: stop when the draft passes the criterion you wrote before the round. The third failed adjustment round is a signal to go back to 7.1's cause list and re-diagnose, not a reason to reword again. Sources note: Anthropic's Academy teaches one change at a time and the same test prompts each round, for improving a Skill. The Help Center's advice stops at giving Claude feedback and asking for rewrites. The stated criterion is ordinary professional method based on the exam guide's objective wording.

Optimising differs from fiddling because it starts from a measured 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.

Skill: a set of instructions that tells Claude how to do one kind of task. Claude loads it when a request refers to the Skill's name or description, in any chat. You or your organisation create custom Skills. They need the Code execution and file creation setting, and on Team and Enterprise plans an organisation Owner controls them. Skills now do the job of the deprecated Styles menu.

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 belongs to Domain 4.2.

• 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 an optimisation that Anthropic recommends.
• 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 spends time and usage on depth it never uses, and deep analysis rushed at a low setting is too shallow for the task. The choice itself is Domain 3.3's; it appears here starting from the symptom, 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 does not justify a Project, request template or afternoon of setup. The setup and upkeep cost more than the time saved, and whatever is built becomes out of date between uses.

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