Scenario practice questions

Refer to the exhibit. In a parallel tool-use scenario where Claude generates three such blocks in a single response, how should the orchestration layer handle the 'tool_result' messages to ensure Claude can correctly process the outputs?

Exhibit

{
  "type": "tool_use",
  "id": "toolu_01",
  "name": "get_weather",
  "input": {"location": "San Francisco, CA"}
}

Trap 1: Combine all three tool outputs into a single 'tool_result' block…

Combining results into one block is incorrect because the model expects a one-to-one mapping between its 'tool_use' IDs and the 'tool_result' blocks. Failing to provide individual results with matching IDs will cause a validation error or cause the model to lose track of which tool call produced which specific piece of data.

Trap 2: Send three separate API requests, each containing one tool result…

While this might work, it is highly inefficient and creates unnecessary round-trips. The Anthropic API is designed to accept multiple 'tool_result' blocks within a single 'user' message. Sending them sequentially significantly increases latency and breaks the parallel nature of the original request, slowing down the overall agentic loop.

Trap 3: Wait for the user to manually approve each tool result before…

While HITL is possible, it is not a requirement for parallel tool use and would drastically impede the performance of an automated agent. The orchestration layer's primary responsibility is to execute the tools and return the data; manual approval should be reserved for high-impact actions rather than every informational tool call.

A
Combine all three tool outputs into a single 'tool_result' block for efficiency
Why it fails: Combining results into one block is incorrect because the model expects a one-to-one mapping between its 'tool_use' IDs and the 'tool_result' blocks. Failing to provide individual results with matching IDs will cause a validation error or cause the model to lose track of which tool call produced which specific piece of data.
B
Send three separate API requests, each containing one tool result in sequence
Why it fails: While this might work, it is highly inefficient and creates unnecessary round-trips. The Anthropic API is designed to accept multiple 'tool_result' blocks within a single 'user' message. Sending them sequentially significantly increases latency and breaks the parallel nature of the original request, slowing down the overall agentic loop.
C
Return a single 'user' message containing three 'tool_result' blocks with matching IDs
This is the correct architectural approach for parallel tool use. By including all results in one 'user' role message, the architect ensures that Claude receives all the requested information at once. Each block must include the 'tool_use_id' that matches the ID from the model's original 'tool_use' request.
D
Wait for the user to manually approve each tool result before sending them back
Why it fails: While HITL is possible, it is not a requirement for parallel tool use and would drastically impede the performance of an automated agent. The orchestration layer's primary responsibility is to execute the tools and return the data; manual approval should be reserved for high-impact actions rather than every informational tool call.

Question 2easymultiple choice

In the context of agentic orchestration, what is the primary purpose of a 'ReAct' (Reason-Act) loop?

Trap 1: To allow the model to rewrite its own system prompt dynamically…

The ReAct pattern does not involve the model modifying its own system prompt. Such behavior would be highly unstable and is generally avoided in robust agentic architectures. Instead, ReAct focuses on using the conversation history to guide the model's internal reasoning and tool selection process.

Trap 2: To reduce the latency of the API response by skipping the output of…

ReAct actually increases latency because the model must generate more tokens (the reasoning steps) before it gets to the actual tool call. However, the trade-off is often worth it because the increased accuracy and reliability of the agent outweigh the slightly longer response time.

Trap 3: To provide a way for the model to access historical data that was…

ReAct does not provide access to data outside the context window. It only helps the model better utilize the information that is already present in the context. For accessing historical data outside the window, architectures like RAG (Retrieval-Augmented Generation) or external memory systems must be used.

A
To allow the model to rewrite its own system prompt dynamically during execution.
Why it fails: The ReAct pattern does not involve the model modifying its own system prompt. Such behavior would be highly unstable and is generally avoided in robust agentic architectures. Instead, ReAct focuses on using the conversation history to guide the model's internal reasoning and tool selection process.
B
To encourage the model to verbalize its internal reasoning before executing a tool.
By forcing Claude to 'think' out loud, the ReAct pattern leverages the model's autoregressive nature. The generated 'Thought' tokens act as a form of working memory, helping the model stay on track and reducing errors by ensuring the reasoning logic is established before the tool call is generated.
C
To reduce the latency of the API response by skipping the output of text blocks.
Why it fails: ReAct actually increases latency because the model must generate more tokens (the reasoning steps) before it gets to the actual tool call. However, the trade-off is often worth it because the increased accuracy and reliability of the agent outweigh the slightly longer response time.
D
To provide a way for the model to access historical data that was not included in the context window.
Why it fails: ReAct does not provide access to data outside the context window. It only helps the model better utilize the information that is already present in the context. For accessing historical data outside the window, architectures like RAG (Retrieval-Augmented Generation) or external memory systems must be used.

Question 3mediummultiple choice

A financial services company is building a customer support assistant that needs to handle loan applications, account balance checks, and general FAQ queries. Which orchestration pattern should be used to minimize token usage while ensuring that the model uses specific system instructions for each distinct task?

Trap 1: The Parallelized Workflow pattern

This pattern is intended for tasks that can be broken down into independent sub-tasks executed simultaneously. Since the user's query only requires one of the three service types at a time, running multiple parallel processes would lead to unnecessary computational waste and increased latency without providing any functional benefit for categorization.

Trap 2: The Evaluator-Optimizer pattern

This pattern focuses on an iterative loop where one model generates a response and another critiques it to improve the final output. While useful for high-quality creative writing or coding tasks, it is inefficient for simple intent-based routing and would significantly increase latency and costs for a standard support assistant.

Trap 3: The Autonomous Agent pattern

Autonomous agents are best for open-ended tasks where the model must decide which steps to take dynamically. For structured business processes like bank support, an autonomous approach is often too unpredictable and difficult to control compared to a deterministic routing logic that enforces strict adherence to specific company protocols.

A
The Parallelized Workflow pattern
Why it fails: This pattern is intended for tasks that can be broken down into independent sub-tasks executed simultaneously. Since the user's query only requires one of the three service types at a time, running multiple parallel processes would lead to unnecessary computational waste and increased latency without providing any functional benefit for categorization.
B
The Router pattern
Routing allows the system to identify the specific domain of a query before applying detailed logic. By selecting a specialized prompt or toolset based on the classification, the architecture maintains high precision for complex tasks like loan applications while keeping the context window focused and cost-effective for simpler queries.
C
The Evaluator-Optimizer pattern
Why it fails: This pattern focuses on an iterative loop where one model generates a response and another critiques it to improve the final output. While useful for high-quality creative writing or coding tasks, it is inefficient for simple intent-based routing and would significantly increase latency and costs for a standard support assistant.
D
The Autonomous Agent pattern
Why it fails: Autonomous agents are best for open-ended tasks where the model must decide which steps to take dynamically. For structured business processes like bank support, an autonomous approach is often too unpredictable and difficult to control compared to a deterministic routing logic that enforces strict adherence to specific company protocols.

Question 4easymultiple choice

A team is exposing an internal inventory database to Claude through an MCP server. They want the model to retrieve a specific item by its SKU, and they want the tool contract to be unambiguous so the model rarely mis-calls it. Which tool definition best matches this goal?

Trap 1: A `query_inventory` tool that takes no parameters and returns the…

A no-parameter tool cannot target a specific SKU, so every call returns the entire table, wasting context and making the model filter the result itself. That shifts work onto the model and increases the chance of an incorrect answer. It also fails the stated requirement to retrieve a specific item by SKU.

Trap 2: A `query_inventory` tool with optional `sku`, `name`, `category`,…

Four optional fields with no required field means the model can call the tool with nothing useful, or with the wrong field populated. The ambiguity increases the chance of malformed or unhelpful calls. For a lookup keyed on SKU, this design is strictly worse than a single required field.

Trap 3: A `query_inventory` tool that accepts a free-form SQL `where`…

A free-form SQL fragment invites injection, makes validation impossible, and forces the model to know the database schema. It also produces highly variable calls that are hard to test. While flexible, it is the opposite of an unambiguous contract and would increase mis-calls rather than reduce them.

A
A `query_inventory` tool that takes no parameters and returns the full inventory table.
Why it fails: A no-parameter tool cannot target a specific SKU, so every call returns the entire table, wasting context and making the model filter the result itself. That shifts work onto the model and increases the chance of an incorrect answer. It also fails the stated requirement to retrieve a specific item by SKU.
B
A `query_inventory` tool with optional `sku`, `name`, `category`, and `warehouse` fields, none required.
Why it fails: Four optional fields with no required field means the model can call the tool with nothing useful, or with the wrong field populated. The ambiguity increases the chance of malformed or unhelpful calls. For a lookup keyed on SKU, this design is strictly worse than a single required field.
C
A `query_inventory` tool that accepts a free-form SQL `where` clause string.
Why it fails: A free-form SQL fragment invites injection, makes validation impossible, and forces the model to know the database schema. It also produces highly variable calls that are hard to test. While flexible, it is the opposite of an unambiguous contract and would increase mis-calls rather than reduce them.
D
A `query_inventory` tool whose input schema has a single required string field named `sku`.
A single required string field named `sku` gives the model one obvious thing to supply and nothing to guess about. The narrow contract reduces ambiguity, so the model is unlikely to invent extra parameters or omit the required one. This directly serves the goal of a low-mis-call tool for SKU lookup.

Question 5easymultiple choice

A support agent has two tools: `search_knowledge_base` and `escalate_ticket`. For simple questions it should answer directly; for unresolved issues it should escalate. Which `tool_choice` setting best supports this behavior?

Trap 1: `{"type": "none"}`

`none` disables tool use entirely, so the agent could never search the knowledge base or escalate a ticket. That removes the core capabilities the scenario requires. It is intended for turns where tools must be suppressed, not for a general-purpose support agent.

Trap 2: `{"type": "any"}`

`any` forces the model to call one of the available tools on every turn, so it could never answer a simple question directly. That contradicts the requirement to handle straightforward questions without escalation. It is useful when a tool call is mandatory, which is not the case here.

Trap 3: `{"type": "tool", "name": "escalate_ticket"}`

Forcing `escalate_ticket` would route every interaction to human escalation, including trivial questions the agent should resolve. It also prevents use of the knowledge base tool. This setting is appropriate only when a specific tool must always be invoked, which is the opposite of the desired mixed behavior.

A
`{"type": "none"}`
Why it fails: `none` disables tool use entirely, so the agent could never search the knowledge base or escalate a ticket. That removes the core capabilities the scenario requires. It is intended for turns where tools must be suppressed, not for a general-purpose support agent.
B
`{"type": "auto"}`
With `auto`, the model decides whether to call a tool or respond directly in text. That matches the scenario, where the agent should answer simple questions without tools and only call `search_knowledge_base` or `escalate_ticket` when needed. It preserves flexibility across both outcomes and is the API default.
C
`{"type": "any"}`
Why it fails: `any` forces the model to call one of the available tools on every turn, so it could never answer a simple question directly. That contradicts the requirement to handle straightforward questions without escalation. It is useful when a tool call is mandatory, which is not the case here.
D
`{"type": "tool", "name": "escalate_ticket"}`
Why it fails: Forcing `escalate_ticket` would route every interaction to human escalation, including trivial questions the agent should resolve. It also prevents use of the knowledge base tool. This setting is appropriate only when a specific tool must always be invoked, which is the opposite of the desired mixed behavior.

Question 6hardmultiple choice

A team is extracting medication names and dosages from clinical notes. The notes contain many similar-looking terms, and the team needs high precision to avoid false positives. They plan to use few-shot examples. Which design of the few-shot examples best supports high precision in this scenario?

Trap 1: Provide many examples of correct extractions only, covering a wide…

Positive-only examples teach the model what to extract but not what to avoid. In clinical notes with similar-looking terms, the model may over-extract and reduce precision. The scenario needs the model to distinguish true medication mentions from lookalikes. Without contrastive examples, the boundary remains unclear, so this design does not directly support high precision.

Trap 2: Randomly sample examples from the dataset without regard to…

Random sampling may include mostly easy cases and few of the confusing lookalikes that cause false positives. In this scenario, the hard cases are exactly what the model needs to see. Random examples do not target the precision problem, so the model may still over-extract on similar terms. Curating examples for difficulty and contrast is more effective.

Trap 3: Use a single detailed example and rely on the model to generalize…

One example cannot convey the variety of medication names, dosages, and lookalikes in clinical notes. Generalization from a single case is unreliable, especially for precision-sensitive extraction. In this scenario, the model would likely miss the nuanced boundary between real and false mentions. This design under-specifies the task and risks both missed and spurious extractions.

A
Include a mix of positive examples and carefully chosen hard negatives that resemble medications but should not be extracted.
Hard negatives show the model the boundary between true medication mentions and lookalikes, which directly improves precision. In this scenario, where similar terms cause false positives, contrastive examples clarify what to exclude. This design teaches the decision boundary rather than only the target class, making it the most effective choice for high precision.
B
Provide many examples of correct extractions only, covering a wide range of medication names.
Why it fails: Positive-only examples teach the model what to extract but not what to avoid. In clinical notes with similar-looking terms, the model may over-extract and reduce precision. The scenario needs the model to distinguish true medication mentions from lookalikes. Without contrastive examples, the boundary remains unclear, so this design does not directly support high precision.
C
Randomly sample examples from the dataset without regard to difficulty or similarity.
Why it fails: Random sampling may include mostly easy cases and few of the confusing lookalikes that cause false positives. In this scenario, the hard cases are exactly what the model needs to see. Random examples do not target the precision problem, so the model may still over-extract on similar terms. Curating examples for difficulty and contrast is more effective.
D
Use a single detailed example and rely on the model to generalize to all other notes.
Why it fails: One example cannot convey the variety of medication names, dosages, and lookalikes in clinical notes. Generalization from a single case is unreliable, especially for precision-sensitive extraction. In this scenario, the model would likely miss the nuanced boundary between real and false mentions. This design under-specifies the task and risks both missed and spurious extractions.

Question 7mediummulti select

You are designing a prompt that asks Claude to review a pull request and return findings in a strict XML structure with a severity attribute for each finding. Your parser depends on the structure being consistent. Which TWO techniques most directly improve the consistency of the XML output? (Choose two.)

Trap 1: Ask the model to return the findings as a Markdown bulleted list…

Markdown lists do not carry the severity attribute or the nested structure the parser expects. In this scenario, this format would fail parsing and lose the required metadata. Readability for humans is not the goal when a downstream system consumes the output. This choice conflicts with the stated XML requirement.

Trap 2: Set the temperature to a high value so the model explores different…

Higher temperature increases variation, which is the opposite of what a strict parser needs. In this scenario, diverse layouts would break parsing and make findings harder to consume. Exploration is useful for creative tasks, not for fixed structural contracts. This setting would actively harm output consistency.

Trap 3: Instruct the model to think step by step before producing the XML.

Step-by-step reasoning can improve analysis quality, but it does not guarantee XML structure. In fact, it may add prose before the XML unless the instructions explicitly separate reasoning from output. In this scenario, the parser needs consistent tags, not better reasoning. This technique addresses a different problem than output consistency.

A
Ask the model to return the findings as a Markdown bulleted list for readability.
Why it fails: Markdown lists do not carry the severity attribute or the nested structure the parser expects. In this scenario, this format would fail parsing and lose the required metadata. Readability for humans is not the goal when a downstream system consumes the output. This choice conflicts with the stated XML requirement.
B
Set the temperature to a high value so the model explores different XML layouts.
Why it fails: Higher temperature increases variation, which is the opposite of what a strict parser needs. In this scenario, diverse layouts would break parsing and make findings harder to consume. Exploration is useful for creative tasks, not for fixed structural contracts. This setting would actively harm output consistency.
C
Instruct the model to think step by step before producing the XML.
Why it fails: Step-by-step reasoning can improve analysis quality, but it does not guarantee XML structure. In fact, it may add prose before the XML unless the instructions explicitly separate reasoning from output. In this scenario, the parser needs consistent tags, not better reasoning. This technique addresses a different problem than output consistency.
D
Describe the required tags and attributes precisely in the instructions, specifying allowed severity values.
Explicit, precise instructions define the contract the model must follow. In this scenario, naming the tags and enumerating allowed severity values removes ambiguity about what to emit. Clear specifications complement examples and reduce structural drift. This is a direct lever for making the XML consistent enough for a parser.
E
Provide a short example of the exact XML structure expected, including the severity attribute.
A concrete example anchors the model to the exact tags and attributes you need. In this scenario, showing a sample finding with a severity attribute makes the required shape unambiguous. Examples are especially effective for structural requirements like nested tags and attribute names. This directly reduces variation in the output format that the parser depends on.

Question 8easymultiple choice

Which property of a well-structured prompt contributes most significantly to the reliability of a model's output in a zero-shot scenario?

Trap 1: Using a highly complex and verbose prompt to cover all possible…

Excessive verbosity can lead to 'prompt noise,' where the model may lose track of the core instructions among less important text. Clear, concise, and structured instructions are far more reliable than long, rambling prompts. Over-complicating prompts makes it difficult to debug failures and maintain the system over time.

Trap 2: Writing the prompt in a conversational tone to make the model feel…

Anthropomorphizing the model or using a conversational tone does not improve reliability or performance. Models respond best to direct, objective, and task-oriented language. A conversational style adds irrelevant tokens to the context, which can potentially distract the model from the primary task requirements, leading to less consistent outputs.

Trap 3: Omitting examples to allow the model to show its full range of…

Providing examples (few-shot prompting) is actually one of the most effective ways to improve reliability. By providing examples, you ground the model's output in the expected pattern, making the results predictable. Omitting examples removes this guidance, increasing the risk of the model producing inconsistent or undesirable results.

A
Using a highly complex and verbose prompt to cover all possible edge cases.
Why it fails: Excessive verbosity can lead to 'prompt noise,' where the model may lose track of the core instructions among less important text. Clear, concise, and structured instructions are far more reliable than long, rambling prompts. Over-complicating prompts makes it difficult to debug failures and maintain the system over time.
B
Providing clear, domain-specific instructions and output format constraints.
Structured prompts with specific instructions and format requirements (like JSON) drastically improve reliability. By defining exactly what the output should look like, you reduce the model's freedom to hallucinate or deviate from the desired format. This level of clarity is the gold standard for production-ready prompt engineering.
C
Writing the prompt in a conversational tone to make the model feel more comfortable.
Why it fails: Anthropomorphizing the model or using a conversational tone does not improve reliability or performance. Models respond best to direct, objective, and task-oriented language. A conversational style adds irrelevant tokens to the context, which can potentially distract the model from the primary task requirements, leading to less consistent outputs.
D
Omitting examples to allow the model to show its full range of reasoning.
Why it fails: Providing examples (few-shot prompting) is actually one of the most effective ways to improve reliability. By providing examples, you ground the model's output in the expected pattern, making the results predictable. Omitting examples removes this guidance, increasing the risk of the model producing inconsistent or undesirable results.

Question 9mediummultiple choice

Which of the following describes the 'Chain of Thought' prompting strategy, and why should it be used for complex logic tasks?

Trap 1: Providing the model with a list of facts and asking it to select…

This describes a retrieval-based or selection task, not a reasoning process. While selecting facts is useful, it does not involve the iterative logical derivation characteristic of Chain of Thought. It lacks the step-by-step processing that helps the model navigate complex dependencies and multi-stage problems effectively.

Trap 2: Instructing the model to write its output in a specific programming…

This is a structural formatting instruction, not a reasoning strategy. While formatting is important for consumption by other systems, it does not inherently help the model improve the quality of its logical reasoning or reduce errors in complex multi-step analysis. It is purely about presentation, not problem-solving.

Trap 3: Forcing the model to repeat the user's prompt back to them to…

Repeating the prompt is a method to verify instruction adherence, but it does not improve reasoning quality. It consumes tokens unnecessarily and does not force the model to engage in any logical deduction. It is effectively a sanity check for intent, not a tool for enhancing deep cognitive performance.

A
Providing the model with a list of facts and asking it to select the most relevant one.
Why it fails: This describes a retrieval-based or selection task, not a reasoning process. While selecting facts is useful, it does not involve the iterative logical derivation characteristic of Chain of Thought. It lacks the step-by-step processing that helps the model navigate complex dependencies and multi-stage problems effectively.
B
Asking the model to outline its reasoning process step-by-step before providing the final answer.
Chain of Thought forces the model to articulate its logic, which acts as a self-correction mechanism. This step-by-step articulation allows the model to verify its own intermediate conclusions, leading to much higher accuracy for complex, multi-step logical problems compared to asking for a single-step final answer.
C
Instructing the model to write its output in a specific programming language format.
Why it fails: This is a structural formatting instruction, not a reasoning strategy. While formatting is important for consumption by other systems, it does not inherently help the model improve the quality of its logical reasoning or reduce errors in complex multi-step analysis. It is purely about presentation, not problem-solving.
D
Forcing the model to repeat the user's prompt back to them to ensure comprehension.
Why it fails: Repeating the prompt is a method to verify instruction adherence, but it does not improve reasoning quality. It consumes tokens unnecessarily and does not force the model to engage in any logical deduction. It is effectively a sanity check for intent, not a tool for enhancing deep cognitive performance.

Question 10mediummultiple choice

In a scenario where a project-specific .clauderc file and a global ~/.clauderc file both define a 'model' setting, which one takes precedence when Claude Code is launched from that project directory?

Trap 1: The global file always takes precedence to ensure consistency.

If the global file always won, developers would be unable to tailor Claude's behavior to the specific needs of different projects. This would limit flexibility, as a project requiring a specific model for legacy code compatibility would be forced to use whatever the global user preference happens to be.

Trap 2: The CLI will prompt the user to choose which one to use.

Prompting the user for every conflicting configuration setting would create a poor user experience and slow down the development workflow. Standard CLI behavior is to follow a deterministic hierarchy, allowing for automated and predictable configuration resolution without requiring constant manual intervention from the developer.

Trap 3: The settings are merged, and the CLI crashes if a conflict exists.

Crashing on configuration conflicts is not a standard or desirable behavior for professional developer tools. Most modern CLIs, including Claude Code, are designed to resolve these conflicts using a layered approach where the most specific configuration (the local one) naturally overrides the more general one.

A
The global file always takes precedence to ensure consistency.
Why it fails: If the global file always won, developers would be unable to tailor Claude's behavior to the specific needs of different projects. This would limit flexibility, as a project requiring a specific model for legacy code compatibility would be forced to use whatever the global user preference happens to be.
B
The CLI will prompt the user to choose which one to use.
Why it fails: Prompting the user for every conflicting configuration setting would create a poor user experience and slow down the development workflow. Standard CLI behavior is to follow a deterministic hierarchy, allowing for automated and predictable configuration resolution without requiring constant manual intervention from the developer.
C
The settings are merged, and the CLI crashes if a conflict exists.
Why it fails: Crashing on configuration conflicts is not a standard or desirable behavior for professional developer tools. Most modern CLIs, including Claude Code, are designed to resolve these conflicts using a layered approach where the most specific configuration (the local one) naturally overrides the more general one.
D
The project-specific file takes precedence over the global file.
In the standard configuration hierarchy, local or project-level settings override global or user-level settings. This allows developers to specify a more powerful model or specific MCP servers for a particular project without affecting their default setup for simpler tasks in other directories.

Review the full routing breakdown →

Question 11hardmultiple choice

When designing a multi-agent system where Claude acts as a 'Router,' how does the 'Lost in the Middle' phenomenon specifically impact context reliability, and how should it be mitigated?

Trap 1: It causes the model to forget the system prompt entirely.

The system prompt is handled separately from the message history and is generally highly resilient to context length issues. The 'lost in the middle' effect primarily impacts the retrieval of specific facts or instructions within the user message block or a large set of provided documents rather than the system persona.

Trap 2: It results in higher costs due to redundant token processing.

While processing large contexts is expensive, the 'lost in the middle' effect is a performance and reliability issue regarding accuracy, not a billing issue. Redundant processing is solved by prompt caching, whereas the retrieval accuracy issue is solved by better prompt engineering and structural organization of the input data.

Trap 3: It prevents the model from generating any output after 100k tokens.

Claude 3.5 models can successfully generate output even at the end of a full 200,000-token context window. The phenomenon does not cause a total failure of generation but rather a decrease in the model's ability to accurately attend to and utilize information that is not positioned at the boundaries.

A
It causes the model to forget the system prompt entirely.
Why it fails: The system prompt is handled separately from the message history and is generally highly resilient to context length issues. The 'lost in the middle' effect primarily impacts the retrieval of specific facts or instructions within the user message block or a large set of provided documents rather than the system persona.
B
It results in higher costs due to redundant token processing.
Why it fails: While processing large contexts is expensive, the 'lost in the middle' effect is a performance and reliability issue regarding accuracy, not a billing issue. Redundant processing is solved by prompt caching, whereas the retrieval accuracy issue is solved by better prompt engineering and structural organization of the input data.
C
It prevents the model from generating any output after 100k tokens.
Why it fails: Claude 3.5 models can successfully generate output even at the end of a full 200,000-token context window. The phenomenon does not cause a total failure of generation but rather a decrease in the model's ability to accurately attend to and utilize information that is not positioned at the boundaries.
D
It degrades retrieval accuracy for data in the center of the prompt.
Information located in the middle of a long prompt is statistically less likely to be recalled accurately than information at the start or end. To mitigate this, architects should place the most critical routing rules at the end of the prompt and use XML tags to clearly define the data boundaries.

Question 12mediummultiple choice

A developer wants Claude Code to automatically run the project's linter after every file edit, but only for files inside the `src/` directory. Where should this be configured so the behavior applies to all contributors of the repository?

Trap 1: In a `.claude/settings.local.json` file with a `PostToolUse` hook…

`settings.local.json` is intentionally gitignored and personal to one developer's checkout, so it cannot enforce a team-wide behavior. Even if it were shared, running the linter unconditionally would ignore the requirement to limit execution to files under `src/`, producing noise and failures for edits elsewhere in the repository.

Trap 2: In the user-level `~/.claude/settings.json` using a…

The user-level settings file lives on the individual developer's machine and is not shared through version control, so other contributors would never receive the rule. Additionally, `permissions.allow` only grants or denies tool execution; it does not trigger a command automatically after an edit, so no linter would ever run from this configuration.

Trap 3: In the top-level `CLAUDE.md` file with a natural-language…

`CLAUDE.md` supplies contextual guidance that Claude may follow as a model instruction, but it is not a deterministic enforcement mechanism. The model could skip the step, run it at the wrong time, or misinterpret the `src/` scope. Hooks exist precisely to guarantee a shell command executes reliably on the matching tool event.

A
In a `.claude/settings.local.json` file with a `PostToolUse` hook that runs the linter unconditionally.
Why it fails: `settings.local.json` is intentionally gitignored and personal to one developer's checkout, so it cannot enforce a team-wide behavior. Even if it were shared, running the linter unconditionally would ignore the requirement to limit execution to files under `src/`, producing noise and failures for edits elsewhere in the repository.
B
In the user-level `~/.claude/settings.json` using a `permissions.allow` rule that lists the linter binary.
Why it fails: The user-level settings file lives on the individual developer's machine and is not shared through version control, so other contributors would never receive the rule. Additionally, `permissions.allow` only grants or denies tool execution; it does not trigger a command automatically after an edit, so no linter would ever run from this configuration.
C
In a project-scoped `.claude/settings.json` file using a `hooks` entry with a `PostToolUse` matcher for the Edit and Write tools.
Project-scoped `.claude/settings.json` is committed to the repository, so every contributor inherits the same configuration. A `hooks` block with a `PostToolUse` matcher scoped to the Edit and Write tools fires the linter command after each file modification, and the hook command itself can filter to paths under `src/` before invoking the linter.
D
In the top-level `CLAUDE.md` file with a natural-language instruction telling Claude to run the linter after edits.
Why it fails: `CLAUDE.md` supplies contextual guidance that Claude may follow as a model instruction, but it is not a deterministic enforcement mechanism. The model could skip the step, run it at the wrong time, or misinterpret the `src/` scope. Hooks exist precisely to guarantee a shell command executes reliably on the matching tool event.