Routing Question
The domain's one-sentence diagnostic: did that happen once, or does it happen every time? A one-off disappointment points at this request or this conversation; the same defect in every output of the same kind points at the setup.
Exam context: The word every in a question shows that the cause is in the Project's instructions or knowledge, where the correction belongs once. The wrong option rewrites today's prompt or hand-corrects the output again, repeating the same cost forever.
See also: 7.1 Diagnosing and Resolving Underperforming Prompts and Poor Outputs
Context Starvation
By far the most common cause of a poor output: a request with no audience, no purpose and no source material can only produce generic output. The documented remedy is to supply more, by giving as much context as possible, as if instructing someone with no background knowledge of the task.
Exam context: The fix supplies what was missing, never asks more forcefully. Emphasis, capitals and "make sure" lines give a request that lacks context nothing new.
See also: 7.1 Diagnosing and Resolving Underperforming Prompts and Poor Outputs
Instruction Overload
A request carrying a dozen requirements loses some of them. The documented remedy is structural: break complex requests into substeps, grouping and prioritising so the important requirements cannot be missed.
Exam context: Re-sending the same list with the missed items in capitals is the classic wrong option; it supplies nothing new, while splitting the request into substeps is the right fix.
See also: 7.1 Diagnosing and Resolving Underperforming Prompts and Poor Outputs
Configuration Defect
A defect produced by the setup rather than by any single request: a Project's instructions or knowledge producing the same wrong tone, format or assumption in every output. Absences count too, such as a spelling or tone standard that was never stated.
Exam context: Recognising that the configuration needs changing is this domain's skill; writing the change is Domain 5's work. Stale knowledge files produce recurring defects just as instructions do.
See also: 7.1 Diagnosing and Resolving Underperforming Prompts and Poor Outputs
Degraded Conversation
A long chat that has accumulated superseded drafts, corrections that were later contradicted, and unrelated topics, all of it material Claude has to work with. The professional fix is a fresh conversation carrying a verified summary of what still matters.
Exam context: The documented costs are practical: the chat eventually hits its length limit, and longer conversations that trigger automatic context management consume more of the usage limit. Anthropic's Academy adds that the quality of Claude's answers can get worse in a very long conversation.
See also: 7.1 Diagnosing and Resolving Underperforming Prompts and Poor Outputs
Named Failure Modes
The symptoms Anthropic's Help Center documents for this objective, each with its own fix. Incorrect or misleading responses, including fabricated quotes: scrutinise high-stakes claims and review cited sources. Hallucinated capability, such as claimed email sends and working-looking links that fail: Claude has no access to email or any software not explicitly integrated. Too-brief responses: revise the prompt, and give Claude the previous prompt and response.
Exam context: Half the diagnosis is recognising which documented symptom the question describes, because each has a different fix. Investigating the delivery of an email Claude claims to have sent is the recurring wrong option.
See also: 7.1 Diagnosing and Resolving Underperforming Prompts and Poor Outputs
Error Message
An operational notice, not a quality defect. 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.
Exam context: The wrong option treats the message as a quality problem and rewords the prompt, which does not address what the message is about.
See also: 7.1 Diagnosing and Resolving Underperforming Prompts and Poor Outputs
Escalation Reflex
Choosing a more capable model or a higher effort setting because an output disappointed, before any cause has been named. A vague brief fails with every model and every effort level, so escalation produces the same generic answer, more thoroughly, at more cost.
Exam context: The domain's favourite trap. Escalation is legitimate only after the brief is sound, when the task genuinely needs depth (effort, extended thinking) or current outside information (web search, Research).
See also: 7.1 Diagnosing and Resolving Underperforming Prompts and Poor Outputs
One-Variable Adjustment
The discipline of changing exactly one thing per adjustment round, so that an improvement can be attributed, repeated deliberately, and explained to a colleague. The bundled alternative, changing the wording, the model and the example at once, produces a better draft nobody can learn from.
Exam context: Wrong options present changing several things at once as decisive. Anthropic's Academy teaches the same rule for improving a Skill: change one thing at a time.
See also: 7.2 Adjusting Your Approach Based on Feedback and Results
Fixed Test Input
The same document, request and materials used for every adjustment round. When the input changes too, a better result may only mean an easier input, so the comparison teaches nothing.
Exam context: Editing an earlier message branches the chat, with artifacts of its own, so each round can be run from the same input and compared with the round before. Testing the adjusted prompt on a different document and crediting the prompt is the error that the wrong option makes.
See also: 7.2 Adjusting Your Approach Based on Feedback and Results
Criterion Stated in Advance
A pass-or-fail sentence written before the new output is read: "an attendee can find the start time in five seconds", not "better". Stating it in advance stops judgement drifting towards whatever the new draft happens to do well.
Exam context: Judging by feel after the fact lets a round that fixed nothing get accepted. A returned draft plus a stated criterion identifies which requirement failed; "the manager didn't like it" identifies nothing.
See also: 7.2 Adjusting Your Approach Based on Feedback and Results
Third Failed Round
The stopping signal for adjustment: when several well-aimed rounds have not changed the output, the assumption that the approach is right has failed. The response is to go back to the cause list and re-diagnose, not to try a fourth round with slightly different words.
Exam context: The re-diagnosis may point at different source material, a feature such as web search or Research, a different setting, or work that should not be handed over at all.
See also: 7.2 Adjusting Your Approach Based on Feedback and Results
Measure First
The rule that optimisation starts from a number: about ten minutes of preamble, three or four times a week, justifies moving the preamble somewhere permanent, while a workflow that merely feels clunky justifies nothing yet except timing it.
Exam context: The presence of a real measurement separates the right optimisation from the unmeasured reorganisation offered as a wrong option. Claim no saving you did not measure.
See also: 7.3 Optimising Workflows for Efficiency and Effectiveness
Repeated-Overhead Test
The question of where to put anything typed, explained or attached at the start of every similar conversation. Context and rules that stay the same go in a Project's instructions. Recurring reference material goes in Project knowledge. A near-identical weekly request goes in a request template. The steps or format of one kind of task go in a Skill. Preferences that apply to everything go in the account-wide Instructions in Settings. Each place reaches different chats. A Project's instructions and knowledge reach every chat in that Project. A request template reaches only the chat where you paste it. A Skill reaches any chat where the request matches it. The account-wide Instructions reach every chat.
Exam context: Spotting which piece of a repeated preamble belongs at which level is the tested skill; writing the configuration is Domain 5's work.
See also: 7.3 Optimising Workflows for Efficiency and Effectiveness
Skill
A set of instructions that tells Claude how to do one kind of task, for example its steps, format and tone. A Skill is available in any chat, inside or outside a Project. Claude loads it when a request refers to the Skill's name or description. You or your organisation create custom Skills. Skills need the Code execution and file creation setting. On Team and Enterprise plans, an organisation Owner controls them.
Exam context: Use a Skill for the steps or format of one kind of task that you want in any chat. Project instructions reach every chat in one Project, so a single task does not belong there when the Project also holds other work, or when the task is needed outside the Project. Skills now do the job of the deprecated Styles menu.
See also: 7.3 Optimising Workflows for Efficiency and Effectiveness
Batching
Grouping multiple related tasks or questions in a single message rather than fragmenting them across exchanges, paired with being specific and concise so rounds of clarification never happen. A documented way to save both time and usage.
Exam context: Ten related questions sent as ten separate messages is the pattern to avoid; fragmentation spends usage and spreads context across messages that one fuller message would have kept together.
See also: 7.3 Optimising Workflows for Efficiency and Effectiveness
Well-Named Files
Files whose names state what each document contains, replacing versions, initials and abbreviations only their owner understands. In a large Project, retrieval decides which material Claude actually works from, and well-named files help Claude understand and retrieve the right information.
Exam context: Renaming for retrieval is an optimisation that Anthropic recommends, alongside referencing documents by name and grouping related documents in the same Project.
See also: 7.3 Optimising Workflows for Efficiency and Effectiveness
Proportion Rule
The recognition that some overhead is not worth removing: 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.
Exam context: In this domain's hardest questions, deciding not to optimise, on the numbers, is the right answer. Count upkeep in the arithmetic, not just setup.
See also: 7.3 Optimising Workflows for Efficiency and Effectiveness