Claude Certified Architect - Foundations (CCAR-F) Exam Questions

Domain 1: Agentic Architecture and Orchestration (27%)

In a multi-agent research system, the web search subagent’s harness gets a response with stop_reason “max_tokens”. The last content block is a tool_use block whose input JSON stops partway through a field. What should the harness do next?

⬜ Treat the response as complete and pass the text generated so far to the coordinator as the final result.
⬜ Append a tool_result with is_error set to true for the truncated call and continue the loop.
⬜ Run the tool with the partial input after repairing the JSON by closing the unfinished braces.
⬜ Retry the request with a higher max_tokens value, then execute the complete tool call it returns.

A research coordinator’s harness treats a run as finished when the assistant text contains “Research complete”, and it also treats reaching its 15-turn cap as a normal finish. Both checks misfire in production. How should the harness detect completion?

⬜ Check the final ResultMessage.stop_reason and treat the value “end_turn” as a completed run.
⬜ Read the stream through to its ResultMessage, treat subtype “success” as completion and handle “error_max_turns” as an incomplete run.
⬜ Tell the report subagent to end its final answer with a fixed marker token and stop the loop when that token appears.
⬜ Stop reading at the first assistant message that has no tool calls and treat it as the finished report.

A research system must escalate a source conflict to a human analyst: a 2022 government report gives a 12% market share and a 2024 industry survey using a different method gives 31%. Analysts can’t see session transcripts and triage each case in a few minutes. How should the handoff be written?

⬜ A structured handoff with both figures mapped to their sources and publication dates, the checks already run, and a recommended next step.
⬜ A structured handoff that lists both figures with source names, labels them contradictory and asks the analyst to choose the more credible source.
⬜ A structured handoff that reports the 2024 figure as current, with its source and date, and marks the 2022 figure as superseded.
⬜ A structured handoff with both figures, sources and dates, plus the complete search and analysis subagent outputs as supporting evidence.

A user asks three independent questions about one company: market position, recent litigation and financial health. The coordinator holds a background profile that all three investigations need. One search subagent currently answers all three, and coverage is shallow. How should the coordinator restructure the work?

⬜ Split the request into three subtasks, include the background profile in each prompt and emit the three Agent tool calls in one response.
⬜ Keep one subagent, give it the background profile and tell it to answer the three questions one after another.
⬜ Spawn three parallel subagents with short prompts naming each question, so they read the profile from the coordinator’s history.
⬜ Run three subagents in sequence, passing each one the profile plus the findings of the subagent that ran before it.

Yesterday an engineer started a Claude Code session named citation-debug to find out why the synthesis subagent drops citations. This morning a short, unrelated session ran in the same directory. No repository files have changed. How should the engineer continue the investigation?

⬜ Start a new session and paste a structured summary of yesterday’s findings as the first message.
⬜ Run claude –resume citation-debug to reopen that named session with its context.
⬜ Run claude –continue to reopen the most recent conversation in the current directory.
⬜ Run claude -p with a prompt asking Claude to continue the citation-debug investigation.

A teammate suggests letting the document analysis subagent send its findings straight to the synthesis subagent to save a turn. You need every finding to pass through the coordinator, with a guarantee that holds on unattended runs. Which two design choices achieve this? (select two)

⬜ Give both subagents a shared findings file that each one reads and writes during the task.
⬜ Add a rule to each subagent’s system prompt that results may be reported only to the coordinator.
⬜ Have the coordinator collect each subagent’s result and place the findings in the synthesis subagent’s prompt.
⬜ List each subagent’s tools explicitly in its AgentDefinition and leave SendMessage out of the list.

A coordinator sends document analysis tasks to the built-in general-purpose subagent instead of the document analysis agent. That agent’s prompt field describes its tasks in detail, but its description field only says “Helps with documents.” What fixes the routing?

⬜ Expand the agent’s prompt field with more explicit examples of the document tasks it handles.
⬜ Rewrite the description field to state which document analysis tasks this agent handles.
⬜ Add the Agent tool to the document analysis agent’s tools list in its AgentDefinition.
⬜ Add few-shot delegation examples to the coordinator’s system prompt that route document tasks to this agent.

A research coordinator receives a request on an emerging topic whose structure is unknown. The team’s fixed subtopic template missed key areas on similar topics before, and the token budget is limited. Which decomposition approach fits?

⬜ Spawn parallel subagents for every plausible subtopic at the start so no angle is missed, then synthesize all the outputs.
⬜ Reuse the fixed subtopic template from past reports and delegate each subtopic to the search and analysis subagents in parallel.
⬜ Delegate one broad research task per subagent and let the synthesis subagent request follow-up research for gaps it finds.
⬜ Run a short scoping pass that maps the topic’s structure, then build a prioritized delegation plan that adapts as findings arrive.

Legal requires that a research system’s web search subagent never sends a request to a list of restricted domains. Prompt instructions failed in testing, and the subagent must keep fetching approved sources. Which design enforces the rule?

⬜ Add the restricted-domain list with explicit refusal instructions to the search subagent’s AgentDefinition system prompt.
⬜ Add a PreToolUse hook matching WebFetch that returns a deny decision when the requested URL is on the restricted list.
⬜ Add a PostToolUse hook matching WebFetch that removes restricted-domain content from the result before the model reads it.
⬜ Add WebFetch to the search subagent’s disallowedTools so it can’t send any outbound web request.

A coordinator’s baseline session holds the full research history, and its final turns contain the consolidated citation list. The team needs two report-strategy branches that both include those final turns, and the baseline must stay unchanged. How should they create the branches?

⬜ Resume the baseline twice with fork_session enabled and resume_session_at set to the message where the last subagent returned.
⬜ Resume the baseline session ID twice with fork_session enabled, so each strategy gets its own new session.
⬜ Open two new sessions and give each a structured summary of the baseline’s conclusions as its first prompt.
⬜ Copy the baseline’s stored transcript to two new session IDs and resume each copy separately.

A research coordinator uses dynamic adaptive decomposition for every request. A weekly competitor briefing must always have the same five sections, but some runs skip one. Open-ended deep-dive requests work well. What should change?

⬜ Convert both workflows to fixed pipelines so every run follows the same reproducible steps.
⬜ Add the five required sections to the coordinator’s system prompt as a checklist to follow when planning the briefing.
⬜ Keep dynamic decomposition for the briefing and add an evaluation loop that detects missing sections and re-delegates.
⬜ Run the briefing as a fixed pipeline with one step per section and keep dynamic decomposition for deep dives.

A research system’s generate_report tool publishes finished reports straight to a client portal. Policy requires verify_citations to pass before any report is published. The system prompt states this order, but logs show the check is sometimes skipped. The pipeline runs unattended overnight with no one to approve actions. Which design guarantees compliance?

⬜ Move the ordering rule to the top of the coordinator’s system prompt and mark it IMPORTANT with numbered steps.
⬜ Add a PreToolUse hook that blocks any generate_report call until verify_citations has returned a passing result.
⬜ Add a PostToolUse hook on generate_report that runs the citation check on the output and reports failures to the coordinator.
⬜ Add a PreToolUse hook on generate_report that returns an ask decision, requiring approval before each publish.

Your coordinator spawns all four extraction subagents for every document and copies the document into each prompt. Plain invoices need only field extraction, but new document types keep arriving, so the specialist combinations can’t be fixed in advance. Which two changes stop the unneeded delegations? (select two)

⬜ Add a routing step that classifies each document into fixed categories, each mapped to a preset list of subagents.
⬜ Tell every subagent to inspect the document when invoked and return ’not applicable’ if its specialty isn’t needed.
⬜ Prompt the coordinator to assess each document first and emit Agent tool calls only for the specialists that apply.
⬜ Write each subagent’s AgentDefinition description to state which document characteristics call for that specialist.

In an extraction system, an extraction agent passes prose summaries of its findings to a report agent that can’t read the original files. Auditors find that values in final reports often lack their source document name and page number. What fixes this?

⬜ Add a prompt instruction telling the extraction agent to always mention sources in its summaries.
⬜ Have the extraction agent emit each value as a structured record with source document name and page number fields.
⬜ Have the report agent reopen each source document and find the page for every value before writing.
⬜ Append a list of all source document names to the end of each summary before the handoff.

A paused named session holds a detailed analysis of several files in an inventory service. Teammates have since merged changes to a few of those files, and the merged code must stay. Which two approaches correctly continue the work? (select two)

⬜ Use file checkpointing to restore the analyzed files to the state the session last saw.
⬜ Start a new session and seed it with a structured summary of the earlier session’s conclusions.
⬜ Use fork_session to branch from the saved context and continue from the fork’s view of those files.
⬜ Resume the session and name the changed files so the agent re-reads them before continuing.

A custom agent loop appends the assistant tool_use message, then a user message with a short status note required for the audit trail, then a second user message with the tool_result blocks. The API rejects the request with a 400 error, and the note must stay in the conversation history. What fixes the request?

⬜ Keep the message order and set is_error to true on each tool_result so Claude treats the turn as a failed tool execution.
⬜ Remove the status-note message so the tool_result message directly follows the assistant message.
⬜ Send the tool_result blocks in the user message right after the assistant message, and put the status note as text after them.
⬜ Combine the note and the tool_result blocks in one user message, with the note’s text block first.

To protect credentials, a team added a PreToolUse hook that denies Read calls on any path under secrets/. When an engineer writes @secrets/db.env in a prompt, the file contents still load. What should the team change?

⬜ Add a CLAUDE.md rule telling Claude never to read files under secrets/.
⬜ Broaden the hook matcher so it also covers Grep and Glob calls on secrets/ paths.
⬜ Add a Read deny permission rule that covers the secrets/ path.
⬜ Add a PostToolUse hook that redacts secret values from Read results before Claude sees them.

For one internal utility, a team calls the Messages API directly and writes its own tool loop for client-side tools that its code runs. Which two loop-control practices are correct? (select two)

⬜ Wait for the final ResultMessage and confirm its subtype is success before reading the result field.
⬜ Treat stop_reason “max_tokens” as a truncated response that needs handling, not as completion.
⬜ Treat stop_reason “pause_turn” as the signal that Claude is waiting for a client tool to run.
⬜ Keep looping while stop_reason is “tool_use”, running the requested tools and returning tool_result blocks.

Engineers ask a developer-productivity agent open-ended questions such as “trace how a legacy config flag flows through the code,” where each tool result decides what to inspect next. A teammate wants a fixed tool order because logs vary between runs. Which control-flow design fits?

⬜ Replace the loop with a fixed pipeline that always runs Glob, then Grep, then Read.
⬜ Write numbered tool-use procedures into the system prompt so every investigation follows the same steps.
⬜ Add a classifier that detects the question type and runs a predetermined tool sequence for it.
⬜ Keep a model-driven loop in which Claude chooses each next tool based on earlier tool results.

Stuck tasks escalate to on-call engineers who can’t see the agent’s session. An intake script parses each handoff for root cause, affected files and a recommended action, but prose handoffs sometimes leave these out. What design fixes this?

⬜ Constrain each escalation message to a JSON schema with required fields using structured outputs.
⬜ Attach the agent’s complete tool-call log and transcript to each escalation.
⬜ Route each prose handoff through a second Claude instance that checks it for completeness.
⬜ Add several few-shot examples of complete handoffs to the escalation section of the system prompt.

A support agent’s policy allows autonomous refunds only within 30 days of delivery. Prompt instructions still let some late refunds through, and refunds post to the payment processor immediately and can’t be reversed. Which design guarantees compliance?

⬜ State the 30-day rule in the process_refund description and make delivery_date a required input field.
⬜ Add few-shot examples showing in-window refunds proceeding and late ones being escalated.
⬜ Add a PostToolUse hook on lookup_order that computes a refund_eligible flag and adds it to the result.
⬜ Add a PreToolUse hook that denies process_refund calls outside the window and redirects to escalate_to_human.

An engineer’s shell profile exports CLAUDE_CODE_SKIP_PROMPT_HISTORY=1. Yesterday’s debugging session was named refund-triage, but today claude –resume refund-triage finds nothing and the picker is empty. How should the engineer make future sessions resumable by name?

⬜ Pass –resume the absolute path of the earlier session’s .jsonl transcript.
⬜ Resume using the earlier session’s full session ID instead of its name.
⬜ Unset CLAUDE_CODE_SKIP_PROMPT_HISTORY so session transcripts are saved to disk.
⬜ Run /rename refund-triage in a fresh session so the name is registered for resume.

A support agent’s PostToolUse hook matches get_customer and lookup_order and converts their mixed timestamps to ISO 8601. Transcripts show Claude still reasons over the raw values, and the tools have no format parameters. What should the hook do?

⬜ Return hookSpecificOutput with updatedToolOutput set to the normalized result.
⬜ Exit with code 2 and write the normalized values to stderr so Claude receives them as feedback.
⬜ Print the normalized values to stdout and exit with code 0 to add them to the context.
⬜ Move the conversion to a PreToolUse hook that returns updatedInput requesting ISO 8601 output.

A support agent gets subagents described only as “Handles billing questions” and “Handles order and return questions.” The coordinator now delegates even simple order-status checks, adding latency, and complex billing disputes usually include an order number too. Which change best stops the unnecessary delegation?

⬜ Include the coordinator’s already-fetched customer and order data in each subagent prompt so spawns finish faster.
⬜ Add a PreToolUse hook that denies subagent spawns whenever the message contains an order number.
⬜ Remove get_customer and lookup_order from the coordinator so all data access goes through subagents.
⬜ Rewrite each subagent’s description to name the complex cases it handles and mark single-lookup requests as out of scope.

A support coordinator verifies the customer, confirms a duplicate charge with lookup_order, then spawns a refund-assessment subagent with “Assess whether this duplicate charge qualifies for a refund.” The subagent replies that no order was given. The design deliberately keeps raw backend output out of each specialist’s context. What should you change?

⬜ Define the subagent as a fork of the coordinator’s session so it inherits the history.
⬜ Have the coordinator restate the order details in its own assistant message just before spawning.
⬜ Include the customer ID, order ID and relevant charge details in the subagent’s prompt.
⬜ Tell the subagent in its AgentDefinition system prompt to call lookup_order before assessing.

A long support session verified the customer and looked up two orders, then pursued a refund approach the team rejected. The team wants a branch that keeps those exact earlier tool results, drops the rejected turns and leaves the original session unchanged. How should they create it?

⬜ Start a new session whose first prompt summarizes the verification and order findings.
⬜ Resume the original session ID and continue from the latest turn with the new approach.
⬜ Resume with fork_session enabled to get a new session ID and a copy of the full history.
⬜ Resume with fork_session enabled and resume_session_at set to the UUID of the last message to keep.

For a doc-lookup utility, a team calls the Messages API directly with the web search server tool. Its loop treats every stop_reason other than “tool_use” as completion. Long research prompts sometimes return “pause_turn”, and users then see unfinished summaries. How should the code handle a “pause_turn” response?

⬜ Treat it as a transient failure and retry the original request with exponential backoff.
⬜ Send the response’s assistant content back in a follow-up request so the server tool loop can continue.
⬜ Resend the request with a larger max_tokens value so the whole answer fits in one response.
⬜ Extract the tool_use block, run the web search in application code and return a tool_result.

A developer-productivity agent maps a legacy module’s conventions over several turns, then spawns a code-generation subagent with “Generate adapters following the conventions identified above.” The subagent ignores them, and conventions differ per module. What should change?

⬜ Resume the subagent with the parent session’s ID so it continues from the earlier context.
⬜ Put the mapped conventions and file paths directly in the delegation prompt sent to the subagent.
⬜ Write the conventions into the shared project CLAUDE.md so subagents load them at startup.
⬜ Move the conventions into the subagent’s AgentDefinition system prompt so they load every time.

An audit finds one refund ran before identity verification. An engineer proposes replacing the support agent loop with a hard-coded decision tree so the order can never be violated. Which two design choices are correct? (select two)

⬜ Replace the agent loop with a classifier that maps each request category to a fixed tool sequence.
⬜ Add a system prompt rule that process_refund must never run before get_customer, repeated every turn.
⬜ Add a programmatic precondition that blocks process_refund until get_customer has returned a verified customer ID.
⬜ Keep model-driven tool selection for investigation, where Claude picks the next tool from context.

One customer message contains three concerns: a duplicate charge on order #4451, a refund whose amount depends on what the duplicate-charge check finds, and an unrelated shipping address change. How should the agent structure the investigation before replying?

⬜ Have the duplicate-charge subagent spawn the refund subagent itself when it finishes.
⬜ Spawn three parallel subagents in one turn, one per concern, each with the customer record.
⬜ Handle all three concerns in sequence inside the main agent without delegating.
⬜ Run the address-change and duplicate-charge subagents in parallel, then assess the refund once the duplicate-charge result is back.

You register a PreToolUse hook with the matcher “process_refund”. Unit tests show its callback denies amounts above $500. The refund tool runs on an MCP server named “support”. In production the hook never fires and large refunds go through. What fixes this?

⬜ Register the hook on PostToolUse instead, because MCP tools trigger only that event.
⬜ Move the limit check into the MCP server, because SDK hooks don’t cover MCP tools.
⬜ Change the matcher to the tool’s full MCP name, mcp__support__process_refund.
⬜ Fix the callback’s comparison so it denies refunds above $500.

A support agent requests get_customer and lookup_order in one turn. lookup_order times out, and one retry also fails. The agent must decide its next step now. How should the loop return the results to Claude?

⬜ Send one user message with the get_customer tool_result plus a lookup_order tool_result marked is_error true with the timeout details.
⬜ Send the get_customer result now and the lookup_order result in a later message after the next response.
⬜ Replace the missing lookup_order result with a plain text block describing the timeout.
⬜ Keep retrying lookup_order with backoff and send both results once the backend recovers.

Engineers resume a named session daily to refine an agent’s MCP tool code. A few files change overnight, teammates forget to mention them, and Claude relies on stale results. What adds the recent changes to context automatically on every resume?

⬜ Start a fresh session each morning with a structured summary of the previous session.
⬜ Add a PostToolUse hook that appends each file’s last-modified time to every tool result.
⬜ Add a SessionStart hook that detects resumes and writes the list of files changed since the last session into context.
⬜ Add a CLAUDE.md instruction telling Claude to re-read every analyzed file at the start of each session.

Internal project codenames must never appear in queries sent to the third-party MCP tool mcp__search__web_search, but the searches must still run. Prompt instructions still leaked codenames in testing. Which two steps enforce this? (select two)

⬜ Register a PostToolUse hook that deletes codenames from the search results.
⬜ In the hook callback, return a deny decision whenever the query contains a codename.
⬜ In the hook callback, read the query from tool_input and return updatedInput with the codename removed.
⬜ Register a PreToolUse hook whose matcher is mcp__search__web_search, the MCP tool naming pattern.

An engineer is two hours into an unnamed session debugging a coordinator’s task decomposition. Short, unrelated sessions run in that directory every day. Tomorrow they want one command that reopens this exact investigation with full context and no session picker. What should they do?

⬜ Plan to run claude –continue tomorrow to reopen the most recent session in the directory.
⬜ Run claude –resume tomorrow without a session and pick the investigation from the list.
⬜ Run /rename with a descriptive name now, then resume it by that name tomorrow.
⬜ Exit and start a fresh session with claude -n to name it, then restart the investigation there.

A research system’s PreToolUse hook exits with code 1 when the web search subagent’s fetch URL is on a licensing blocklist, yet logs show the blocked fetches still run. Research runs unattended overnight. What change enforces the rule?

⬜ Add the blocklist to the subagent’s system prompt with an instruction to refuse those domains.
⬜ Move the blocklist check to a PostToolUse hook that returns a blocking error.
⬜ Have the hook return JSON with permissionDecision “ask” for blocklisted URLs.
⬜ Have the hook exit with code 2 when the URL is on the blocklist.

An earlier research investigation’s conclusions are still trusted, but most sources have since replaced their published figures, so the saved tool results must not re-enter context as evidence. The team starts a new coordinator session instead of resuming. What should its first prompt include?

⬜ The saved tool results, each labeled with its retrieval date and source.
⬜ Only the research topic and its list of subtopics.
⬜ The full search results and document analyses the earlier subagents returned.
⬜ The earlier conclusions and the claim-to-source mappings that support them.

A research coordinator stores each subagent’s result separately but forwards all accumulated outputs to every downstream subagent. Report subagent prompts now reach 90K tokens, and the reports miss the synthesis conclusions. Every handoff must stay auditable in the coordinator’s logs. What should change?

⬜ Have the coordinator pass each subagent only the stored results its task needs.
⬜ Add a summarization subagent that condenses the accumulated outputs before they reach the report subagent.
⬜ Have the synthesis subagent send its output straight to the report subagent, bypassing the coordinator.
⬜ Move the report subagent to a model with a larger context window so everything fits.

A custom code-explorer subagent (not the built-in Explore agent) mapped a legacy module and returned a brief summary with its agentId. A later spawn of the same agent type knows nothing about that work. Which two approaches give the follow-up access to the earlier context? (select two)

⬜ Spawn a fresh explorer from the same AgentDefinition so it keeps the first instance’s state.
⬜ Spawn a fresh explorer and point it at the earlier tool results in the coordinator’s history.
⬜ Ask Claude to resume the earlier explorer subagent by its agentId instead of spawning a new one.
⬜ Spawn the next explorer as a fork so it inherits the coordinator’s conversation history.

A coordinator defines an explorer subagent through the SDK’s agents option with a detailed description, but the coordinator’s own tools list is limited to Read, Grep and Glob. At run time it never delegates and explores everything itself. What enables delegation?

⬜ Rewrite the explorer’s description to match exploration tasks more precisely.
⬜ Move the explorer definition into a .claude/agents/ Markdown file so it’s discovered at startup.
⬜ Set the coordinator’s permissionMode to dontAsk so spawn requests are approved automatically.
⬜ Add the Agent tool (formerly called Task) to the coordinator’s restricted tools list.

A third-party MCP code-search tool returns more than 50 fields per result, and the agent needs only five. The server has no option to limit fields, and long exploration sessions run out of context. What should you implement?

⬜ A PreToolUse hook that returns updatedInput to rewrite each call so it asks for only five fields.
⬜ A trim_result tool that the agent is told to call on each raw result.
⬜ A system prompt instruction telling the agent to ignore all but the five fields.
⬜ A PostToolUse hook that strips the unused fields from each search result before the model processes it.

A developer’s manual agent loop gets a single Grep tool_use block from Claude. The next request’s history holds the original user prompt, then a user message with exactly one tool_result whose tool_use_id copies Claude’s ID, with no text blocks. The API returns a 400 error for an unmatched tool_use_id. What fixes the request?

⬜ Generate a new unique tool_use_id for the tool_result instead of copying Claude’s.
⬜ Return an extra tool_result with is_error true for each tool_use the loop didn’t run.
⬜ Append Claude’s assistant message with its tool_use block to the history before the user message with the result.
⬜ Reorder the results message so every tool_result comes before any text block.

A research coordinator’s delegation prompts give the web search subagent a fixed list of eight queries. On emerging topics, useful search terms only become clear after the first results, and the subagent returns thin findings. How should the delegation prompts change?

⬜ Rewrite the search subagent’s description to say it handles emerging, fast-moving topics.
⬜ Add extra query sets covering more categories of emerging topics in advance.
⬜ State the research goal and quality criteria, such as source count and cross-verification, and let the subagent choose its queries.
⬜ Keep the fixed queries, but have the coordinator re-delegate with a new list when findings are thin.

Yesterday’s named session report-templates designed a citation format and edited three report templates. A teammate reverted the edits, so the exact diff is in git history, while the design reasoning exists only in that conversation. How should the engineer recover both?

⬜ Resume the session and have Claude rebuild the edits from its earlier tool results.
⬜ Start a new session and have Claude recover the decisions and edits from git history.
⬜ Restore the edits with git, then start a new session seeded with a written summary of the design.
⬜ Resume the session with claude –resume report-templates for the design context, and restore the edits through git.

A report-generation stage always runs the same three steps: draft the report, check citations against the findings, then refine. Citation coverage must be confirmed before refinement runs. Which two design choices fit? (select two)

⬜ Reuse the research phase’s dynamic decomposition, letting the model pick each next step.
⬜ Implement the stage as a fixed prompt chain, with one call per step that processes the previous step’s output.
⬜ Add a programmatic gate after the citation check that blocks refinement until every claim maps to a finding.
⬜ Run the three steps as parallel calls and merge their outputs to cut latency.

A team forks a baseline session into two branches to compare report structures. Branch A runs first and its report subagent edits reports/draft.md. When branch B runs, it reads that file and builds on A’s edits instead of the baseline draft. How should the branches be kept independent?

⬜ Fork each branch with resume_session_at set to a message before branch A wrote the draft.
⬜ Turn off session persistence for each branch so one branch’s state isn’t saved for the other.
⬜ Copy the baseline session’s entries to new keys in the session storage backend.
⬜ Run each forked branch in its own working directory with its own copy of the report files.

A policy forbids force pushes to shared branches because rewritten history can’t be reliably restored. A PostToolUse hook with a Bash matcher detects force-push commands and returns a blocking response, but the pushes still reach the remote. Which change enforces the policy?

⬜ Extend the hook to run a compensating git command that restores the branch afterward.
⬜ Register the same check under PreToolUse so it runs before the Bash command executes.
⬜ Add a system prompt rule that the agent must never force-push to shared branches.
⬜ Change the hook’s return value to an explicit deny decision.

Despite a system prompt rule against pushing to main, an agent’s unattended Bash runs pushed to main twice last month. Routine tests, builds and feature-branch pushes must keep running without approval. Which design enforces the rule?

⬜ A PreToolUse hook that inspects each Bash command and denies every git push.
⬜ The rule in CLAUDE.md with IMPORTANT emphasis and examples of allowed and forbidden commands.
⬜ A PostToolUse hook that inspects finished Bash commands and flags any push to main.
⬜ A PreToolUse hook that inspects each Bash command and denies any push to the main branch.

A support agent’s escalation handoffs include the customer ID, an issue summary, the refund amount and a recommended action. Human agents triage each ticket in under two minutes and often re-offer resolutions the customer already declined. Which handoff change fixes this?

⬜ Attach the full session transcript to each ticket.
⬜ Have escalate_to_human attach the latest get_customer and lookup_order results.
⬜ Add an actions-taken section listing each resolution the agent tried and how the customer responded.
⬜ Have human agents start each case by asking the customer what was already tried.

A pilot runs a support agent unattended in bypassPermissions mode so runs never stall on approval prompts. Pilot policy forbids autonomous refunds; every refund must go through escalate_to_human. Which two changes guarantee the agent can never execute process_refund? (select two)

⬜ Put a numbered rule at the top of the system prompt requiring refunds to go through escalate_to_human.
⬜ Remove process_refund from the agent’s allowedTools list.
⬜ Add process_refund to the agent’s disallowedTools configuration.
⬜ Add a permission deny rule that matches the process_refund tool.

An engineer is starting a multi-day investigation into a drop in first-contact resolution, and other short sessions run in that directory every day. They want a scripted command that reopens the investigation directly each morning. Which setup works?

⬜ Start the session with claude -n escalation-spike, then run claude –resume escalation-spike each morning.
⬜ Start a normal session, then use fork_session each morning to branch from the previous day.
⬜ Start a normal session, then run claude –continue each morning.
⬜ Start a normal session, then run claude –resume each morning and pick it from the list.

Policy now requires a supervisor to approve, in real time, any refund above $200 before it runs. Once approved, the refund must still complete in the same session, and smaller refunds should run without interruption. Which hook design meets this?

⬜ A PreToolUse hook on process_refund that denies amounts above $200.
⬜ A PreToolUse hook on process_refund that returns an ask decision for amounts above $200.
⬜ A PreToolUse hook that returns updatedInput capping refunds above $200 at $200.
⬜ A PostToolUse hook on process_refund that sends refunds above $200 to supervisor review.

You add a fraud-check subagent whose description clearly covers chargeback requests, but the coordinator still skips it on about 1 in 10 chargebacks. Every chargeback needs a fraud check before the agent replies. Which change fixes this most reliably?

⬜ Redefine the subagent programmatically through the agents option so it takes precedence over filesystem agents.
⬜ Detect chargeback requests in your application and name the fraud-check subagent explicitly in the coordinator’s prompt.
⬜ Move the fraud-check subagent to the first position in the agents configuration.
⬜ Expand its description with more example phrasings of chargeback and dispute requests.

A billing dispute session was paused yesterday. Overnight, the billing team corrected the order record and applied a partial credit, so the session’s saved tool results are out of date. How should the agent continue the case?

⬜ Start a new session seeded with a structured summary of case facts and decisions, and let the agent re-query the tools.
⬜ Resume the session and tell the agent to call lookup_order and get_customer again before acting.
⬜ Fork the session with fork_session so the continuation runs in a new branch.
⬜ Resume the session by its stored ID so the agent keeps yesterday’s full context.

A support agent runs on short-lived containers. Resuming a saved session ID fails on new containers because session files are local, and summaries injected into fresh sessions lost details. How should the team keep the full conversation across customer returns?

⬜ Resume the saved ID with fork_session so each container works on its own copy.
⬜ Start a fresh session each time with a longer structured summary of facts, decisions and quotes.
⬜ Add a SessionStore that mirrors session transcripts to shared storage, then resume by session ID on any container.
⬜ Set continue_conversation to true so each container picks up the most recent session.

A team adds a PreToolUse hook that returns an allow decision for process_refund calls under $25, but those calls are still blocked. A deny rule matching process_refund remains from an earlier pilot. What should change?

⬜ Run these sessions in bypassPermissions mode.
⬜ Add process_refund to the agent’s allowedTools.
⬜ Move the auto-approval into a PostToolUse hook.
⬜ Remove the deny rule that matches process_refund from the permission settings.

For complex disputes, a support coordinator spawns two parallel subagents, one for billing history and one for order records. Each independently calls get_customer and lookup_order for the same customer, and resolution latency is at its limit. How do you remove the duplication?

⬜ Add a shared state store where each subagent logs fetched data for the other to reuse.
⬜ Run the subagents in sequence, passing the first’s results into the second’s prompt.
⬜ Have the coordinator call get_customer and lookup_order once and include the results in each subagent’s prompt.
⬜ Merge both subagents into one investigation agent.

A complex dispute involves a duplicate charge and a missing replacement order. The coordinator spawns two parallel subagents with vague, overlapping prompts, and both investigate the duplicate charge, nearly doubling token use and producing conflicting findings. Resolution time is already at its limit. What change is most effective?

⬜ Let the subagents report their focus areas to each other while they run.
⬜ Have the coordinator split the dispute into distinct issues before delegating, giving each subagent one issue with explicit scope boundaries.
⬜ Run the subagents in sequence, passing the first one’s findings to the second.
⬜ Keep the prompts and have the coordinator remove duplicate and conflicting findings when merging.

A research system’s web search subagent twice ran shell commands embedded in fetched pages, despite a prompt rule to treat page content as data. The subagent needs only fetch tools. Which change guarantees embedded instructions can’t execute commands?

⬜ Restrict the search subagent’s AgentDefinition tool list to web fetch and read tools, removing Bash and Write.
⬜ Have the coordinator restate the untrusted-content rule in every delegation prompt.
⬜ Add a PostToolUse hook that strips text that looks like instructions from each fetched page.
⬜ Enable strict tool use so every tool call is validated against its schema.

A web search subagent emits register_source and add_citation in one turn. add_citation needs the source ID that register_source returns, and register_source fails because the URL is unreachable. The subagent also runs independent searches in parallel, and you want to keep that. How should the loop handle the pending add_citation call?

⬜ Resend with disable_parallel_tool_use true so the two calls arrive in separate turns.
⬜ Run add_citation with a placeholder source ID to correct later.
⬜ Return the register_source error alone and send no tool_result for add_citation.
⬜ Return a tool_result for add_citation with is_error true and a short note that its prerequisite failed.

An engineer ran several named investigation sessions last week, one per pipeline bug, plus short unrelated sessions since. No files have changed, and they can’t remember the exact name of the session they need. How do they reopen it?

⬜ Run claude –continue to reopen the most recent conversation in the directory.
⬜ Start a new session and paste a summary of the investigation’s key findings.
⬜ Run claude –resume with the closest name they remember.
⬜ Run claude –resume without a session argument and choose the investigation from the interactive picker.

A citation-verification step uses the Messages API Tool Runner with client tools. One run kept repeating fetch_url calls and never finished. The team wants a guaranteed bound on every run and correct completion detection. What should they change?

⬜ Set max_iterations on the runner as a safety cap and treat a run that stops at the cap as incomplete.
⬜ Set max_iterations to the usual number of tool calls and treat stopping at the cap as a normal finish.
⬜ Detect repeated identical tool calls in the harness and abort when that pattern appears.
⬜ Replace the runner with a manual loop that stops when stop_reason is end_turn.

In a research refinement loop, the synthesis subagent checks its own output for coverage gaps and requests follow-up research. Finished reports still miss subtopics, and the agent rates its coverage as complete. Which change fixes the loop?

⬜ Have the synthesis subagent output a per-subtopic coverage rating and trigger research below a threshold.
⬜ Enable extended thinking for the synthesis subagent’s self-review.
⬜ Add a review subagent that scores each finished report and appends the gaps it finds.
⬜ Have the coordinator compare each synthesis output with the subtopic decomposition and re-delegate research for uncovered subtopics.

A support agent’s code gate blocks process_refund until get_customer has verified someone in the session. An audit found a refund posted to an order that had nothing to do with the verified caller. What should the gate check?

⬜ That the order in the refund call belongs to the same customer that get_customer verified.
⬜ That get_customer returned a verified result within ten minutes before the refund call.
⬜ That the order ID came from a lookup_order call made after get_customer in the same session.
⬜ That the caller repeats their full name and email just before the refund is submitted.

Policy lets a support agent post refunds up to $20 on its own; larger ones need a person. The team enforces this with a PreToolUse callback hook on process_refund in the Agent SDK. Which two design choices are best? (select two)

⬜ Deny calls over $20 with a reason telling the agent to route the case through escalate_to_human.
⬜ Let calls over $20 run, and add a PostToolUse hook that flags each one for supervisor review.
⬜ Return updatedInput with the amount reduced to $20 so a partial refund posts without review.
⬜ Read the refund amount from the hook’s tool_input, not from the amount the customer stated earlier.

An analyst asks a research coordinator for ’the latest merger numbers.’ Two mergers she covers are pending, so the coordinator ends its turn asking which one, and the loop records the run as failed. What should happen instead?

⬜ Pick the merger with the most recent regulator filing and state that assumption at the top of the brief.
⬜ Pass the coordinator’s question to the analyst, then send her reply back in the next user message.
⬜ Keep the failed status and send runs that end without a brief to a support queue.
⬜ Pick one merger, draft its brief, and ask in the first line whether it was the right one.

Yesterday, Claude’s Bash tool started a local mock of a carrier API in the background on port 8081. Today the engineer resumes that session by its ID on the same laptop, Claude calls the mock at that address, and every call fails. What should she do?

⬜ Resume with fork_session so the new branch restarts the processes the original session started.
⬜ Use continue instead of resume to reopen the latest session with its earlier processes.
⬜ Restart the mock on its original port, then tell the resumed session it’s running again.
⬜ Restart the mock on the next free port and have Claude retry its earlier calls exactly as before.

An investigation started in Claude Code on one engineer’s laptop. Tonight the on-call team must carry it on from a shared server where the same repository is already cloned. How should the work carry over?

⬜ Run claude –resume on the server with the laptop session’s ID.
⬜ Run claude –continue on the server to pick up the most recent conversation.
⬜ Commit a handoff file, then resume the laptop session by its ID on the server.
⬜ Start a new server session seeded with a structured note of confirmed findings, open questions and next steps.

A CI step’s claude -p run with –output-format json returns a session_id. A later step, in a new process on a shared runner, must ask a follow-up about that review. What should it do?

⬜ Start a new claude -p run and paste the earlier JSON output into its prompt.
⬜ Save session_id from the first step’s output and pass it to –resume in the follow-up run.
⬜ Run the follow-up with –continue to reopen the latest conversation on the runner.
⬜ Run with –continue –fork-session to branch from the latest conversation.

A review coordinator creates one subagent per changed hunk, spawning 300 subagents for a 40-file pull request. An earlier single-pass version missed interactions between related modules. How should the review be divided?

⬜ Group related files or concerns into a few focused passes, then run one integration pass that checks how they interact.
⬜ Keep one subagent per hunk but launch them in batches of twenty.
⬜ Go back to one pass over the whole diff and allow a longer answer.
⬜ Give each module its own subagent and let each one report issues in other modules it touches.

process_refund succeeded, but its confirmation reached the support agent late, and the agent proposed the same refund again. Payments can’t be reversed, and network delays sometimes deliver duplicate requests. Which two controls should run before any further refund call on this order? (select two)

⬜ Look up the refund state by order or transaction ID in the payment system before accepting the call.
⬜ Check the conversation history for an earlier refund confirmation.
⬜ Reject a new refund when the same amount was sent in the last few minutes.
⬜ Reject any new refund for an order or transaction ID that already has a completed refund on record.

Claude Code maintains an extraction mapper. After an edit, the same type error keeps coming back while Claude moves on without running the type check. The team wants each type error reported right after the edit that caused it. Which hook fits best?

⬜ A PreToolUse hook on edit tools that runs the type check before each edit.
⬜ A PostToolUse hook on edit tools that runs the full test suite and logs the results.
⬜ A Stop hook that runs the type check when Claude finishes and blocks completion on errors.
⬜ A PostToolUse hook on edit tools that runs the type check after each edit and returns any failure to Claude.

A third-party MCP tool returns invoices as JSON text with invoice_id, amount in cents and due_date. A PostToolUse hook uses updatedToolOutput so Claude sees amounts in dollars, and Claude later passes each invoice_id to a pay_invoice tool. How should the hook build the replacement?

⬜ Return a short prose summary of the converted totals.
⬜ Return the same JSON structure with every field kept and only the amount values converted.
⬜ Return only the converted amounts, since the other fields are already in context.
⬜ Return the converted JSON alongside the original under a new top-level key.

A research search subagent’s last message reads: “Done. Found 14 relevant sources; details above.” The coordinator then has no sources to pass on, and the brief stalls. What should change?

⬜ Require the final message to contain all findings in full, including each source’s URL, key claim and date.
⬜ Give the coordinator read access to the search subagent’s full transcript.
⬜ Have the coordinator read any files the search subagent saved and rebuild the list.
⬜ Stream the subagent’s intermediate messages to the coordinator while it runs.

A team prefers given/when/then names for generated tests but accepts exceptions when another name reads better. An engineer proposes a PreToolUse hook that blocks any Write whose test names don’t match a pattern. What fits best?

⬜ Put the naming preference and one example test name in CLAUDE.md or the tests rule file.
⬜ Add the hook with an error message showing a correctly named example.
⬜ Add a PostToolUse hook that renames tests to match the pattern after each Write.
⬜ Fail the CI build on any non-matching name and have developers rename tests by hand.

A CI test-writing job runs one long prompt chain for every pull request, covering API, UI, migration and docs changes. Docs-only changes still take nine minutes and get irrelevant test suggestions. What fits best?

⬜ Add a first step listing the changed file types and pass it through the same full chain.
⬜ Run the API, UI, migration and docs chains in parallel on every pull request and merge.
⬜ Skip test writing for pull requests under 20 changed lines.
⬜ Classify each pull request by kind of change first, then run the chain built for that kind.

Each vuln-db advisory is about 8,000 tokens. Policy requires every full advisory to be kept for audit, but reviews need only severity, affected versions and fixed version. What fits best?

⬜ A PreToolUse hook that logs each lookup request, plus a PostToolUse hook that trims results.
⬜ A PostToolUse hook that trims each advisory to three fields; auditors re-query vuln-db for details.
⬜ A PostToolUse hook that appends a three-field summary to each full advisory.
⬜ A PostToolUse hook that saves the full advisory to audit storage, then passes Claude only the three fields.

For a PR touching six endpoints, a test-writing job plans one test file per endpoint. After writing two, it finds the PR also changed shared auth middleware that all six call, which its plan never covered. What should it do next?

⬜ Finish the four remaining files as planned and note the middleware change in the summary.
⬜ Stop and fail the job so a developer can split the pull request.
⬜ Add a seventh test file for the middleware, then finish the remaining four as planned.
⬜ Replan the remaining work around the middleware change and revisit the two test files already written.

Each customs declaration is extracted, validated and submitted, and the customs authority charges a penalty for every amended declaration. A specialist reviews the day’s submissions each evening and often finds errors that passed validation. What should change?

⬜ Move the specialist’s review to just before submission and hold each declaration until it is approved.
⬜ Keep the evening review and add a process for filing corrections early the next day.
⬜ Add a second Claude instance before submission and retire the specialist’s review.
⬜ Add validation rules for the errors found each evening and block declarations that fail them.

Policy lets refunds up to $250 run automatically; anything larger needs a supervisor’s approval for the full amount. A customer asks for $900 for a damaged sofa and suggests four smaller refunds. Today process_refund checks each call against $250 on its own. What should change?

⬜ Move the $250 check into a PreToolUse hook that compares each call’s amount with the limit.
⬜ Track the cumulative amount refunded for the case and send the full $900 for supervisor approval before any payment.
⬜ Issue $250 now automatically and send the remaining $650 for approval afterward.
⬜ Keep the per-call check and reject a second refund on the same order within 24 hours.

A support agent called lookup_order five times in a row with the same order ID; each result said “in transit, next update 18:00,” and the customer added nothing new. What should the application do?

⬜ Have the agent wait until 18:00 before its next lookup, then continue the loop.
⬜ Set max_turns to 5 so the loop ends and the case closes after five calls.
⬜ Cache lookup_order results for an hour so repeated calls are faster.
⬜ Detect repeated identical calls with identical results, then end the loop with an escalation that carries the order status.

Policy requires a carrier claim, filed with file_carrier_claim, before a support agent finishes any damaged-delivery case. The agent sometimes ends its turn without filing one, and the team wants a deterministic check at completion. Which hook fits?

⬜ A PreToolUse hook on escalate_to_human that blocks handoffs until a claim is on file.
⬜ A PostToolUse hook on process_refund that files the claim automatically after each refund.
⬜ A Stop hook that checks for a filed claim and blocks completion with a reason until one exists.
⬜ A SubagentStop hook that checks for a claim when the claims subagent finishes.

Three search subagents each studied one district’s vaccination data for this week’s report, and each returned cited findings. The report leaves out the Eastfield district, including a 12-point drop, although the coordinator’s log shows Eastfield’s result arrived complete with the finding and citation. Which two actions should the team take? (select two)

⬜ Trace the Eastfield result ID from the coordinator through the synthesis-input records to find the exact handoff that failed.
⬜ Rerun the Eastfield search with broader terms and replace its result before regenerating.
⬜ Require synthesis to confirm one outcome record per assigned district before drafting: cited findings or a documented failure.
⬜ Raise synthesis’s token budget and regenerate, assuming the late findings were truncated.

A research coordinator loops: search for more sources, then ask a reviewer whether the report is complete. The reviewer keeps finding new gaps, and last week the loop ran nine rounds and missed the deadline. Which two changes fix this? (select two)

⬜ Define exit criteria in advance, such as two sources for each key question, and stop once they’re met.
⬜ Cap the loop at three rounds and escalate any remaining gaps to a human analyst with a summary of what was tried.
⬜ Let the reviewer decide when the report is complete, with a stricter definition of complete.
⬜ Allow new gaps each round, but require each gap to cite a missing source.

An analyst resumes Tuesday’s session. The brief’s admissions total and its admissions per 1,000 residents both come from the county admissions file; ambulance response times come from a separate dispatch file. Only the admissions file has been corrected since. What is the most targeted instruction?

⬜ Name the admissions file, have the agent re-read it and update the total, keeping the other findings.
⬜ Name the admissions file, have the agent re-read it and recheck both the total and the per-1,000 rate.
⬜ Name the file, have the agent re-read it and recheck every figure in the summary table.
⬜ Paste the corrected count into the prompt and have the agent substitute it in the total and the rate.

For each report, a coordinator pastes the full text of a 300-page health survey into the prompts of five analysis subagents. Their context fills early and costs have tripled. Which two changes fix this? (select two)

⬜ Summarize the whole survey in the coordinator and paste the summary into each subagent prompt.
⬜ Give each subagent the file path and the page range it covers, and let it read those pages with Read.
⬜ Store the extracted text once and pass a document ID that each subagent uses to fetch only the sections it needs.
⬜ Remove line breaks and tables from the text before pasting it into each prompt.

Council analysts use a research agent through a web app built on the TypeScript Agent SDK. When Claude calls AskUserQuestion, the canUseTool callback shows the questions as buttons. After the analyst clicks, it returns allow with the original input, and Claude carries on as if nothing was answered. What should the callback return?

⬜ Allow with updatedInput holding an answers array of the chosen labels in question order.
⬜ Allow with updatedInput whose options are trimmed to the chosen label.
⬜ Allow with updatedInput holding the original questions plus an answers object keyed by question text.
⬜ Allow with no updatedInput, after storing the selections on the session.

Two new rules apply to a research document subagent: it must never call delete_document, and it may call fetch_url only for domains on an allowlist that the legal team updates in a database several times a day. Which setup fits both rules?

⬜ State both rules in the system prompt and log every call for a weekly review.
⬜ Add a PreToolUse hook for delete_document and a static list of today’s allowed domains.
⬜ Add permission deny rules for delete_document and for every domain not currently on the allowlist.
⬜ Add a permission deny rule for delete_document, and a PreToolUse hook that checks each fetch_url domain against the database.

About 40% of requests to a research system are single-fact questions, such as a regulation’s effective date, answerable from one source. Each still goes through the coordinator and four subagents, taking three minutes and many more tokens than a direct lookup. Answers are accurate. What should the team do?

⬜ Route single-fact questions to one agent with search and citation tools, and keep the full pipeline for research reports.
⬜ Run the four subagents in parallel for single-fact questions so answers arrive sooner.
⬜ Replace the four subagents with one larger subagent for every request type.
⬜ Send single-fact questions straight to the search subagent, skipping the coordinator but keeping synthesis and reporting.

A research report requested on data-privacy rules in the EU, the US and Japan covers only the EU and the US. Japan isn’t mentioned anywhere, not even as a coverage gap. What should the team inspect first?

⬜ The coordinator’s delegation log, to see whether any task asked a subagent to cover Japan.
⬜ The search subagent’s queries, to see whether any used Japanese terms or sources.
⬜ The synthesis subagent’s inputs and outputs, to see whether Japan findings were dropped.
⬜ The report subagent’s settings, to see whether a length limit cut off a Japan section.

An analyst forks her research session twice to draft two report versions. Later, in the original session, she says one dataset was revised and gives the new figures. Both drafts still use the old figures. What should she do?

⬜ Send the revised figures to each forked session directly, because a fork shares history only up to the moment it was created.
⬜ Resume each fork with –continue to pull in messages added to the original later.
⬜ Wait for automatic compaction to merge newer parent messages into each fork.
⬜ Fork the original twice again and throw away both drafts.

Each pull request summary must follow nine house rules, such as a 120-word limit, a Risks section and a linked ticket. Summaries read well but each breaks one or two rules, and different ones each time. What should the job do?

⬜ Generate the summary first, then run a second step that checks it against all nine rules and corrects any violations.
⬜ Move the nine rules to the end of the prompt, after the diff.
⬜ Reject any violating summary and regenerate it from scratch with the same prompt until one passes.
⬜ Split the rules across nine prompts, each generating its own version.

A hook blocks change_plan until get_customer has verified the caller’s account PIN. When it blocks, the support agent sees only “Denied,” then retries change_plan or tells the customer the system is down. What should the hook return when it blocks?

⬜ A reason saying the request was denied by policy, with no detail.
⬜ Nothing different; add a system prompt instruction to escalate on any denial.
⬜ A reason saying the caller must be verified first, without naming the verification tool.
⬜ A reason saying the account PIN is unverified and that get_customer must verify it before change_plan can run.

An engineer asks Claude Code to update a booking API, its client SDK, the developer docs and the mobile app for a new cancellation rule. Claude delegates three subagent tasks and reports the work done, but the mobile app was never touched. Which two steps prevent this? (select two)

⬜ Before delegating, have Claude list the request’s required parts and check that each one is covered by a task.
⬜ Give each subagent the full original request so it can pick up any part nobody else covers.
⬜ Have each subagent report the files it changed and have Claude summarize them.
⬜ After the subagents return, have Claude check the combined results against every part of the original request.

A documentation workflow always runs four fixed steps on each module: read it, write an API reference, write a tutorial and write a migration guide. For internal helper modules, the tutorial and migration guide come out as filler that reviewers delete. Which two changes fit? (select two)

⬜ Let Claude decide which documentation pieces each module needs after reading it, and produce only those.
⬜ Keep a fixed first step that inventories the module’s public API, and base the later steps on what it finds.
⬜ Keep all four steps and have Claude write “not applicable” when a section doesn’t fit.
⬜ Split the chain into four skills and run all four on every module in parallel.

An engineer uses one Claude Code session all day: a booking bug in the morning, CSS fixes after lunch, then a reporting query. By evening, answers borrow assumptions from the booking bug, such as its test fixtures. Which two habits fit? (select two)

⬜ Run /compact before each new task so earlier work is condensed but carried forward.
⬜ Run /clear before starting an unrelated task so it begins with an empty context.
⬜ Start a new session for each unrelated task and resume an older one later only if needed.
⬜ Keep one session and state at the top of each prompt which task it belongs to.

Before a test-generation job finishes, two checks must run: every generated test must pass the test runner, and each test must check a stated requirement rather than restate the current code. Which setup fits?

⬜ A command hook that runs the test runner, and a prompt-based hook in which a model judges whether the tests match the stated requirements.
⬜ A command hook for both checks, with a script that searches test names for keywords from the requirements.
⬜ A prompt-based hook for both, asking a model to predict whether the tests would pass.
⬜ Instructions in CLAUDE.md asking Claude to confirm both checks in its final message.

A review coordinator spends 30 turns weighing findings, rejecting some and recording why. It then starts a new subagent to write the final summary comment, and the summary lists rejected findings as open. The summary depends on nearly all of that discussion. How should the summary step start?

⬜ As a fresh subagent told to “summarize the decisions we made,” with the PR number.
⬜ As a fresh subagent given only the diff, so it reconstructs the decisions independently.
⬜ As a fresh subagent with read access to the coordinator’s transcript file.
⬜ By resuming the coordinator’s session with fork_session, so the summary starts with the full discussion, including every rejection and its reason.

An extraction loop treats any stop_reason other than tool_use as a finished answer. Some saved records are truncated JSON, and a few contain refusal text instead of data. What should the loop do?

⬜ Treat end_turn and max_tokens the same but validate JSON before saving.
⬜ Retry any non-tool_use response three times and save the last result.
⬜ Retry max_tokens with a higher limit and save refusals and end_turn responses as records.
⬜ Handle each stop_reason separately: retry max_tokens with a higher limit, send refusals to review and save only end_turn results.

An extractor handles 40-page contracts. On one contract, 38 fields are clear but two clauses need a lawyer’s judgment, and the current workflow sends the whole contract to legal review and extracts nothing. What should happen?

⬜ Extract the 38 fields, publish the record as complete, and send the two clauses to legal separately.
⬜ Extract the 38 clear fields and send only the two clauses to legal review, marking the record pending on those two fields until a lawyer decides.
⬜ Extract all 40 fields, using Claude’s best reading of the two clauses with a low-confidence flag.
⬜ Extract the 38 fields, leave the two clauses null and let downstream users request review.

A team’s hand-written Messages API loop now has custom code for tool execution, validation hooks before each tool call, retries and resuming interrupted sessions, and maintaining it takes a day a week. What should the team consider?

⬜ Moving to the Claude Agent SDK, whose managed agent loop includes these features.
⬜ Adopting the SDK Tool Runner, which automates the tool-call loop.
⬜ Keeping the loop and adding prompt caching to cut its cost.
⬜ Moving to Claude Code hooks, which add checks before tool calls.

A pipeline chooses an extraction tool with a hand-written decision tree that checks keywords, such as “Invoice” in the first line. It now has 40 branches, and documents with unusual layouts still go to the wrong tool. What should the team do?

⬜ Give Claude the extraction tools with clear descriptions and let it choose one after reading each document.
⬜ Add branches for each unusual layout found in production and review the tree monthly.
⬜ Replace the tree with a trained classifier, which first needs about 10,000 labeled documents.
⬜ Send every document to every tool and keep the first output that passes validation.

---

Domain 2: Tool Design and MCP Integration (18%)

A research system’s synthesis subagent must report every finding by calling one of three tools: record_statistic, record_quote or record_narrative, each with its own schema. On a model that supports forced tool use, some runs return plain text instead of a tool call and the coordinator’s parser fails. What is the correct fix?

⬜ Keep tool_choice as “auto” and add a system prompt rule that every finding must be reported through a tool.
⬜ Set tool_choice to {“type”: “tool”, “name”: “record_narrative”} on the subagent’s requests.
⬜ Set tool_choice to {“type”: “any”} on the synthesis subagent’s requests.
⬜ Add strict: true to all three recording tool definitions so their inputs follow each schema.

A research system’s document analysis subagent spends its first few tool calls finding out which research collections exist and which fields each one has. The collections change daily. Which two changes give the subagent this information without spending tool calls on discovery? (select two)

⬜ Write the current list of collections and their fields into each subagent’s system prompt.
⬜ Expose the collection inventory as an MCP resource that lists every collection and its fields.
⬜ Define a resource template such as docs://collections/{id}/schema for each collection’s field details.
⬜ Add a describe_collections tool that returns the current inventory of collections and their fields.

A research system’s document analysis subagent must run extract_metadata before any enrichment tool. After the metadata result comes back, it may call enrichment tools or finish with a text answer. On a model that supports forced tool use, which two tool_choice settings implement this? (select two)

⬜ Switch tool_choice to {“type”: “none”} on follow-up requests once the metadata result is returned.
⬜ Set tool_choice to {“type”: “tool”, “name”: “extract_metadata”} on the first request.
⬜ Switch tool_choice to {“type”: “auto”} on follow-up requests once the metadata result is returned.
⬜ Set tool_choice to {“type”: “any”} on every request in the pipeline.

A research system’s web search tool fails for three reasons: rate limits, queries over the length limit and paywalled sources. Every failure returns is_error: true with only “search failed”. The subagent retries paywalled sources and gives up on rate-limited queries. What fixes its recovery decisions?

⬜ Return a different error message for each cause, saying what failed and what to try next.
⬜ Intercept error tool results in the Tool Runner and retry them there before the model sees them.
⬜ Have the coordinator retry every failed search twice with exponential backoff before logging a coverage gap.
⬜ Add a system prompt rule listing which search failure causes can be retried and which can’t.

The synthesis subagent must collect every findings file. File names start with findings- and end in .md or .json. The files sit at any depth under work/, contents vary, and there are fewer than 40. Which two approaches find all of them? (select two)

⬜ Call Glob once with the pattern work//findings-.{md,json}.
⬜ Call Glob once with the pattern work//findings-*.{md,json}.
⬜ Call Grep across work/ with the pattern findings- and collect the files that match.
⬜ Call Glob twice, once with work//findings-.md and once with work/**/findings-.json.

A synthesis subagent calls verify_claim on almost every turn, even for claims that already cite a source. The tool description is detailed and has clear boundaries. The system prompt says: “CRITICAL: You MUST use verify_claim.” What fixes the over-triggering?

⬜ Add stronger boundary language to the verify_claim description, stating when the tool should not be used.
⬜ Set tool_choice to auto for the synthesis subagent so the model decides whether each turn needs a tool.
⬜ Rewrite the system prompt instruction as targeted criteria, such as “Use verify_claim when a claim lacks a source.”
⬜ Remove verify_claim from the synthesis subagent and route all verification through the coordinator.

Each research subagent’s tools are scoped to its role. Now the synthesis agent often needs to confirm a single fact (a date, a figure) that is missing from its handed-off findings, and each check costs a full round trip through the coordinator to the search agent. What is the recommended change?

⬜ Give the synthesis agent a constrained verify_fact lookup tool and keep complex research with the coordinator.
⬜ Pass the search agent’s full raw results, not summaries, in the context at delegation.
⬜ Have the coordinator spawn several search subagents in parallel to run the checks as one batch.
⬜ Give the synthesis agent the full web search toolset so it can fill gaps itself.

A research system needs two new integrations: standard Jira task tracking, and the team’s internal archive of past reports, which has a proprietary API that no public MCP server supports. Which two integration decisions are correct? (select two)

⬜ Document the archive’s API endpoints in CLAUDE.md and have agents call them with Bash.
⬜ Build a custom MCP server that wraps the internal archive’s proprietary API.
⬜ Build a custom Jira MCP server whose tools encode the team’s ticket-filing conventions.
⬜ Connect Jira through an existing community MCP server.

A security scan finds a live GitHub token in the committed .mcp.json. The server is a local stdio server started with npx that reads the token from its env entry. The team rotates the token, and configuration changes must still reach developers through version control. What is the correct fix?

⬜ Change the entry to ${GITHUB_TOKEN:-} so developers who haven’t set the variable still connect.
⬜ Configure a headersHelper script that outputs the token as a dynamic header, so no credential sits in the file.
⬜ Replace the token with a ${GITHUB_TOKEN} reference in the server’s env entry and have developers set the variable locally.
⬜ Add an Authorization header of Bearer ${GITHUB_TOKEN} under the server’s headers field and remove the env entry.

A pull request changes parseAmount in src/utils/money.ts, and src/utils/index.ts re-exports it as toCents. The review currently greps only for parseAmount and misses call sites. Which two steps find every affected caller? (select two)

⬜ Read src/utils/index.ts to list every name the function is exported under.
⬜ Grep for the import path utils/money to find every file that imports the module.
⬜ Grep file contents for each exported name, including the toCents alias.
⬜ Glob for a pattern like **/parseAmount to find files that reference the function.

An agent harness sends its first request with tool_choice {“type”: “tool”, “name”: “get_code_conventions”} (on a model that supports forced tool use) so generated code follows team conventions. The response ends with stop_reason “tool_use”, and no conventions data appears anywhere. What must the harness do next?

⬜ Return the tool_result in the next request but keep tool_choice forced to get_code_conventions.
⬜ Run get_code_conventions, append a tool_result with the tool call’s ID and send the updated history in a new request.
⬜ Turn the tool’s output into a plain user text message and append that to the history.
⬜ Do nothing more; the API runs the forced tool and returns its output in the same response.

A developer-productivity agent’s find_known_issues MCP tool returns an empty list both on a database timeout and on a real no-match. Maintenance windows take the database offline for minutes, so the agent reports modules as issue-free. The harness marks a call as failed only when the tool result itself signals failure. How should the tool report timeouts?

⬜ Add a status field set to timeout or no_matches inside the normal result body for the agent to check.
⬜ Return timeouts with isError: true and a descriptive message, and keep the empty list for genuine no-matches.
⬜ Log each timeout to the server’s monitoring dashboard and alert the database maintainers.
⬜ Retry the query inside the server with exponential backoff and respond only after a retry succeeds.

A documentation MCP server’s catalog gains and loses resource entries many times a day, but each document’s content rarely changes after publication. Long agent sessions keep trying to read URIs that no longer exist. Which server change fixes this?

⬜ Return an empty contents array from resources/read for removed URIs so the agent can detect the gap.
⬜ Advertise the resources.listChanged capability and send notifications/resources/list_changed when entries are added or removed.
⬜ Advertise resources.subscribe so the client receives notifications/resources/updated for resources it follows.
⬜ Add a system prompt rule telling the agent to call resources/list again before every resources/read.

A developer is testing an unstable, daily-changing MCP server for semantic code search. The team shares three MCP servers through a version-controlled .mcp.json, and teammates must not get the experimental one. Where should it be configured?

⬜ In .mcp.json, with .mcp.json added to the repository’s .gitignore.
⬜ In .mcp.json, loading its token through ${SEARCH_TOKEN} environment variable expansion.
⬜ As launch commands and arguments in the developer’s uncommitted local CLAUDE.md.
⬜ In the developer’s ~/.claude.json, at user or local scope.

A developer-productivity agent’s UI must show a short text explanation beside each suggest_refactor call. Since the team set tool_choice to {“type”: “any”}, responses contain tool_use blocks but no text, despite prompt instructions. What restores the explanations?

⬜ Change tool_choice to {“type”: “tool”, “name”: “suggest_refactor”} and keep the instruction in the prompt.
⬜ Add disable_parallel_tool_use: true to limit each response to one tool call.
⬜ Keep tool_choice “any” and add a stronger system prompt rule requiring text before the call.
⬜ Set tool_choice to {“type”: “auto”} and tell the model in the prompt to always call suggest_refactor.

After resolving a case, a support agent must change ‘status: open’ to ‘status: resolved’ in that case’s entry in its notes file. It knows the entry only by its position. Edit fails because the anchor text appears in every templated entry, and a longer anchor with neighboring lines still matches several entries because they are identical. What should the agent do next?

⬜ Use Read to load the full file, then Write the complete content with that one entry updated.
⬜ Keep the same old_string and rerun Edit with replace_all set to true.
⬜ Extend old_string again until it spans enough of the file to match only once.
⬜ Use Bash to run a sed command that replaces the status line at the entry’s position.

A support agent gets four backend tools from one MCP server. You add an investigation subagent that should use only get_customer and lookup_order, and process_refund must not be available to it at all. Which configuration achieves this?

⬜ In the subagent’s configuration, set allowedTools to auto-approve only the two lookup tools by their full MCP names.
⬜ In the subagent’s definition, set the tools field to list only get_customer and lookup_order.
⬜ Add a permissions.deny rule that blocks the process_refund MCP tool by its full name.
⬜ Define the backend MCP server inline in the subagent’s frontmatter instead of in .mcp.json.

In failing support transcripts, the agent calls lookup_order for order details, then calls process_refund just to check eligibility, issuing unwanted refunds. The refund inputs are well formed, and both tools have one-line descriptions. What is the highest-leverage fix?

⬜ Add a PreToolUse hook that denies process_refund until lookup_order has returned in the session.
⬜ Add routing rules to the system prompt mapping each request type to the right backend tool.
⬜ Add input_examples to process_refund showing correctly formatted refund calls.
⬜ Rewrite the process_refund description to say it executes a refund and that eligibility checks belong to lookup_order.

A support agent’s tools are split across two MCP servers: crm (get_customer, lookup_order) and billing (process_refund, escalate_to_human). Each team deploys its own server, and neither will maintain shared middleware. One refund conversation needs live calls to both. How should tool access be configured?

⬜ Build one aggregator MCP server that re-exposes both teams’ tools behind a single connection.
⬜ Register only the billing server and put current customer and order data in the system prompt.
⬜ Register both servers in the agent’s configuration; tools from both are available at the same time.
⬜ Register the billing server and add mcp__crm__* to allowedTools so the agent can call the crm tools.

A find_owner MCP tool returns isError: true with “no owner found” in two cases: when the registry times out during its nightly 30-second rebuild, and when a file really has no registered owner. The agent retries ownerless files and gives up during rebuilds, and the harness stops any tool call after 10 seconds. Which two response changes fix the agent’s recovery? (select two)

⬜ For a registry timeout, keep isError: true and include errorCategory “transient” and isRetryable: true in the error content.
⬜ For a file with no registered owner, return a successful result with an empty owner field.
⬜ For a file with no registered owner, return isError: true with errorCategory “validation” and a note to re-check the path.
⬜ For a registry timeout, retry inside the tool with backoff until the rebuild finishes, then return the owner.

An engineer asks the agent to list every call to the legacy helper cache.flushAll() in the repository. The review needs each matching line with its line number. Which Grep call is correct?

⬜ Pattern cache.flushAll( with output_mode set to content.
⬜ Pattern cache.flushAll( with output_mode set to content.
⬜ Pattern cache.flushAll( with output_mode set to count.
⬜ Pattern cache.flushAll( with output_mode left at its default.

A support agent gets a new track_shipment tool described as “Gets order and delivery information”, while lookup_order is described as “Retrieves order information.” Delivery questions still go to lookup_order even after a routing rule was added to the system prompt. What fixes the misrouting most directly?

⬜ Expand the routing rule with few-shot examples of the right tool for each request type.
⬜ Add input_examples to both tools with typical order and tracking identifiers.
⬜ Classify messages for delivery keywords and force track_shipment with tool_choice for those.
⬜ Rewrite each tool’s description to state what it returns, when to use it and when the other tool applies.

To investigate billing disputes, a team gave its support agent a generic run_query tool that runs any SQL string. Some queries return rows belonging to other customers, even though they touch only billing tables. What is the correct redesign?

⬜ Have the harness scan run_query results and remove rows whose customer_id doesn’t match.
⬜ Replace run_query with a get_billing_history tool that takes a verified customer_id and a date range.
⬜ Add a PreToolUse hook that blocks run_query calls referencing tables outside the billing schema.
⬜ Expand the run_query description with a rule that every query must filter on the current customer ID.

Reports attach wrong source URLs only to citations that come through the document-ingestion path. Tests show the shared citation formatter renders correctly when given correct URL metadata. An earlier attempt used Read on dozens of files and ran out of context. Which exploration strategy is correct?

⬜ Grep for the document-ingestion citation symbols to find entry points, then Read those files and follow their imports.
⬜ Read the pipeline’s main entry file in full and trace the flow from that one file.
⬜ Read the citation formatter’s source in full and fix its URL handling before exploring ingestion.
⬜ Glob for all pipeline source files, then Read each file returned.

A research system’s load_document tool rejects any source not on the approved citation list, with no exceptions, and subagents can’t read the list. MCP tools report failures with isError: true and a JSON body following your team’s schema: errorCategory, retriable and message. The tool currently returns only “Request denied.” The subagent retries the same URL repeatedly, then reports an outage. Which error body fixes both behaviors?

⬜ errorCategory “business” and retriable false, with a message saying the source isn’t on the approved list.
⬜ A successful result with an empty document body and a note that the source was skipped.
⬜ errorCategory “validation” and retriable true, suggesting a retry with a different URL from the approved list.
⬜ errorCategory “permission” and retriable false, telling the agent to escalate to a human reviewer.

A research system’s report subagent must correct one citation line in a draft. Edit fails because the identical line appears in five places and only one should change. Which two recovery approaches are valid? (select two)

⬜ Call Write with only the corrected line and let Write merge it into the existing file.
⬜ Retry Edit with a longer anchor that includes surrounding lines, so the match becomes unique.
⬜ Use Read to load the whole file, then Write the complete corrected content back.
⬜ Run Edit with the replace-all option so every match is updated at once.

An agent must update a retry limit that appears exactly once in config.ts. It must also regenerate scaffold.ts from a template, and some repositories don’t have scaffold.ts yet. Which two tool choices match each tool’s documented purpose? (select two)

⬜ Use Edit on config.ts, matching the single line that sets the retry limit.
⬜ Use Write on config.ts, passing only the updated retry-limit line as the file content.
⬜ Use Write on scaffold.ts, passing the complete generated file content.
⬜ Use Edit on scaffold.ts, matching its full current content and replacing it with the generated version.

A research subagent reads the resource URI of a deleted document. The server returns a success result with an empty contents array, so the synthesis agent cites the document as empty. How should the server respond instead?

⬜ Return the read result with isError set and an errorCategory of business.
⬜ Return a JSON-RPC Invalid Params error (-32602) saying the resource doesn’t exist.
⬜ Advertise resources.subscribe so clients get notifications/resources/updated when a document is deleted.
⬜ Return one text content item that says the document wasn’t found.

A team builds an MCP server for its shared citation database. Every contributor to this repository needs it, and it must not load in contributors’ unrelated projects. How should it be registered?

⬜ With local scope, so the configuration stays tied to this checkout.
⬜ In .mcp.json, keeping the file out of version control and documenting setup in the README.
⬜ At user scope in each contributor’s ~/.claude.json, following README steps.
⬜ With project scope, committing the resulting .mcp.json at the repository root.

A search subagent gets find_content from the archive MCP server and search_content from the web server. Both descriptions already state clear boundaries, but archive queries still often go to the web tool. What reduces the misrouting most directly?

⬜ Force the archive tool with tool_choice naming find_content.
⬜ Add few-shot routing examples to the subagent’s system prompt.
⬜ Rename the tools with source prefixes, such as archive_find_documents and web_search_pages.
⬜ Add a select_search_tool routing tool that the subagent calls first.

A synthesis agent’s scoped verify_fact tool handles frequent single-fact checks well. But when two sources disagree on a statistic, it makes long chains of verify_fact calls and still resolves the conflict wrongly. What is the correct design change?

⬜ Remove verify_fact and route every verification through the coordinator.
⬜ Have the synthesis agent return conflicts to the coordinator, which delegates the investigation to the web search agent.
⬜ Raise the synthesis agent’s tool-call budget so longer chains can finish.
⬜ Give the synthesis agent the web search agent’s full toolset.

A document analysis subagent runs Glob with the pattern **/*.md to list every analysis note and gets 100 results plus a truncation flag. The notes/ folder holds about 400 notes in topic subfolders of fewer than 100 files each. What is the recommended way to get the complete list?

⬜ Run find through Bash across notes/ and parse its output.
⬜ Repeat the same Glob call until older files appear in a later result.
⬜ Use one Glob call with notes//*.md, excluding files outside notes/.
⬜ Call Glob once per topic subfolder, for example notes/economics//*.md, and merge the results.

An engineer’s personal jira MCP server is user-scoped in ~/.claude.json and has the same name as the team’s jira entry in .mcp.json, so Claude Code connects only to the team version. Without editing the shared .mcp.json, which two changes make the personal build connect? (select two)

⬜ Delete the jira entry from the project’s .mcp.json so the user-scoped definition is used.
⬜ Re-add the personal build in that repository with claude mcp add at the default local scope.
⬜ Move the personal definition from ~/.claude.json into ~/.claude/settings.json to raise its precedence.
⬜ Rename the user-scoped server in ~/.claude.json to a name no project uses, such as jira-dev.

A test-runner subagent uses Bash for test suites, linters and build scripts, and company policy says it must never run git push. Which configuration enforces this while keeping every other command working?

⬜ Replace Bash with a custom run_tests MCP tool that runs only the test suite.
⬜ Add a disallowedTools entry of Bash(git push *) to the subagent’s definition.
⬜ Add a Bash deny rule matching the git push pattern to permissions.deny.
⬜ List each approved Bash command pattern in the subagent’s allowedTools field.

A project’s checked-in .mcp.json defines an HTTP code-index MCP server. Most engineers need the production URL (https://code-index.internal/mcp) with no setup, but a few run a local instance on a custom port. How should the url field be set?

⬜ ${CODE_INDEX_URL:-https://code-index.internal/mcp}, with local-instance engineers exporting CODE_INDEX_URL.
⬜ The production URL, with local-instance engineers defining the same server name in ~/.claude.json.
⬜ ${CODE_INDEX_URL} without a default, with the production URL documented in the README.
⬜ The production URL committed, with local-instance engineers editing their copy of .mcp.json without committing.

A support agent’s backend MCP server is remote over HTTP and needs a bearer token. Every engineer must get the server configuration through version control, and the secret must never be committed. Which two configuration decisions are correct? (select two)

⬜ Reference the token in the server’s headers, for example Authorization: Bearer ${SUPPORT_API_TOKEN}.
⬜ Declare the server entry with “type”: “http” together with its url.
⬜ Define the server in each engineer’s ~/.claude.json with the token referenced there.
⬜ Reference the token in headers as Authorization: Bearer ${ANTHROPIC_AUTH_TOKEN}.

get_customer runs successfully against the authoritative customer database and finds no match for the well-formed email a customer gave. The agent retries the same call three times, then tells the customer the system is unavailable. Support policy allows one clarifying question before escalating. What behavior should you design?

⬜ Ask the customer for another identifier, such as an order number, and run a new lookup with it.
⬜ Call escalate_to_human with a handoff saying the customer’s identity couldn’t be verified.
⬜ Have get_customer return zero matches as isError true with errorCategory validation.
⬜ Add exponential backoff and a higher retry cap before the agent gives up.

You plan to expose 40 refund and return policies through a support MCP server. The agent must see which policies exist without exploratory calls, and an engineer warns this will load every policy’s full text into context. Which design resolves the concern?

⬜ Advertise resources.listChanged so the server sends updated policy text into context when a policy changes.
⬜ Expose each policy as its own MCP resource; the agent reads one with resources/read only when a case needs it.
⬜ Expose a search_policies tool whose description covers each policy area and returns matching text.
⬜ Combine all 40 policies into one resource that the agent reads in full at the start of each session.

An agent must list every case transcript file. Glob with **/*.json from the project root matched thousands of dependency files and was truncated. Transcripts live in data/transcripts/; completed ones contain a case_id field, but new cases start as empty placeholder files. What is the fix?

⬜ Use Read on the data/transcripts/ directory to get a listing.
⬜ Switch to Grep and search contents for case_id, collecting the matching paths.
⬜ Keep the **/.json pattern and set Glob’s path parameter to data/transcripts/.
⬜ Run find data/transcripts -name ‘.json’ through Bash and parse the output.

A team is renaming lookup_order across an agent’s codebase. Before editing, it needs a count of references per source file, without adding hundreds of matching lines to context. Which approach is correct?

⬜ Grep with the default output mode and count the file paths returned.
⬜ Grep for lookup_order with output_mode set to count.
⬜ Grep with output_mode content and have the agent tally lines per file.
⬜ Glob with the pattern lookup_order to get per-file counts.

A shared backend MCP server gives a support agent nine engineering tools, including run_sql_query. The agent answers some order questions with raw SQL rows instead of calling lookup_order, even after boundary language was added to the engineering tools’ descriptions. What should change?

⬜ Add a system prompt rule naming the four support tools as the only approved tools.
⬜ Rewrite run_sql_query’s description with example inputs and when-not-to-use guidance.
⬜ Restrict the agent’s allowed tools to the four support tools its role needs.
⬜ Force lookup_order with tool_choice whenever a message mentions an order.

A server’s resources/list entries carry only a URI and names like doc-0481, so subagents read many irrelevant resources to find the right ones. Which two catalog changes let them choose correctly from the listing alone? (select two)

⬜ Add a preview_resource tool that returns the first lines of any URI.
⬜ Add icons to each entry and ttlMs cache metadata to the list response.
⬜ Add a description field to each resource entry saying what data it contains.
⬜ Fill in the title, mimeType and size fields on each resource entry.

The first request forced extract_sources, and its result is back. The model must call verify_citations next, before any other tool or report text, and after verification later turns must be free to use the remaining tools. On a model that supports forced tool use, which two configurations guarantee verify_citations runs next without blocking later steps? (select two)

⬜ Send only verify_citations in the second request’s tools array, with tool_choice “auto”.
⬜ Set tool_choice to {“type”: “tool”, “name”: “verify_citations”} and keep it on every later request.
⬜ Set tool_choice to {“type”: “tool”, “name”: “verify_citations”} on the second request only.
⬜ Send only verify_citations in the second request’s tools array, with tool_choice {“type”: “any”}.

A support agent’s lookup_order fails in three ways: ‘service busy’, ‘order not found’ and ‘permission denied’. Today the agent escalates every failure, and escalations have tripled. How should it handle the three errors?

⬜ Retry busy and not-found errors with exponential backoff, and escalate permission errors to a human.
⬜ Retry busy errors with backoff, escalate not-found errors, and ask the customer to recheck details on permission errors.
⬜ Retry busy errors with backoff, escalate not-found errors, and retry permission errors once after refreshing credentials.
⬜ Retry busy errors with backoff, ask the customer to confirm the order number on not-found errors, and escalate permission errors.

In a bank’s research system, fetch_document returns ‘unsupported format’ for scanned regulator PDFs, which the subagent’s ocr_document tool can read. The subagent keeps calling fetch_document on the same filing until it hits its turn limit. What should the error contain?

⬜ A non-retryable error saying scans are unsupported, so the subagent skips the filing.
⬜ A retryable flag with a longer backoff so the service has time to convert the scan.
⬜ The raw parser exception with its stack trace and file size so the subagent can diagnose it.
⬜ A non-retryable error saying this tool can’t read scanned PDFs and naming ocr_document as the alternative.

A research coordinator has all 18 tools of its four subagents in addition to its own. It often runs searches itself and fills its context, and the document subagent sometimes runs web searches outside its role. Which two changes address both problems? (select two)

⬜ Tell the coordinator in its prompt to prefer delegating, while it keeps all 18 tools.
⬜ Give each subagent only its role’s tools and let the coordinator keep all 18 to step in when needed.
⬜ Remove the search and document tools from the coordinator, leaving it the tools it needs to delegate.
⬜ Give each subagent only the tools its role requires, for example search tools for the search subagent.

A codebase assistant’s repo-index search_code tool returns results like {id: ‘a91f3c’, ref: ‘x7’, t: 3}. The assistant often fetches the same file twice and can’t tell engineers who owns a result. Which output change helps most?

⬜ Return each result’s repository, file path, owning team and a short matching excerpt as clearly named fields.
⬜ Return repository and path as named fields and keep the owner in the short ID.
⬜ Keep the short IDs and add a decode_id tool to expand each identifier.
⬜ Keep the output and add a system prompt table that explains each short key.

Logs show a codebase assistant doing all file work through Bash: cat to view files, sed to change them and npm test to run tests. Several sed edits corrupted YAML files, and cat on large files floods the context. What guidance fits?

⬜ Use Read to view files and keep sed for edits, running a YAML linter after each change.
⬜ Use Read to view files and Edit to change them, and keep Bash for builds and the test suite.
⬜ Keep Bash for tests and use Write to save each whole edited file after viewing it with cat.
⬜ Find code with Grep and Glob first, and keep Bash for sed edits and test runs.

During a page, an engineer asks about a service last changed in spring. repo-index keeps one quarter of commits, but get_history’s description says only ‘Returns commit history for a file.’ It returns an empty list, and the assistant reports ’no recent changes.’ What helps most?

⬜ Document the tool’s retention window, what an empty result means and where older history can be found.
⬜ Rename it get_recent_history and add ‘covers recent commits’ to the description.
⬜ Add a system prompt rule to treat any empty result with suspicion and search again elsewhere.
⬜ Have get_history return an error for empty results so the assistant searches elsewhere.

Claude must find every call to fetchRates whose options set retry: false. The calls span several lines, with “retry: false” two lines below “fetchRates(url, {”. Grep for fetchRates.*retry: false finds nothing. What should Claude do?

⬜ Add \n to the pattern between the two parts and search again.
⬜ Run the same Grep again with the multiline option enabled.
⬜ Use Glob to list files that mention fetchRates.
⬜ Escape the period and colon, then search again.

The main session asked the Explore subagent to find a faulty date parser. Explore found it, proposed a three-line patch and reported the change as made, but git shows no modified files. What is the right next step?

⬜ Resume the same Explore instance with an allow rule for Edit so it applies the patch.
⬜ Hand Explore’s findings to an agent with write access that makes the edit and runs the tests.
⬜ Record the fix as done: subagent edits reach git only after the session ends.
⬜ Run Explore again in acceptEdits mode so its edits are approved automatically.

A support platform exposes about 400 MCP tools. Their definitions take a large share of context on every turn, while five core tools are used on most turns and specialist tools only now and then. Which setup fits?

⬜ Keep the core tools loaded and defer the rest behind tool search.
⬜ Defer all tools, including the five core ones, behind tool search.
⬜ List the tool names in the prompt and fetch schemas on request.
⬜ Split the tools across three subagents that each load only their own group.

A support agent is connected to 80 MCP tools from several teams and often picks a similarly named tool from a server the support workflow never uses. The support tools themselves work. What targets this most directly?

⬜ Add a prompt rule to prefer support tools whenever a customer mentions an order or refund.
⬜ Remove the servers this workflow never uses, then retest tool selection.
⬜ Keep all servers and put every tool behind tool search.
⬜ Keep all servers and deny only the three misused tools seen in last week’s logs.

A jira MCP server exposes one tool, jira_op, with an op field (create, comment or transition) and a free-form payload. Calls often fail because the payload fields don’t fit the op. What fits best?

⬜ Add a JSON payload example for each op to the jira_op description and keep the single tool.
⬜ Validate payloads on the server and return an error listing the fields the chosen op expects.
⬜ Make op a required enum and add a system prompt table mapping each op to its fields.
⬜ Replace jira_op with one tool per operation, such as create_issue, each with an input schema that fits its payload.

A repo-index server offers nine search tools, such as search_python and search_go, identical except for the language. The assistant often picks the wrong one, and cross-language searches need several calls. What fits best?

⬜ Add file extensions and example queries to all nine descriptions.
⬜ Load all nine through tool search with deferred loading.
⬜ Add a system prompt table mapping file extensions to tools.
⬜ Merge the nine tools into one search_code tool with a language parameter.

Asked whether any code still calls fetchTariffs, a codebase assistant runs Grep for fetchTariffs with the glob *.ts, gets zero matches and says the function is safe to delete. Which two checks should come first? (select two)

⬜ Search again without the *.ts glob, so .tsx and .js files are covered too.
⬜ Ask the owning team whether anything still calls it and delete it if they know of none.
⬜ Search git history for commits mentioning fetchTariffs and check the files they changed.
⬜ Search for indirect references, such as re-exports under another name or lookups by the name as a string.

An archive_search MCP server raises a JSON-RPC error when the upstream archive is down or licensing blocks a document. The agent gets no usable message, keeps calling the tool and never tries other sources. How should the server report these failures?

⬜ As a tool result with isError set, saying what failed and which other sources the agent could try.
⬜ Keep the JSON-RPC errors but add detailed codes the client can map to messages.
⬜ Return a normal empty result and let the agent decide to move on.
⬜ Retry inside the server until the archive responds, then return what it finds.

An MCP server registers a new code-search tool while a session is running, and the client receives notifications/tools/list_changed on the existing connection. How should the client make the new tool available without dropping the connection?

⬜ Reconnect to the server so a fresh handshake returns the updated list.
⬜ Handle notifications/resources/list_changed and call resources/list for the new tools.
⬜ Call tools/list again on the existing connection and give Claude the updated definitions.
⬜ Send a new initialize request on the existing connection to get the current tool list.

A nightly job runs claude -p with –mcp-config pointing at a JSON file whose remote tax-rate server entry has only a url field. The run exits cleanly, but no tax rate is ever looked up. Why?

⬜ Remote servers need command and args; add a command that starts a local client.
⬜ The server starts slowly; raise MCP_TIMEOUT so the run waits longer.
⬜ The entry has no transport type; Claude Code skips url entries without one at startup, so add type: http.
⬜ claude -p reads –mcp-config only with –bare; add –bare.

After gathering facts, a final API call writes the customer’s reply from a case summary. In that call Claude sometimes calls lookup_order again, which adds delay and a second, different answer. The tools are still passed in the request. What is the right fix?

⬜ Set tool_choice to auto for the reply call.
⬜ Set tool_choice to any for the reply call.
⬜ Keep the tools and add an instruction that no tool may be called in this step.
⬜ Set tool_choice to none for the reply call, or send the request without the tools parameter.

schedule_pickup takes a reason parameter, and the carrier system accepts only damaged, wrong_item or changed_mind. Claude sometimes sends values like “broken” or “arrived scratched,” and the carrier rejects the booking. Which change fits best?

⬜ List the three values in the tool description and tell Claude to copy one exactly.
⬜ Define reason in input_schema as an enum of damaged, wrong_item and changed_mind, and describe when each applies.
⬜ Map free-text reasons to the three values in the backend with a keyword table.
⬜ Add a regex allowing only lowercase letters and underscores.

A support agent’s loop uses tool_choice auto, and the parser expects a tool_use block in every response, crashing when Claude answers with text only. The first turn must always call get_customer. On a model that supports forced tool use, which two changes are correct? (select two)

⬜ Accept a text-only response under auto and handle it as a normal reply to the customer.
⬜ Switch to tool_choice any for every turn so Claude can return either text or a tool call.
⬜ Retry the request whenever no tool_use block comes back.
⬜ On the first turn, set tool_choice to type tool with name get_customer to force that call.

process_refund timed out after the request reached the payment service. The tool returns only “Error: timeout,” and the agent has retried, sometimes creating a second refund. Which two details should the error include? (select two)

⬜ A suggested wait time so the agent can retry once the service recovers.
⬜ What was attempted: the refund request ID, the order ID and the amount sent to the payment service.
⬜ An error category of transient so the agent retries like any temporary failure.
⬜ Whether a retry is safe, for example “status unknown; check the refund status before retrying this call.”

A return has three items: a sofa and two chairs. schedule_pickup booked the sofa and one chair but found no slot for the second chair. The tool returned a generic error, so the agent retried all three and double-booked two pickups. What should the tool return?

⬜ Each booked item with its pickup ID, plus the failed item with its reason (no available slot).
⬜ Success for the whole request with a list of pickup IDs, leaving out the failed item.
⬜ An isError result whose message lists the booked items and their pickup IDs.
⬜ Success with a free-text note that some items couldn’t be booked.

A nightly job runs claude -p to refresh API docs and calls get_schema on the catalog MCP server, but the logs show every call denied for lack of permission. What should the job configure?

⬜ An allow rule for get_schema by its short name in the project settings.
⬜ –allowedTools “catalog__get_schema”, with the server prefix but without mcp__.
⬜ –dangerously-skip-permissions so every tool runs without checks.
⬜ –allowedTools “mcp__catalog__get_schema”, which pre-approves that MCP tool by its full name for this run.

Two edits are needed in config.ts, which has identical blocks for dev, staging and production: change timeout: 30 to 60 in the production block only, and rename retries to maxRetries in all three blocks. Both Edit calls fail because each old_string matches three places. Which two fixes are correct? (select two)

⬜ Set replace_all: true on the timeout edit as well, since production appears first.
⬜ Pass the production block’s line number to Edit so only that match is used.
⬜ For the timeout edit, extend old_string with nearby unique lines, such as the production: key above it.
⬜ For the rename, keep old_string as it is and set replace_all: true, since all three blocks need the change.

When an account is suspended, lookup_account returns a 60-line Java stack trace. The support agent sometimes quotes class names to customers and sometimes retries. What should the tool return instead?

⬜ The same stack trace, plus a prompt rule forbidding technical details.
⬜ A short error saying the account is suspended, which actions are blocked and what the agent can do next.
⬜ A short code such as ACCT_SUSPENDED, with code meanings listed in the system prompt.
⬜ A generic “Account unavailable” message with no internal detail.

change_plan takes a dry_run flag: the agent should call it with dry_run true to quote the new monthly price, then with false after the customer agrees. Twice this month it left out the flag, and the plan changed before the customer agreed. What should change?

⬜ Add a prompt reminder to set dry_run true when quoting.
⬜ Split it into two tools: quote_plan_change returns only a price, and apply_plan_change requires a confirmed quote ID.
⬜ Add a PostToolUse hook that reverses any change made without recorded agreement.
⬜ Keep one tool and require a confirm_price parameter filled with the quoted price.

A get_claim tool takes one parameter named id. Engineers often mention policy numbers and claim numbers in the same request, and the agent sometimes passes a policy number, which returns an unrelated claim. What should change?

⬜ Add an enum of valid claim IDs to the id parameter.
⬜ Make get_claim accept either kind of number and return every claim on a policy.
⬜ Rename the parameter to claim_id and describe its format, CLM- followed by eight digits, in the input schema.
⬜ Keep the name id and say in the tool description that it expects a claim number.

A search_claims tool returns every matching claim, sometimes 30,000 rows, in one result. A single broad search can fill the agent’s context, and it then loses track of the engineer’s question. How should the tool change?

⬜ Keep returning every row and tell the agent to summarize large results.
⬜ Silently truncate results at 500 rows.
⬜ Return only the claim IDs for every match and let the agent fetch each claim.
⬜ Return 50 rows by default with a total count, and accept filters and a page token for more.

A submit_record tool validates each extracted record but returns only the first invalid field. Records with five problems take five round trips, and some runs hit the turn limit before a record is accepted. Which two changes to the tool’s error fit? (select two)

⬜ Return the first invalid field with the rule it broke and let the agent resubmit after each fix.
⬜ Return a generic “Validation failed” message and let the agent re-read the schema.
⬜ Return every invalid field in one error, each with the value received and the rule it broke.
⬜ Mark the error as a correctable validation error, distinct from system errors the agent shouldn’t retry.

---

Domain 3: Claude Code Configuration and Workflows (20%)

Terraform files (.tf and .tfvars) are spread across many service directories. The team wants one maintained copy of its Terraform conventions that loads only when Claude Code works on those files. Which two actions configure and verify this? (select two)

⬜ Create a directory-level CLAUDE.md with the Terraform conventions in every directory that has .tf or .tfvars files.
⬜ Create one rule file in .claude/rules/ with paths frontmatter listing globs such as “/*.tf” and “/*.tfvars”.
⬜ Move the conventions into a file under .claude/rules/terraform/ and leave out the paths frontmatter.
⬜ Run claude –debug to check that the rule’s YAML frontmatter parses without errors.

A teammate edited the frontmatter of .claude/rules/sql-style.md, which uses paths: [“db/**/*.sql”]. Since then, /context shows the rule loaded in every session, even sessions that never touch SQL. Which two actions restore and verify the intended scoping? (select two)

⬜ Start a fresh session and check /context before touching SQL files, then have Claude edit a db/ SQL file and check /context again.
⬜ Delete the rule file and add the SQL conventions to the project CLAUDE.md with an @sql-style.md import.
⬜ Run claude –debug to find the frontmatter parse error, then fix the YAML so the paths field parses.
⬜ Start a fresh session, have Claude read one file under db/ that matches the glob, and confirm /context then lists sql-style.md.

A team starts a large feature. Past requirement lists missed edge cases because of unstated requirements, not codebase details, and implementation needs a clean context after a long design discussion. Which two steps should the team take? (select two)

⬜ Start a fresh session once the spec is complete and implement the feature from it.
⬜ Give Claude a minimal prompt asking it to interview the team with AskUserQuestion, then write the spec to SPEC.md.
⬜ Enter plan mode so Claude reads the codebase and proposes an implementation plan for approval before any edits.
⬜ Implement in the same session as the design discussion so Claude keeps every decision in context.

Claude Code generated a payment module. Your review finds three issues, and fixing one changes a function signature that the other two fixes depend on. How should you give this feedback?

⬜ Delegate each issue to a separate subagent so each fix runs in an isolated context.
⬜ Run /clear after each fix and restate the next issue in a fresh, specific prompt.
⬜ Describe all three issues in one detailed message and ask for a single combined fix.
⬜ Raise the issues one at a time, letting Claude fix and verify each before you give the next.

Developers ask Claude Code to add tests for the billing module, but the new tests keep repeating scenarios already covered in tests/billing.test.ts. How should they give Claude the context to avoid duplicates?

⬜ Run test generation in plan mode so duplicates can be rejected during plan review.
⬜ Reference the existing test file in the prompt, such as @tests/billing.test.ts, before asking for new tests.
⬜ Reference the whole test directory in the prompt, such as @tests/, so the full suite is available.
⬜ Add a CLAUDE.md instruction that generated tests must never repeat scenarios the suite already covers.

Claude Code is revising a single-file currency rounding function with a clear, agreed approach. Each revision fixes one edge case and breaks another that passed before, and prose descriptions of the rules have been read inconsistently. How should you drive the iteration?

⬜ Write a test suite covering all the edge cases first, then share the failing test output to guide each revision.
⬜ Move the rounding rules into the project CLAUDE.md so every session loads them.
⬜ Switch to plan mode so Claude explores the rules and proposes a complete design before editing.
⬜ Add two or three input/output examples for each rounding rule to the prompt before every revision.

Your team shares a /review skill in .claude/skills/. You want a stricter personal version that teammates never see, while keeping the team’s /review available to you unchanged. How do you create it?

⬜ Create it as ~/.claude/skills/review-deep/SKILL.md so it has its own command name.
⬜ Create it as ~/.claude/skills/review/SKILL.md, reusing the team skill’s name in your home directory.
⬜ Add the stricter review steps to ~/.claude/CLAUDE.md so they load in every session.
⬜ Edit the project’s .claude/skills/review/SKILL.md in your working copy and leave the change uncommitted.

A team’s CI reviews run Claude Code, and the root CLAUDE.md has become unmanageable. Review criteria must apply to every review. Testing conventions apply only to test files, which most pull requests don’t touch. Which two changes should the team make? (select two)

⬜ Split the review criteria into standards files and import them into the root CLAUDE.md with @path syntax.
⬜ Package the review criteria as an on-demand skill under .claude/skills/ that reviews can invoke.
⬜ Split the testing conventions into a separate file and import it into the root CLAUDE.md with @path syntax.
⬜ Move the testing conventions into a .claude/rules/ file with a paths glob matching test files.

Review criteria that should apply to every pull request live in services/api/CLAUDE.md. Reviews of pull requests that touch only other directories ignore them. The CI runner image is shared by several unrelated repositories. Where should the criteria live?

⬜ In a CLAUDE.md at the repository root, committed to version control.
⬜ In ~/.claude/CLAUDE.md baked into the CI runner image.
⬜ In .claude/rules/review-criteria.md with a paths glob of services/api/**/*.
⬜ In a CLAUDE.local.md at the repository root.

A nightly job resumes a named Claude Code session that rewrites deprecated API calls, then has it audit its own diff. A fresh session flags regressions that the audit approved. Which two pipeline changes fix the audit step? (select two)

⬜ Start a fresh audit instance and include the migration session’s full transcript in its context.
⬜ Give the audit instance only the diff and the project’s CLAUDE.md, not the migration transcript.
⬜ Run /compact on the migration session before the audit turn.
⬜ Run the audit as a separate claude -p invocation that doesn’t resume the migration session.

A pipeline step runs claude “review the staged diff” to produce review findings. The job hangs until the CI timeout kills it. The step must process the prompt, print its findings and exit on its own. What should you change?

⬜ Add –output-format json to the invocation.
⬜ Add –max-turns 1 to the invocation.
⬜ Pipe the staged diff into the command on stdin.
⬜ Add the -p flag to the invocation.

An engineer wrote the code review criteria in their own ~/.claude/CLAUDE.md. Reviews on their machine follow them, but CI runs and teammates’ sessions ignore them. Both must use the same criteria. What is the fix?

⬜ Move the criteria into a project-level CLAUDE.md committed to the repository.
⬜ Move the criteria into CLAUDE.local.md in the project root and add it to .gitignore.
⬜ Add a pipeline step that copies the file into the CI runner’s home directory.
⬜ Add the criteria to the checked-in .claude/settings.json file.

A platform team owns shared standards files in standards/ and the root .claude/ directory and updates them often. Each package team maintains its own package CLAUDE.md and should load only the standards its stack needs. What should package teams do?

⬜ Add @import lines in each package’s CLAUDE.md that reference only the standards files for that package’s stack.
⬜ Move each standards file into .claude/rules/ at the root with a paths glob matching the packages that use it.
⬜ Copy the text of the relevant standards files into each package’s CLAUDE.md during setup.
⬜ Import every standards file in each package’s CLAUDE.md so Claude expands only the relevant ones at run time.

Claude Code iterates against a test suite your team wrote first, and it still adds tests when developers find edge cases mid-session. The latest diff shows two assertions rewritten to match wrong output, so the suite now passes. What is the right correction?

⬜ Start a fresh Claude instance to review each diff independently before you accept it.
⬜ Add a PostToolUse hook that runs the full test suite after each implementation edit.
⬜ Add a PreToolUse hook that blocks every Write and Edit call on files in the test directory.
⬜ Revert the test edits and tell Claude that removing or editing tests is unacceptable.

Generated tests often repeat scenarios the suite already covers because developers forget to reference existing test files. Test generation happens only occasionally, and the project CLAUDE.md is already long. What is the most maintainable team-wide fix?

⬜ Have each developer create a test-generation skill in ~/.claude/skills/ on their own machine.
⬜ Tell developers to include @tests/ in each test-generation prompt so the whole directory loads.
⬜ Create a project skill in .claude/skills/ whose procedure starts by reading the target module’s existing test files.
⬜ Add an instruction to the project CLAUDE.md telling Claude to read existing test files before generating tests.

A CI review job runs claude -p with –output-format json, but the findings in the result field are sometimes prose that breaks parsing. Each run is slow, so an external re-run loop isn’t acceptable. What change gives the job schema-validated findings when the run succeeds?

⬜ Switch to –output-format stream-json and parse the final event for the findings.
⬜ Add –json-schema with the findings schema and read the structured_output field.
⬜ Add a pipeline step that validates each result against the schema and re-runs the job when validation fails.
⬜ Move the required output format and two example findings into CLAUDE.md so every CI run loads them.

The project CLAUDE.md holds concise coding standards plus a 150-line release procedure the team runs a few times a month. Every session loads all of it, and Claude now misses some of the standards. Where should the release procedure live?

⬜ In a skill in .claude/skills/, keeping the coding standards in CLAUDE.md.
⬜ As a short summary inside CLAUDE.md, letting Claude infer the detailed steps.
⬜ In a separate file pulled into CLAUDE.md with an @import reference.
⬜ In a .claude/rules/ file with a paths glob matching the deployment scripts.

A prompt tells Claude to plan and wait for approval before editing, but Claude sometimes starts editing anyway. The developer needs a guarantee that nothing is edited until a plan is approved, with implementation following in the same session. Which approach works?

⬜ Add a PreToolUse hook that denies every Edit and Write call for the session.
⬜ Run the session in the default permission mode so every edit asks for approval.
⬜ Add a rule to the project CLAUDE.md requiring Claude to plan before any edit.
⬜ Switch the session to plan mode and approve the plan before implementation starts.

A nightly test run shows four failures in four modules that don’t share code or import each other. Each has a clear stack trace pointing to one file. How should you hand these to Claude Code?

⬜ Launch an Explore subagent to investigate all four failures and return a summary before any fixes.
⬜ Describe all four failures in one message so Claude can design the fixes together.
⬜ Enter plan mode first so Claude proposes a coordinated repair strategy across the four modules.
⬜ Give Claude one failure at a time, check that the fix passes its test, then move on to the next.

An agent converts legacy log lines into a standard JSON event format, with a detailed prose description of the rules in every prompt. Output varies across log variants (not on identical inputs). For lines with missing fields, Claude sometimes omits the key, sometimes writes null and sometimes invents a value. Which two changes improve consistency most directly? (select two)

⬜ Move the same prose rule description into the project CLAUDE.md so every session loads it.
⬜ Add two or three example pairs, each showing a sample log line and its expected JSON output.
⬜ Set the sampling temperature to zero so the model applies the rules the same way each run.
⬜ Include an example showing the expected output for a log line with a missing field.

Shared review standards live at standards/review-criteria.md in the repository root, where CI starts Claude Code, and each run checks out to a new temporary path. How should the import in services/api/CLAUDE.md reference the standards file?

⬜ With the runner’s absolute path, such as @/home/runner/work/repo/standards/review-criteria.md.
⬜ With a quoted path, @"../../standards/review-criteria.md".
⬜ With @standards/review-criteria.md, relative to the directory where CI starts Claude Code.
⬜ With @../../standards/review-criteria.md, relative to the services/api/CLAUDE.md file itself.

You set context: fork on the verbose /dependency-audit skill, and now it audits the wrong packages. Its instructions refer to “the diff discussed earlier in this conversation.” How do you fix the skill while keeping its output isolated?

⬜ Set agent: general-purpose in the frontmatter to run the fork in the default subagent.
⬜ Set background: false so the main session waits for the forked skill’s result.
⬜ Remove context: fork and run /compact after each audit to shrink the output.
⬜ Rewrite the instructions to stand alone and have the skill run git diff to get the changed files itself.

Terraform conventions live in .claude/rules/infra/terraform.md. The team expected the infra/ folder to scope the rule, but it loads in every session, and Terraform files sit in several directories. How do you make the rule load conditionally?

⬜ Move the conventions into a directory-level CLAUDE.md in the main Terraform directory.
⬜ Convert the conventions into a skill that engineers invoke when they work on Terraform.
⬜ Rename the rule’s subfolder under .claude/rules/ to match the path of the Terraform files.
⬜ Add YAML frontmatter to the rule file with a paths field containing a glob such as **/*.tf.

A team wrote 300 lines of notes about legacy billing code that lives entirely under services/legacy-billing/. Every engineer needs the notes, but sessions that never touch that code shouldn’t load them. Where do the notes belong?

⬜ In a CLAUDE.local.md at the repository root, listed in .gitignore.
⬜ In a separate notes file referenced from the root CLAUDE.md with an @import.
⬜ In each engineer’s ~/.claude/CLAUDE.md under a legacy billing heading.
⬜ In a CLAUDE.md inside services/legacy-billing/, committed to the repository.

A team’s /trace-legacy skill fills the main session with long exploration notes. Engineers need only its final report, and the report’s exact file paths and line numbers must stay accurate for later work. What is the right fix?

⬜ Set context: fork in the skill’s SKILL.md frontmatter.
⬜ Run /compact with a focus instruction right after the skill finishes.
⬜ Set the skill’s allowed-tools to Read, Grep and Glob only.
⬜ Move the skill’s detailed guidance into a reference.md that SKILL.md links to.

A teammate added context: fork to your /legacy-style skill. Its SKILL.md contains only reference coding guidelines and no task instructions. Invocations now return nothing useful, and the conventions are ignored. What should you change?

⬜ Set background: false so the invoking turn waits for the subagent’s result.
⬜ Remove context: fork so the guidelines load into the invoking conversation.
⬜ Rewrite the skill’s instructions so they stand alone without the conversation history.
⬜ Set agent: Explore so the forked skill runs with read-only tools.

Claude-generated tests skip error and boundary cases. The team’s one-page testing standards must load in every session, even while Claude edits source files, without anyone invoking them. Which two changes meet these requirements? (select two)

⬜ State the test command and the required error cases concretely in the project CLAUDE.md.
⬜ Move the standards into .claude/rules/testing.md with a paths glob matching test files.
⬜ Package the standards as a skill that Claude invokes when it detects test work.
⬜ Import the one-page standards file into the project CLAUDE.md with @path syntax.

A rule file in .claude/rules/ has frontmatter with paths: [“src/billing/**/*”] and allowed-tools: [“Read”, “Grep”]. The conventions load correctly, but Claude still edits billing files, and the team needs those edits blocked. What is the correct fix?

⬜ Add a deny permission rule in settings.json that blocks Write and Edit on src/billing files.
⬜ Run claude –debug and fix the frontmatter YAML so the allowed-tools field parses.
⬜ Move the conventions into a skill and set allowed-tools in its SKILL.md frontmatter.
⬜ State in the rule’s body that files under src/billing are read-only and must never be changed.

A nightly CI job runs claude -p to report on legacy code. When the agent asks to run a Bash command, the step stalls until it times out. The report doesn’t need Bash, and policy forbids auto-approving Bash in CI. Which change fixes the hang?

⬜ Add Bash to the allowed tools in .claude/settings.json so it runs without prompting.
⬜ Run the job with –permission-prompts none so unresolved permission requests are denied.
⬜ Configure –permission-prompt-tool with an MCP tool that approves the agent’s Bash requests.
⬜ Pipe a stream of yes answers into standard input to answer the prompts.

An application prompts Claude to interview the engineer about requirements before generating boilerplate. The SDK call passes a tools array with only Read, Write, Grep and Glob. Claude never asks anything and builds on its own assumptions. What is the fix?

⬜ Start the session in plan mode so Claude must analyze before editing.
⬜ Add a permission allow rule for AskUserQuestion so its calls are approved.
⬜ Generate the questions inside the canUseTool callback and return the engineer’s answers.
⬜ Add AskUserQuestion to the tools array passed in the SDK call.

Four tasks are queued for Claude Code. Which two should the team run with direct execution rather than plan mode? (select two)

⬜ Add a date-range validation check to the known submitForm handler in one file.
⬜ Replace a hardcoded timeout with the existing shared TIMEOUT constant in one file.
⬜ Fix an intermittent crash in a legacy reporting module nobody on the team has worked in.
⬜ Add retry logic to one HTTP client wrapper, where the team hasn’t chosen between simple backoff and the existing circuit-breaker helper.

A CI review job pastes the PR diff into the prompt as text. A .claude/rules/ file with paths: ["**/*.test.ts"] holds the test review criteria, but reviews never apply them, and the criteria must load only for test files. What change activates the rule?

⬜ Have the review step read the changed test files with the Read tool instead of only pasting the diff.
⬜ Move the rule into a testing/ subfolder under .claude/rules/ so the folder scopes it.
⬜ List the changed test file paths in the review prompt so the glob can match them.
⬜ Remove the paths frontmatter so the rule loads at session start.

CI reviews ignore the team’s review criteria while one engineer’s sessions follow them; the criteria are in that engineer’s user-level CLAUDE.md. You need a read-only check of which memory files a session loaded at launch, plus a lasting fix. Which two actions do this? (select two)

⬜ Move the review criteria into the project CLAUDE.md that is checked into the repository.
⬜ Run /memory to browse memory locations and open the engineer’s CLAUDE.md files for editing.
⬜ Add the review criteria to .claude/settings.json so every run receives them through version control.
⬜ Run /context in a session and check the Memory files section to see which CLAUDE.md files loaded.

A CI job runs claude -p to review each pull request on every push. CLAUDE.md already says to report only new issues, but every re-run reposts the same findings. What stops the duplicates?

⬜ Run each re-review with –resume on the previous review session.
⬜ Limit each re-review to the commits pushed since the previous review.
⬜ Have the pipeline fetch the earlier review’s findings and include them in each re-run’s prompt.
⬜ Add a step that drops any finding whose text matches an existing PR comment.

One developer’s sessions keep applying a retired API convention; teammates’ sessions don’t. /memory on that machine shows the current rule in the project CLAUDE.md and the retired rule in ~/.claude/CLAUDE.md. What fixes this?

⬜ Add the current convention to .claude/settings.local.json on the developer’s machine.
⬜ Delete the retired convention from the developer’s ~/.claude/CLAUDE.md.
⬜ Delete the retired convention from the project CLAUDE.md and commit the change.
⬜ Restate the current convention in the project CLAUDE.md and mark it IMPORTANT.

A nightly, unattended Claude Code job generates starter tests for new modules. Interactive sessions handle ambiguity by having Claude interview the developer, but for some new modules the intended behavior is ambiguous. How should the job’s prompt handle this?

⬜ Write explicit success criteria and instructions for the ambiguous cases into the job’s prompt.
⬜ Run the job in plan mode so it proposes a test plan instead of writing files.
⬜ Add the team’s general testing conventions to CLAUDE.md so the job can infer each module’s needs.
⬜ Tell the job to interview an on-call maintainer with AskUserQuestion before generating tests.

Your /code-metrics skill uses context: fork, and a later step in the same turn needs its report, but Claude often continues before the report arrives. The skill’s verbose output must stay out of the main session. What should you change?

⬜ Add a CLAUDE.md rule telling Claude to wait for forked skills.
⬜ Set background: false in the skill’s frontmatter so the invoking turn waits for the result.
⬜ Remove context: fork so the analysis runs in the main conversation.
⬜ Set agent: general-purpose so the forked subagent runs in the foreground.

An error-handling standard lives in .claude/rules/error-handling.md with paths: [“src/**/*.ts”]. Claude ignores it in design discussions that happen before any file is read or edited, and you want it loaded in every session from launch. What fixes this?

⬜ Broaden the glob to */ so it matches every file.
⬜ Move the standard into a CLAUDE.md inside src/.
⬜ Remove the paths field from the rule’s frontmatter so it loads unconditionally at launch.
⬜ Convert the standard into a skill that developers invoke at the start of sessions.

A repository is full of fragile legacy code, and the team wants every Claude Code terminal session in it to start in plan mode with no extra step from anyone. What should you configure?

⬜ An onboarding note telling developers to start with claude –permission-mode plan.
⬜ A CLAUDE.md instruction telling Claude to enter plan mode at the start of every session.
⬜ permissions.defaultMode set to plan in each developer’s ~/.claude/settings.json.
⬜ permissions.defaultMode set to plan in the repository’s .claude/settings.json.

You copied the team’s /analyze skill to ~/.claude/skills/analyze-plus/SKILL.md but left name: analyze in its frontmatter. Now /analyze runs your personal copy and the team skill never runs. Your version must stay private. What fixes this?

⬜ Move your version into the project’s .claude/skills/ under the folder name analyze-plus.
⬜ Invoke your version by its folder name, /analyze-plus, and leave the frontmatter as is.
⬜ Change the name field in the personal skill’s frontmatter to analyze-plus.
⬜ Add context: fork to the personal skill so the two skills resolve in separate contexts.

You give Claude Code a three-phase task: find every call site of a deprecated helper, design its replacement, then apply it. The search fills the context window, and a /compact attempt dropped file paths you needed. What should change on the next run?

⬜ Run /compact again with an instruction to keep the full call-site list.
⬜ Run /clear once discovery finishes, then design in the empty context.
⬜ Delegate the call-site search to the Explore subagent, which reports its findings back to the main session.
⬜ Start in plan mode so search and design run read-only before edits are approved.

An /analyze-deps skill prints thousands of exploration lines. Its instructions stand alone. It must stay out of the main session, be guaranteed read-only and return its report in the invoking turn. Which two frontmatter settings meet these requirements? (select two)

⬜ Set context: fork and leave agent unset so the default subagent runs the skill.
⬜ Set background: false so Claude Code waits for the result in the invoking turn.
⬜ Set context: fork with agent: Explore in the SKILL.md frontmatter.
⬜ Keep the skill in the main context and set allowed-tools to read-only tools.

Claude-generated tests rebuild setup by hand instead of using the fixture factories in src/fixtures/, and many assert trivial getter behavior. Tests sit next to the code across the repository. Which two configuration changes fix this? (select two)

⬜ Add a PostToolUse hook that runs the test suite after Claude writes each test file.
⬜ Document the fixture factories in src/fixtures/ and how to use them in the project CLAUDE.md.
⬜ State in CLAUDE.md which behaviors need tests and which trivial cases, such as simple getters, to skip.
⬜ Create .claude/rules/fixtures.md with a paths glob of src/fixtures/**/* describing the factories.

A CI step pipes a 25 MB diff into claude -p to summarize the changeset, and the run exits non-zero because the piped input is too large. The summary must catch inconsistencies that span files. What is the fix?

⬜ Write the diff to a file in the workspace and reference the file path in the prompt.
⬜ Split the diff into pieces and run a separate claude -p on each.
⬜ Add –output-format stream-json so the input is handled as a stream.
⬜ Put the diff in the prompt argument instead of piping it through stdin.

A developer will use direct execution, not plan mode, for a well-understood bug fix in one known file. Which two practices make the direct run reliable? (select two)

⬜ Reference the exact file in the prompt and describe what a correct fix looks like.
⬜ Give Claude a test command to run and ask it to show the passing output.
⬜ Switch to plan mode for one prompt so Claude proposes the edit first.
⬜ Record the bug’s details in the project CLAUDE.md so the fix loads into the session.

A review of agent-generated boilerplate finds four small, unrelated issues, each with an obvious single-file fix. You’ve already corrected the agent twice on one of them this session without success. Which two actions are recommended? (select two)

⬜ Give the agent the remaining issues one at a time, checking each fix before raising the next.
⬜ Switch to plan mode and have the agent produce an approved plan for all four fixes first.
⬜ Run /clear, then restate the twice-corrected issue in a fresh, more specific prompt.
⬜ Describe all four issues in one message and ask for a single combined fix.

A CI investigation job must explore the repository and print a migration plan without changing any file, even through shell commands. A later job implements the approved plan. How should the investigation job start Claude Code?

⬜ Add Edit and Write to the deny list in .claude/settings.json and run the job with claude -p.
⬜ Have the job script press Shift+Tab to enter plan mode before submitting the prompt.
⬜ Run claude -p with –permission-mode plan, then capture the printed plan.
⬜ Run claude -p with a prompt instruction that forbids edits and asks only for a plan.

A developer runs Claude Code in plan mode to reorganize a pipeline’s review workflow files. Claude presents a plan in which one step names the wrong workflow file; everything else is right. She wants to fix that step before any edits start, keeping the exploration Claude already did. What should she do?

⬜ Reject the plan and start a fresh session naming the correct file.
⬜ Approve the plan, then press Escape just before Claude reaches the wrong step.
⬜ Press Ctrl+G at the approval prompt, fix the step in her editor, then approve the plan.
⬜ Approve with manual edit approval, then deny the edit when Claude reaches the wrong file.

A pipeline sends its pre-review search to the built-in Explore subagent. Explore ignores the CLAUDE.md rule to skip gen/, and a later step can’t resume Explore with follow-up questions. Which two changes address these problems? (select two)

⬜ Use a general-purpose subagent for discovery work that later steps continue.
⬜ Restate the gen/ exclusion in the task prompt Claude sends to Explore.
⬜ Move the gen/ exclusion from CLAUDE.md into a .claude/rules/ file with a paths glob.
⬜ Have the later step resume the first Explore run by its agent ID.

A CI step runs claude -p for an automated review. One run started, then failed because authentication was missing; the step logged only stderr and captured nothing. Which two mechanisms make the step fail and record the reason for failures inside a run? (select two)

⬜ Capture stdout, because a run that fails after starting prints the failure reason there.
⬜ Fail the step whenever the review output contains the word error.
⬜ Capture stderr, because a run that fails after starting writes the reason there.
⬜ Fail the step when the claude process exits with a non-zero status.

A –json-schema findings schema declares author_email with “format”: “email”, but some runs still return addresses the notifier rejects. The notifier accepts only addresses in the employee directory, and one bad address blocks the whole batch. What is the correct fix?

⬜ Parse structured_output in the pipeline and check each author_email against the employee directory before notifying.
⬜ Add a CLAUDE.md rule that author_email must be an address from the employee directory.
⬜ Replace the format annotation with a regex pattern for email syntax.
⬜ Re-run the job whenever the notifier rejects a batch.

A team split a long CLAUDE.md into topic files under .claude/rules/. deployment.md now loads in every session, even ones that never touch deploy files. It begins: — paths: [“deploy//*”, “/*.deploy.yml”] Use blue-green deployment steps for every service rollout. What is the correct fix?

⬜ Move the guidance into a CLAUDE.md inside the deploy/ folder.
⬜ Convert deployment.md into a skill invoked when reviewing deployment changes.
⬜ Add a closing — line after the paths entry so the frontmatter block parses.
⬜ Rewrite the paths value as a YAML block list with one glob per line.

A developer built a /ci-review command in ~/.claude/commands/ on their laptop. The CI job checks the repository out into a fresh container and can’t find the command, and teammates want to run it locally before pushing. Where should the command file live?

⬜ Copied into ~/.claude/commands/ inside the CI container by a setup step.
⬜ Pasted into the project CLAUDE.md under a commands heading.
⬜ In .claude/commands/ in the repository, committed to version control.
⬜ Registered in .claude/settings.json so it is shared through version control.

Your /generate-tests skill writes test files, and while it’s active Bash must be unavailable to Claude, enforced rather than requested. Other CI jobs in the repository still need Bash. Which change achieves this?

⬜ Add disallowed-tools: Bash to the skill’s SKILL.md frontmatter.
⬜ Write a rule in the skill’s instructions that forbids running Bash.
⬜ Add a permission deny rule for Bash in .claude/settings.json.
⬜ Set allowed-tools to Read, Write and Grep in the skill’s frontmatter, leaving Bash out.

Claude Code must fix three bugs. Two are in unrelated functions of label_printer.py; the third is in an ETA service that reads a date field one of the label bugs changes. How should they be sent?

⬜ Send the two label_printer.py bugs together, and the ETA bug on its own.
⬜ Send all three one at a time, starting with the ETA bug.
⬜ Send the ETA bug first, then both label bugs together once the ETA fix passes.
⬜ Send the ETA bug together with the label bug that changes its date field, and the other label bug on its own.

During an on-call page, a dispatch service rejects valid postcodes. The engineer has never worked in this repository and suspects a one-line validation pattern, which Grep finds in three files, one under dispatch/. What should she do first?

⬜ Use plan mode and have Claude trace which of the three checks the failing request actually reaches.
⬜ Have Claude edit the copy under dispatch/, the likeliest path, then run that module’s tests.
⬜ Switch to acceptEdits, have Claude update all three copies, and review the diff afterward.
⬜ Write a short spec of the pattern change herself, then have Claude apply it in one edit.

Three needs come up: database migration edits must pass a schema linter without relying on model judgment; a 40-step incident postmortem procedure is used a few times a month; a monorepo license scan prints thousands of lines. Which mapping fits best?

⬜ Linter in a PostToolUse hook, postmortem procedure in CLAUDE.md, license scan in a subagent.
⬜ Linter in a PostToolUse hook on migration edits, postmortem procedure in an on-demand skill, license scan in a subagent with its own context.
⬜ Linter step in CLAUDE.md, postmortem procedure in a skill, license scan in a subagent.
⬜ Linter in a skill with allowed-tools, postmortem procedure in CLAUDE.md, license scan in a subagent.

An engineer set up Claude Code on a new laptop. Mid-session she wants to add a personal coding rule to her user-level CLAUDE.md, which doesn’t exist yet on this machine. What should she do?

⬜ Run /init, which generates the user CLAUDE.md and opens it.
⬜ Ask Claude to remember the rule, which writes it into her CLAUDE.md automatically.
⬜ Add the rule as an instructions entry in .claude/settings.json.
⬜ Run /memory, choose the ~/.claude/CLAUDE.md entry so Claude Code creates and opens it, then add the rule.

A CI review job runs claude -p with –permission-mode acceptEdits. Last week it rewrote two files while fixing its own findings, and a later step committed them. The job can receive the diff as input and run with the repository mounted read-only. Which change most reliably keeps the checkout untouched?

⬜ Add a line to the review prompt that Claude must not modify, create or delete files.
⬜ Mount the repository read-only, pass the diff as input, and restrict built-in tools to Read, Grep and Glob.
⬜ Keep acceptEdits and pass –disallowedTools Edit Write, leaving the other tools available.
⬜ Switch to dontAsk with –allowedTools for Read, Grep, Glob and Bash(git diff *) in the writable checkout.

The payments team adds .claude/rules/payments.md with paths set to src/payments/**, and developers often run /compact in long sessions. Which two statements about this rule are correct? (select two)

⬜ The rule enters context when Claude reads a file under src/payments/, not when the session starts.
⬜ After /compact, the rule reloads on demand when Claude next works with a matching file, rather than being re-injected with the root CLAUDE.md.
⬜ At session start, the rule loads whenever files matching src/payments/** exist in the repository.
⬜ The rule also loads for src/payments-legacy/, because the pattern acts as a prefix.

Claude has presented a plan to rename a config key across four services. The developer agrees but wants to be able to stop any change she disagrees with. Which approval option fits?

⬜ Approve the plan with “manually approve edits”; plan mode ends and Claude starts editing, asking before each edit.
⬜ Approve with auto mode and expect its classifier to show her each edit first.
⬜ Stay in plan mode and have Claude apply the rename service by service.
⬜ Approve with auto-accept edits and check each service’s diff before letting Claude continue.

A rule file in .claude/rules/ sets paths to src/api/*.ts. Claude follows it when editing src/api/users.ts but ignores it in src/api/v2/orders.ts, and every other rule loads correctly. What is the most likely cause?

⬜ A single * matches one directory level; use src/api/**/*.ts.
⬜ Rules load at session start, before the v2 folder existed.
⬜ Each paths entry covers one folder; a second rule is needed for v2.
⬜ A CLAUDE.md in src/api/v2/ overrides rules there.

A team’s .claude/rules/ folder holds 38 flat files, such as api-errors.md and ui-forms.md, and new engineers can’t find the right one. The tech lead wants to group them by area but worries Claude will stop seeing rules one level deeper. What should the team do?

⬜ Merge each area’s rules into one large file per area at the top of .claude/rules/.
⬜ Group the files into subfolders such as rules/api/ and rules/ui/; Claude Code discovers rule files in subfolders recursively.
⬜ Move each area’s rules into a CLAUDE.md inside that area’s source folder.
⬜ Group them into subfolders and import each one from the root CLAUDE.md with @ lines.

Claude Code finished the first of twelve similar data-layer migrations, but the diff shows it also renamed a public method that eleven services call, although the task said the public interface must not change. The other eleven are queued in this session. What should the engineer do before Claude continues?

⬜ Let the batch finish and add a final review step that flags public method renames.
⬜ Use /rewind to undo the first migration, then restart all twelve with the same prompt.
⬜ Stop, add the interface rule to CLAUDE.md, and let Claude continue in this session.
⬜ Stop, state exactly which interface must not change, and have Claude fix the first file and recheck its diff.

A monorepo root has a 300-line CLAUDE.md, and services/payments/ has its own team CLAUDE.md. A developer starts Claude Code inside services/payments/, expecting the long root file to stay out of context. What happens at launch?

⬜ Only the payments CLAUDE.md loads, because the file where Claude starts replaces the root file.
⬜ The root file loads at launch, and the payments file loads once Claude reads a file there.
⬜ The payments file replaces the root one because the closer file takes priority.
⬜ Both files load at launch: the root file from the parent directory and the team file from the start directory.

A project skill shows [ticket-id] as its argument hint. A developer ran it with a sentence instead of an ID, and it updated the wrong ticket. Malformed IDs must be rejected before any lookup. What should change?

⬜ Put a ticket ID pattern in argument-hint so Claude Code rejects non-matching input.
⬜ Add the ID format to CLAUDE.md so Claude validates IDs before invoking skills.
⬜ Describe the valid format in the skill’s description so Claude refuses other input.
⬜ Validate the argument in the skill’s own steps or a script it runs, stopping before any lookup if it fails.

A project CLAUDE.md contains the line: See @docs/release.md before a release. The team expects the release checklist to load as an import, but it never does, although the file exists. Which two statements are correct? (select two)

⬜ Writing @docs/release.md outside backticks makes Claude Code import the file.
⬜ Claude Code imports a backtick-formatted path only when it sits on its own line.
⬜ Writing @./docs/release.md inside the backticks makes it a relative import.
⬜ Text inside backticks is treated as a literal mention, not as an import.

Claude’s plan to rename the order_ref field updates the API and the web client, but never mentions the nightly export job, which reads that field. What should the engineer do before approving?

⬜ Approve now and ask Claude to update the export job after the other edits.
⬜ Point out the export job, ask Claude to revise the plan, and review the revised plan before approving.
⬜ Approve with manual edit approval and add the export change when a related file comes up.
⬜ Approve as written and ask Claude to search for other readers of order_ref afterward.

An engineer asks Claude to “fix the time zone bug in scheduling.” Claude changes display code, the database layer and a cron job, and the bug remains. She has since traced the fault to one function and can reproduce it with one input. What should the next request contain?

⬜ A request to start in plan mode and list every time zone conversion before editing.
⬜ The file and function, plus one sample input with its expected output and the output it gives now.
⬜ The failing function’s name, a note that it mishandles time zones, and a request to fix only it.
⬜ A request to undo the three changes and retry in smaller separate edits.

A review job runs claude -p “Run git diff main and review the changes” with –allowedTools “Bash(git diff *),Read,Grep”. Security now requires CI review jobs to have no Bash access at all. Which two changes keep the review working? (select two)

⬜ Pipe the output of git diff main into claude -p on stdin, and remove the Bash entry from –allowedTools.
⬜ Add –bare, which removes Bash and keeps the other tools.
⬜ Keep Bash and add a PreToolUse hook that rejects anything other than git diff.
⬜ Change the prompt to “Review the diff on stdin” so Claude doesn’t try to run git diff itself.

Compliance wants one instruction about patient identifiers loaded into every Claude Code session on company laptops and CI runners, in current and future repositories, even where teams exclude other CLAUDE.md files. Where should it go?

⬜ In each repository’s root CLAUDE.md, with a review rule protecting that section.
⬜ In the managed policy CLAUDE.md, deployed by IT to every laptop and CI runner.
⬜ In each developer’s ~/.claude/CLAUDE.md and the runners’ home folders, set up by a script.
⬜ In a .claude/rules/ file without paths in each repository.

A data team’s review job often reads shared code under teams/platform/, whose CLAUDE.md tells Claude to convert raw SQL to the ORM, which conflicts with data team conventions. The data team still needs to read those files. What fits best?

⬜ Ask the platform team to remove the ORM instruction for everyone.
⬜ Add a data team rule saying other teams’ CLAUDE.md files don’t apply.
⬜ Run the review job with –bare so no CLAUDE.md files load.
⬜ Add teams/platform/CLAUDE.md to claudeMdExcludes in the settings the data team’s job uses.

A health-app company’s review step runs claude -p and posts each finding as an inline PR comment. Some findings cite lines the pull request never changed, often inside files it did change, and the comment API rejects them. What should the team add?

⬜ The full contents of each changed file in the prompt instead of the diff.
⬜ A pipeline step that checks each finding’s file and line against the diff before any comment is posted.
⬜ A per-run schema listing the changed files as the only allowed paths.
⬜ A retry that reruns the whole review whenever the API rejects a comment.

A team has two rule files with identical text, one scoped to src/api//*.ts and the other to src/jobs//*.ts. Engineers keep updating one and forgetting the other. What is the simplest fix that keeps the same scope?

⬜ Move the text into src/CLAUDE.md, which covers both folders.
⬜ Keep both files and add a CI check that they match.
⬜ Keep one rule file and list both glob patterns under paths.
⬜ Scope one file to src/**/*.ts and delete the other.

A shared skill in the repository’s .claude/skills/ publishes a release and pushes a production tag. Claude must not start it on its own during normal coding, and every tag push must need a person’s approval, even when an engineer runs the skill. Which two changes meet both needs? (select two)

⬜ Set user-invocable: false so Claude won’t choose it automatically while engineers still can.
⬜ List Bash(git push –tags *) in the skill’s allowed-tools so each push needs approval.
⬜ Set disable-model-invocation: true so only engineers can start it with /release.
⬜ Add an ask rule for Bash(git push –tags *) to .claude/settings.json so each push asks for confirmation.

Engineers run the team’s /scaffold-service skill, which expects a service name and then a port. They often swap the values or leave out the port. The team wants the expected arguments shown as a placeholder while engineers type the command. What should they change?

⬜ Add a first step that checks both values and stops with a usage message.
⬜ Describe both arguments under a Usage heading in SKILL.md.
⬜ Add argument-hint: “[service-name] [port]” to the SKILL.md frontmatter.
⬜ Set disable-model-invocation: true so only engineers can start the skill.

An engineer puts the session in plan mode before refactoring a legacy billing module. Claude first needs to know which tests cover the module and which packages depend on it. Which activity fits plan mode?

⬜ Modify the module on a scratch branch to test the approach, then present that diff.
⬜ Run exploratory commands such as npm ls, inspect callers, then write a plan without modifying any file.
⬜ Run the tests with coverage and save the coverage report in the repository.
⬜ Use only the Read tool, since plan mode blocks shell commands such as npm ls.

A platform team’s CLAUDE.md says “Do not run rm on shared build directories,” but in an unattended run the assistant still ran rm -rf on one. The team needs a rule enforced in every session. What should they change?

⬜ Move the line into the managed policy CLAUDE.md, which engineers can’t exclude.
⬜ Put the line in a rules file without paths and repeat it in every skill that runs Bash.
⬜ Add a deny rule such as Bash(rm *) to .claude/settings.local.json and keep the CLAUDE.md line.
⬜ Add a deny rule such as Bash(rm *) to managed settings, keeping the CLAUDE.md line to explain why.

An engineer keeps personal coding-style rules in ~/dotfiles/claude-rules/ and symlinks them into each repository’s .claude/rules/. In a newly cloned repository the rules didn’t apply, and some use paths frontmatter. What is the cleanest setup?

⬜ Copy the files into each project’s .claude/rules/ and commit them.
⬜ Move the personal rules into ~/.claude/rules/, which applies to every project on this machine.
⬜ Add paths frontmatter to each linked rule so it loads when matching files are opened.
⬜ Keep the dotfiles folder and pass it with –add-dir in every session.

A team changes its extraction prompt each time a customer reports a bad record. Each fix solves that record, but a week later an older problem often returns. How should the team change its process?

⬜ Add each reported document as a new few-shot example and deploy once it extracts correctly.
⬜ Keep about 30 labeled documents that include past failures, and rerun all of them after each prompt change.
⬜ Add reported documents to a regression set but rerun only the newest one after each change.
⬜ Collect reports for a month, then make one comprehensive prompt revision.

An engineer’s ~/.claude/rules/style.md says to prefer early returns, while the project’s .claude/rules/style.md requires single-exit functions in the payments module. In payments code Claude sometimes follows one rule and sometimes the other. What should she do?

⬜ Make the two rules consistent, for example by excluding the payments module from her personal early-return rule.
⬜ Nothing; project rules load after user rules, so Claude settles on the project rule.
⬜ Rename her rule file so it sorts after the project file.
⬜ Move her preference into ~/.claude/CLAUDE.md, which takes priority over project rules.

On each push, a review job reviews only the newest commit. A pull request’s first commit changed a function’s return type and its third commit changed a caller, and the mismatch was never flagged. What should the job review on each push?

⬜ The newest commit plus the previous commit’s diff as context.
⬜ The complete diff of the pull request branch against its base, recomputed on every push.
⬜ Every commit separately in parallel, then merge the findings.
⬜ The newest commit only, plus a nightly full-repository review.

A review job needs 40 lines of CI-only instructions, such as the JSON comment format. The team added them to the project CLAUDE.md, and now engineers’ interactive sessions sometimes reply in that JSON format. Where should the CI-only instructions go?

⬜ In a .claude/rules/ file scoped to the CI configuration folder.
⬜ In CLAUDE.local.md at the repository root, which only CI reads.
⬜ In the shared CLAUDE.md under a heading saying it applies only in the pipeline.
⬜ In a separate file the job passes with –append-system-prompt-file, outside the project CLAUDE.md.

A team’s release-notes skill has a 900-line SKILL.md that includes three templates and a formatting script pasted inline. Every invocation loads all of it, though most runs need one template. How should the skill be organized?

⬜ Split it into four skills, one per template and one for the script.
⬜ Move the templates and script into the top-level CLAUDE.md.
⬜ Delete the templates and have Claude reconstruct them from memory.
⬜ Keep concise steps in SKILL.md, and store the templates and the script as separate files in the skill folder.

A newly acquired gift-card service has no CLAUDE.md, and every Claude Code session spends its first few minutes rediscovering build commands, test commands and the folder layout. Which two steps fit? (select two)

⬜ Run /init in the repository so Claude Code analyzes the codebase and generates a starter CLAUDE.md.
⬜ Review the generated file, fix wrong commands, remove generic advice and commit it for the team.
⬜ Run /init in each engineer’s home folder so personal sessions share the generated file.
⬜ Commit a README section with the commands and layout, which Claude Code reads at startup.

Two engineers each ask Claude to build the same price formatter, one for the web store and one for the mobile API, from the same one-page spec. The two versions round half-cents and format negatives differently. What keeps them consistent?

⬜ A precise table of rounding and negative-number rules in both prompts, without tests.
⬜ Ask Claude to compare the two and merge them into one version.
⬜ Have one engineer generate both in a single session.
⬜ A shared test suite of inputs and expected outputs that both implementations must pass.

An online bookstore wants product pages rendered on the server for search engines. It could adopt a new framework, pre-render pages at build time or add a rendering service, and each touches routing, caching and deployment. Which two steps fit? (select two)

⬜ Start in plan mode, have Claude read only the routing code, and pick the smallest diff.
⬜ Start in plan mode and have Claude explore the routing, caching and deployment code before comparing the three approaches.
⬜ Start in plan mode, then let Claude implement whichever approach it prefers without a comparison.
⬜ Choose one approach from Claude’s trade-off comparison, then implement it in steps, reviewing each change before the next.

An engineer keeps personal preferences, such as terse commit messages and her preferred test-runner flags, in a CLAUDE.local.md in each of the 14 repositories she works in, and the copies have drifted apart. Where should the preferences live?

⬜ In each repository’s committed CLAUDE.md under a personal section.
⬜ In a team rule file in each repository, scoped to the files she edits.
⬜ In ~/.claude/CLAUDE.md, which applies to every project on her machine and isn’t shared with the team.
⬜ In ~/.claude/settings.json under an instructions key.

A team’s db-migration skill has the description “Migration helper.” When engineers ask Claude to add a column to the appointments table, it writes raw SQL and never loads the skill, though invoking /db-migration by hand works. What should change?

⬜ Set disable-model-invocation: true so it stays out of the way until invoked by name.
⬜ Set user-invocable: false so Claude treats it as background knowledge.
⬜ Rewrite the description to say what the skill does and which kinds of request should trigger it.
⬜ Rename the skill folder to add-column to match the engineers’ wording.

Claude is renaming a claims field across a monorepo in direct execution. Five files in, the engineer sees it also changing an unrelated field with a similar name in the payments service. What should she do?

⬜ Let it finish, then /rewind to the start and repeat with a more precise prompt.
⬜ Press Esc to stop Claude, have it revert the payments-service edits, then name the field to leave alone and let it continue.
⬜ Press Esc twice to open the rewind menu, restore only the conversation and repeat the request.
⬜ Let it continue and add a PreToolUse hook blocking edits in the payments service.

An engineer knows exactly how to fix a deprecated logging call in 12 services: the replacement is mechanical and the tests cover it. Approving each of the 12 edits one by one is slowing her down. What should she do?

⬜ Switch to acceptEdits mode for this mechanical change and review the complete diff before committing.
⬜ Use plan mode first so Claude plans all 12 edits before she approves each one.
⬜ Switch to bypassPermissions for the rest of the session.
⬜ Have Claude write a sed script and run it herself outside Claude Code.

---

Domain 4: Prompt Engineering and Structured Output (20%)

An extraction pipeline uses a client-executed lookup_vendor tool: Claude calls it mid-extraction and your code returns the result. You want the Message Batches API discount, and results are due 30 hours after submission. Which redesign meets both requirements?

⬜ Force lookup_vendor with tool_choice so each batch request completes the lookup in a single pass.
⬜ Submit the batch, execute the returned lookup_vendor calls, then submit a second batch with the tool results.
⬜ Keep lookup_vendor in each request; the batch worker runs the tool in its server-side loop.
⬜ Run the vendor lookup before submission and include its data in each batch request, removing the mid-request tool call.

Invoices in an extraction pipeline carry an issue date, a delivery date and a due date. Strict tool use makes every extraction schema-valid, but invoice_date often gets the wrong date, and detailed written selection rules haven’t fixed it. Which prompt change is most effective?

⬜ Add 3 to 5 examples of multi-date invoices, each showing the chosen date with a short rationale for rejecting the others.
⬜ Add a required schema field, before the date fields, where the model records its full step-by-step reasoning.
⬜ Rewrite the selection rules with stronger wording and mark the invoice_date rule as IMPORTANT.
⬜ Add 3 to 5 diverse examples, each showing a complete, correctly formatted extraction from a different layout.

Some shipment manifests contain real data-entry errors: the declared total weight doesn’t equal the sum of the package weights. The downstream customs system must know which extractions came from internally inconsistent manifests. Which design achieves this?

⬜ Tell the model to report the sum of the package weights as the total whenever the declared weight disagrees.
⬜ Extract declared_weight from the manifest and computed_weight summed from the packages, with a weight_mismatch boolean set when they differ.
⬜ Retry each mismatched extraction with the manifest, the failed output and the discrepancy so the model corrects the value.
⬜ Tighten the JSON schema with stricter numeric types and required fields so mismatched extractions fail validation.

An extraction pipeline flags documents for human review in four categories. The duplicate-line-item category runs at 60% false positives; the other three are above 90% precision. Reviewers now dismiss every flag unread, including real total mismatches. What is the right response?

⬜ Attach the model’s self-rated confidence to each flag so reviewers can triage before investigating.
⬜ Keep all four categories live and add few-shot examples to the duplicate-line-item prompt over the next few sprints.
⬜ Turn off the duplicate-line-item category until its criteria are rewritten, and keep the other categories live.
⬜ Raise the reporting threshold across all four categories to lower the overall false-positive rate.

Your extraction requests force tool_choice to {“type”: “tool”, “name”: “extract_metadata”} on a model that supports forced tool use. The prompt also asks Claude to explain ambiguous fields in text before the tool call, but no text block ever appears. How should you capture the explanation?

⬜ Set tool_choice to auto and keep the instruction to explain in text before calling the tool.
⬜ Add an ambiguity_notes field to the extract_metadata input schema and read the explanation from the tool input.
⬜ Move the explanation instruction into the system prompt and mark it as a strict requirement.
⬜ Enable manual extended thinking so the model’s reasoning appears in thinking blocks.

An extraction team has two workloads: a nightly run over thousands of archived documents that must be done by morning, and an on-demand flow where an analyst uploads one document and waits for the result. Which two actions are correct? (select two)

⬜ Send the nightly archive run through the Message Batches API and match results to documents by custom_id.
⬜ Move the on-demand flow to the Message Batches API and poll the batch status every few seconds.
⬜ Keep the on-demand flow on synchronous Messages API calls.
⬜ Split the nightly run into many small batches to get a one-hour completion window for each batch.

An extraction prompt wraps each document in XML tags with source metadata and gives prose rules for normalizing informal amounts. The schema has normalized_amount, original_text and precision fields, and extractions pass validation. Still, the model invents precise amounts for informal measurements and misattributes sources when documents switch between inline citations and bibliography-style references. Which two prompt changes reduce these errors most directly? (select two)

⬜ Add contrasting examples that extract the same fact from an inline-citation document and from a bibliography-style document.
⬜ Expand the prose normalization rules with stricter boundaries for when to output an approximate value.
⬜ Add examples that convert informal amounts to approximate normalized values and fill the original_text and precision fields.
⬜ Wrap each document in XML document tags with source metadata so the model can tie each fact to its origin.

A team extracts contract terms with tool use and a JSON schema, and parsing failures are gone. Some extractions put the effective date after the termination date, or swap the customer and vendor names. What should the team add?

⬜ Semantic validation in code, such as checking that the effective date comes before the termination date, with a retry that includes the errors.
⬜ Run every extraction twice and accept a result only when both runs return the same values.
⬜ Strict regex date patterns on every date field and enum constraints on each party role field.
⬜ Force the extraction tool with tool_choice on every request so the schema applies to each contract.

A CI review job uses a report_findings tool with tool_choice “auto” and parses response.content[0] as the findings. Runs fail when a text block comes first. The text summary must still appear in the PR comment. How should extraction be fixed?

⬜ Set strict: true on the tool definition so the tool_use block is always the first content block.
⬜ Add a prompt rule that forbids any text before the tool call and keep parsing response.content[0].
⬜ Force tool_choice to report_findings so the response starts with the tool call.
⬜ Select the content block whose type is tool_use and read the findings from its input field.

Developers dismiss about 40% of a reviewer’s posted findings with one click and rarely say why. You want to learn which code constructs trigger the dismissed findings without adding work for developers. What should you change?

⬜ Add a detected_pattern field to each finding’s schema that records the construct that triggered it.
⬜ Route each finding through a second independent Claude instance before it is posted.
⬜ Add few-shot examples to the review prompt that contrast dismissed findings with real issues.
⬜ Require developers to pick a dismissal reason from a fixed list each time they close a finding.

A team wrote a brand-new audit prompt and plans one Message Batches API run across 12,000 source files. They want to avoid paying for repeated large runs. What should they do before submitting?

⬜ Define the audit output as a tool with a strict JSON schema so malformed responses can’t happen.
⬜ Submit the full batch now, then use custom_id to find failures and resubmit only those with a corrected prompt.
⬜ Run the prompt synchronously on a representative sample of files, refine it, then submit the full batch.
⬜ Split the files into several smaller batches and review each batch’s results before submitting the next.

A review findings schema uses a category enum: bug, security, performance, style. Merge gates route each finding by its category. Reviews keep producing issue types that fit no category, so the model forces the closest match. Which schema change handles this best?

⬜ Add an “other” value to the category enum, paired with a string field describing the issue.
⬜ Make the category field optional so the model can leave it out when nothing fits.
⬜ Add a new enum value to the schema each time an uncategorized issue type appears.
⬜ Replace the enum with a free-text string so the model can name any category.

An automated reviewer posts findings in two categories, security and correctness, each above 90% precision, and developers act on almost every finding. The team wants to add an untested deprecated-API category. The PR interface shows every finding the same way, with no labels or confidence and no way to filter categories. How should the team introduce it?

⬜ Enable it in production now but label its findings experimental so developers judge them separately.
⬜ Add “only report high-confidence deprecations” to its prompt, then enable it with the others.
⬜ Run the new category offline on recent merged pull requests, measure its false-positive rate and enable it only once precision is acceptable.
⬜ Enable it in production with a self-rated confidence on each finding so developers can skip low ones.

Before the first nightly batch, a team will refine its test-generation prompt on a sample, scoring many prompt versions a day. The sample scores must predict full-run quality. Which two practices are correct? (select two)

⬜ Have a senior engineer hand-grade every sample output in each round before the next version.
⬜ Score each round with automated checks, such as code-based validation of the generated tests.
⬜ Choose sample pull requests that mirror the real mix of change types and include known edge cases.
⬜ Build the sample only from pull requests where earlier versions produced duplicate or wrong tests.

A review step defines a report_findings tool with an input_schema. Claude calls it every run, but the input sometimes gives severity as the string “2” instead of the integer 2, or leaves out a required field, and the parser fails. Which change guarantees the tool input matches the schema?

⬜ Set tool_choice to {“type”: “tool”, “name”: “report_findings”} to force the call.
⬜ Add input_examples to the tool definition showing correctly typed findings.
⬜ Validate each input in code and retry with the type errors included.
⬜ Add “strict”: true to the report_findings tool definition.

A nightly Message Batches job generates test cases with one request per changed file. Results arrive out of submission order, and some requests fail with errors instead of output. How should the pipeline link each result to its source file?

⬜ Match each result line to the request at the same position in the submitted array.
⬜ Have the model include the source file path in its JSON output and match on that.
⬜ Give each request a unique custom_id that identifies its file, and read that ID from each result line.
⬜ Poll the batch endpoint with each custom_id to fetch that request’s status and output one by one.

A team added four few-shot examples to its review prompt, each flagging a hardcoded value. Findings are now consistently formatted, but the reviewer also flags named constants that the prose rules explicitly allow. What revision is most effective?

⬜ Replace two examples with allowed hardcoded values, each with a short reason it isn’t flagged.
⬜ Remove the examples and rely on the prose rules alone.
⬜ Move the prose exemptions to the top of the prompt and mark them IMPORTANT.
⬜ Add four more examples flagging other kinds of hardcoded values.

A weekly dependency-license audit runs on the Message Batches API for its 50% saving, and compliance needs the report within 30 hours of each code freeze. How should the team schedule the batch?

⬜ Move the audit to the synchronous Messages API so completion time is predictable.
⬜ Submit at any point in the 30-hour window, since most batches finish within an hour.
⬜ Cancel and resubmit the batch if it hasn’t finished within an hour of submission.
⬜ Submit the audit batch no later than 6 hours after the code freeze.

A job extracts dependency updates from PR descriptions using a tool’s JSON schema, and each prompt already includes the PR’s creation date and timezone. Extractions validate, but dates and versions keep their source formats, including relative dates like “last Tuesday”. New styles appear weekly, and deduplication needs a canonical format. What should you change?

⬜ Add stricter string constraints, such as length limits, so non-canonical values are rejected.
⬜ Add a post-processing step that rewrites dates and versions into canonical form with regular expressions.
⬜ Add normalization rules to the prompt: dates as ISO 8601 (YYYY-MM-DD) and versions as MAJOR.MINOR.PATCH without prefixes.
⬜ Add few-shot examples covering every date and version style the team has seen.

A release-notes pipeline extracts entries from each merged PR with a validation-retry loop. Date format errors clear after one retry, but ticket_summary fails every retry because the ticket text exists only in the issue tracker, not in the diff. Release notes must include ticket summaries. What should you change?

⬜ Fetch the linked ticket text from the issue tracker and add it to the extraction context.
⬜ Make ticket_summary nullable so a retry can return null when the diff lacks the text.
⬜ Raise the retry limit and include the diff, the failed extraction and the errors in each retry.
⬜ Define the extraction as a tool with a JSON schema so ticket_summary always arrives valid.

A nightly test-generation batch defines a client-executed read_fixtures tool in each request. When you retrieve the results, many requests succeeded but ended with stop_reason tool_use and contain tool_use blocks instead of finished suggestions. How should the pipeline handle them?

⬜ Remove read_fixtures from every request and resubmit the batch without tool use.
⬜ Keep polling the batch until the worker runs the tool and final suggestions appear.
⬜ Run each requested tool, then send a follow-up request containing the assistant content and the tool_result.
⬜ Match these results by custom_id and resubmit the identical requests in a new batch.

A review prompt tells Claude to “flag an issue only when you are certain it is real.” Findings already follow the required format, but harmless comment wording is still reported as a bug, and the same code is flagged in some runs and not others. Which change improves precision most?

⬜ Run each review twice and report only findings that appear in both runs.
⬜ Add few-shot examples showing the required format: location, issue, severity and fix.
⬜ Have the model attach a confidence score to each finding and filter out those below 0.8.
⬜ Replace the certainty instruction with named rules for which comment issues to flag and which to skip.

Extractions from a system always pass JSON Schema validation, but buyer and seller names sometimes end up in each other’s fields. A self-review instruction in the extraction prompt rarely changes anything. Which design catches these subtle errors best?

⬜ Enable extended thinking for the extraction so the model deliberates longer.
⬜ Add a retry loop that sends JSON Schema errors back with the document for correction.
⬜ Send the document and the finished extraction to a second Claude instance with no prior context for verification.
⬜ Send a follow-up in the same conversation asking Claude to re-check for swapped fields.

A pipeline runs document extraction on a model that supports both forced tool use and manual extended thinking. To improve accuracy, the team enables thinking: {“type”: “enabled”, “budget_tokens”: 10000} on requests that force tool_choice {“type”: “tool”, “name”: “extract_metadata”}. Every request now fails, and each document must still produce a structured extraction through a tool call. What should change?

⬜ Change tool_choice to {“type”: “auto”} and tell the prompt to always call extract_metadata.
⬜ Keep both settings and retry the failed requests with exponential backoff.
⬜ Remove the thinking parameter from these extraction requests and keep the forced tool_choice.
⬜ Change tool_choice to {“type”: “any”} so thinking can stay on.

A system extracts fields from 12-document loan packets in one pass over the whole packet. Some documents come back complete, others shallow or incomplete, and conflicting borrower addresses across documents go unflagged. How should the extraction be restructured?

⬜ Keep the single pass and add few-shot examples showing complete extraction for every document type.
⬜ Move to a model with a larger context window so one pass can attend to all twelve documents.
⬜ Extract each document in its own pass, then run a separate pass that compares values across documents and flags conflicts.
⬜ Run three extractions of the full packet and keep only values that at least two runs agree on.

An extraction schema’s category enum includes “Unclear” for ambiguous documents. The schema is shared with downstream systems and must not change. In a nightly batch, some correct classifications come back as “unclear” and fail validation, and retries with the error sometimes return the same lowercase value. What is the right fix?

⬜ Raise the retry budget until a correctly capitalized value comes back.
⬜ Rewrite every enum value in lowercase so the output matches.
⬜ Compare the returned category with the enum values case-insensitively in the validation step.
⬜ Add a prompt instruction requiring the exact capitalization from the schema.

A pipeline extracts ticket_id from each PR description. The schema allows null and the prompt says to return null when no ticket is referenced, but all three few-shot examples show a ticket. On PRs without a ticket, the model invents a plausible ID that passes validation. What addresses the fabrication most directly?

⬜ Define the extraction as a tool with the ticket schema and read ticket_id from the tool_use block.
⬜ Add a few-shot example where the description has no ticket and the output sets ticket_id to null.
⬜ Repeat the null rule at the end of the prompt and mark it IMPORTANT.
⬜ Add more examples with varied real ticket ID formats.

A nightly extraction pulls stated_total from each test log’s summary line, calculated_total from the per-suite counts, and a conflict_detected flag. Several runs set the flag, and spot checks show the extraction is faithful: the log itself is inconsistent because of a reporter bug. How should the pipeline handle these runs?

⬜ Tell Claude to reconcile the two counts and report one consistent total.
⬜ Retry with the failed output and the two totals included as error feedback.
⬜ Route runs with conflict_detected set to a separate review path instead of re-extracting.
⬜ Replace stated_total with calculated_total before the summary reaches dashboards.

A findings schema marks affected_test_file as a required string naming the test that covers the flagged code. Some changed modules have no tests yet, and Claude fills the field with plausible paths to nonexistent files, which PR comments then link to. Which change prevents the fabricated paths?

⬜ Check each path against the repository and retry with the validation error.
⬜ Add a prompt instruction to name only test files that exist.
⬜ Add few-shot examples contrasting findings from tested and untested modules.
⬜ Allow null for affected_test_file and remove it from the schema’s required list.

A nightly test-generation batch for 3,000 files ends with 150 errored results. Most show invalid_request_error with “prompt is too long”; the rest are server errors. What is the correct resubmission workflow?

⬜ Find the failed files by custom_id and resubmit all of them unchanged in a new batch.
⬜ Send the oversized files unchanged through the synchronous Messages API.
⬜ Resubmit only the failed requests with a higher max_tokens on each so longer inputs fit.
⬜ Find the failed files by custom_id, chunk the oversized ones and resubmit only those requests in a new batch.

A findings schema already records detected_pattern. A month of dismissal data shows one construct causes 70% of dismissals: guard clauses with early returns, flagged as missing error handling. Other correctness findings are rarely dismissed and catch real bugs. What is the most effective fix?

⬜ Disable the correctness category and re-enable it after its prompts are rewritten and tested.
⬜ Add a general instruction to be more conservative and report only high-confidence findings.
⬜ Add an explicit rule that guard clauses with early returns aren’t reportable as missing error handling.
⬜ Add a self-reported confidence score to every finding so developers can triage.

A review step outputs findings as JSON that your code validates with Pydantic. One run is rejected because two findings cite line numbers that don’t exist in the PR diff. How should you build the retry?

⬜ Turn the two rejected findings into contrastive examples and re-run the whole review.
⬜ Send the PR diff, the rejected findings and the exact validation errors, and ask for a corrected output.
⬜ Send only the rejected findings with the errors, and ask the model to fix the line numbers.
⬜ Send the rejected findings, the errors and only the diff hunks those findings cite.

After sample refinement met the quality target, an engineer restructured each batch request to add a tool definition for structured findings. The nightly batch then ended with every request errored for invalid params. What should the team do before resubmitting?

⬜ Repeat the sample refinement loop to raise first-pass quality.
⬜ Add strict: true to the tool definition so the API enforces the schema.
⬜ Split the corpus into smaller batches so a failure affects fewer requests.
⬜ Send a few of the restructured requests through the synchronous Messages API before submitting the full batch.

An automated review emits each finding through tool use with an input_schema. Every finding parses and severity is always a valid enum value, but developers report that minor issues are often labeled critical. What addresses this?

⬜ Add explicit severity criteria to the review prompt, with an example issue for each level.
⬜ Enable strict mode (strict: true) on the findings tool.
⬜ Add a retry step that resends each finding with its schema errors.
⬜ Set the sampling temperature to zero.

On contracts longer than 20,000 tokens, the model invents clause details that the source contradicts, while shorter documents extract accurately. More few-shot examples didn’t change the error rate. Which change reduces these fabrications most directly?

⬜ Rebuild the example set with ten examples from full-length production contracts.
⬜ Make every clause field nullable so the model can return null.
⬜ Set the sampling temperature to zero.
⬜ Ask the model to extract word-for-word quotes for each field first, then fill the schema from those quotes.

Invoices contain an order date, a ship date and a due date. The extraction prompt says only “extract the invoice date.” Extractions pass validation, but different runs put a different one of these dates in invoice_date for the same invoice. Which change fixes this most reliably?

⬜ Add a rule naming the exact label that maps to invoice_date, plus a fallback for invoices without that label.
⬜ Add a validation-retry loop that sends schema errors back for correction.
⬜ Have a second Claude instance review each extraction and replace any wrong date.
⬜ Add three few-shot examples showing the exact JSON structure to return.

An extraction schema has stated_total, calculated_total and a conflict_detected boolean. An audit finds records where the two totals differ but conflict_detected is false. Downstream systems filter on this flag alone and must never receive a wrong flag. What is the right fix?

⬜ Retry with a prompt that quotes the two totals and the wrong flag value.
⬜ Add few-shot examples that set the flag whenever the two totals differ.
⬜ Make conflict_detected a required, strictly typed boolean in the schema.
⬜ Compare the two totals in validation code after each extraction and overwrite conflict_detected with the result.

Extractions from a tool_use pipeline always pass validation, but the same information lands in different fields across documents with inline citations, narrative text and tables. Detailed instructions haven’t fixed this. Which two changes address the inconsistency best? (select two)

⬜ Enable strict tool use with strict: true so inputs are validated against the schema.
⬜ Wrap each example in dedicated example XML tags so the model can tell examples from instructions.
⬜ Retry each inconsistent extraction with the previous output and the validation error.
⬜ Add 3 to 5 examples drawn from the real document structures, covering each structure type.

A review step defines three finding tools, one per issue category, and the right category varies per pull request. tool_choice is {“type”: “any”} on a model that supports forced tool use. Some responses contain two tool_use blocks, and some tool inputs miss a required field. The parser needs exactly one schema-conformant tool call per response. Which two changes fix these problems? (select two)

⬜ Add disable_parallel_tool_use: true inside the tool_choice object.
⬜ Add a system prompt rule that Claude must call one tool and fill every required field.
⬜ Set strict: true on each of the three tool definitions.
⬜ Change tool_choice to force one named finding tool on every review.

A review step reports a per-PR summary through a tool call. One integer field counts affected API endpoints, which means tracing calls across several files. Every response matches the schema, but the count is often wrong, and cost rules allow one model call per PR. What improves the count’s accuracy?

⬜ Tell Claude to trace and count the affected endpoints in text before it makes the tool call.
⬜ Run a second independent Claude instance to re-derive the count and flag disagreements.
⬜ Set strict: true on the tool definition.
⬜ Add minimum and maximum bounds to the count field.

An extraction schema’s category enum includes “unclear” for ambiguous documents. Every extraction passes validation, but the model almost never returns “unclear” and assigns a best-fit label even to documents reviewers judge genuinely ambiguous. What fixes this most directly?

⬜ Add a validation retry that resends the document with the errors from the failed extraction.
⬜ Make the category field nullable so the model can return null.
⬜ Set strict: true on the extraction tool.
⬜ Describe when to choose “unclear” in the field description and the prompt, giving the model explicit permission to be uncertain.

Reviewers now dismiss an extraction system’s flags unread, including flags that catch real total mismatches. The dashboard shows 85% overall flag precision, and the team can’t agree which flag type is to blame. What should you do first?

⬜ Attach a self-rated confidence score to every flag.
⬜ Tighten the criteria uniformly across all categories.
⬜ Label a recent sample of flags and measure precision separately for each flag category.
⬜ Add few-shot examples of correct flags and non-flags for every category.

A contract extraction pipeline defines an extraction tool whose input_schema is the output format, with strict: true. The team is trimming its validation code. Which two checks must stay? (select two)

⬜ A check that each extracted party name appears in the source document text.
⬜ A repair step that fixes unclosed braces and trailing commas before parsing.
⬜ A check that flags extractions where end_date is earlier than start_date.
⬜ A check that every required field is present with the schema’s declared type.

A nightly Message Batch extracts data from thousands of documents, each identified by a file path that contains slashes. Which two design choices map each result back to its source document correctly? (select two)

⬜ Poll the batch by its Message Batch ID, then match each .jsonl result line to its document by custom_id.
⬜ Convert each file path into an ID using only letters, digits, hyphens and underscores, and use it as the custom_id.
⬜ Read the .jsonl results in order and match each line by its position in the submitted array.
⬜ Use each document’s raw file path as its custom_id and look results up by path.

An extraction tool runs with strict tool use, so its inputs always match the schema’s types and required fields. Downstream systems also need a non-negative amount and a nine-character tax_id. Which approach guarantees these two rules?

⬜ State the range and length rules as normalization instructions in the system prompt.
⬜ Add few-shot examples with a non-negative amount and a nine-character tax_id.
⬜ Keep the strict schema as is and check the range and length rules in code after parsing.
⬜ Add minimum to amount and minLength and maxLength to tax_id in the strict input_schema.

A support agent tags every issue a message raises, for routing. The prompt has three single-issue few-shot examples. Formatting is now consistent, but when a customer reports a late delivery and a double charge together, only the first issue is tagged. What fixes this?

⬜ Remove the examples and describe the tagging rules in prose, keeping the format instructions.
⬜ Add a sentence saying some messages raise several issues and each needs its own tag.
⬜ Replace them with varied examples, including messages with two or three issues that are each fully tagged.
⬜ Add examples of the other issue types, showing the full set of tags the model may use.

A support agent records a refund amount from phrases like “$12”, “12 bucks” and “twelve fifty” before calling process_refund. The API requires whole-number cents, but the record holds a string. Which change makes the handoff reliable?

⬜ Normalize the phrase in application code, reject ambiguous amounts, and validate an integer cents field before calling process_refund.
⬜ Change the record to integer cents and let Claude interpret each phrase with its own judgment.
⬜ Keep a string field with a dollar regex and rely on strict mode to convert matching values to cents.
⬜ Keep the string and teach process_refund to parse spoken amounts while keeping its current contract.

Three independent reviewer instances check each refactor, and a finding is posted only when two report it. An audit of last month’s discarded single-reviewer findings turned up a SQL injection, a race condition and a data-loss bug. What change fits best?

⬜ Post single-reviewer findings only in the security category and keep two-of-three for the rest.
⬜ Add a fourth reviewer and keep the majority rule.
⬜ Post every finding any reviewer reports, labeled with how many of the three flagged it.
⬜ Keep two-of-three and give the reviewers a shared checklist to raise agreement.

In one Claude Code session, Claude writes a patch and then declares it correct. The team wants a cheap check in the same session before an independent review runs later, and test and lint commands exist. What is most useful?

⬜ Ask Claude to check the diff against the acceptance criteria and list any unmet requirement.
⬜ Run the relevant tests and lint in the same session and report their actual output with the list of changed files.
⬜ Ask Claude to rate its confidence in each changed file and flag any below 7.
⬜ Ask for a second, more skeptical written critique of the patch.

A test-writing job creates tests from the changed code, and a second Claude instance reviews them by reading the same code. Both approved a pull request with wrong discount rounding: the tests assert exactly what the code does. What should the reviewer check the tests against?

⬜ Property-based tests generated from the changed code.
⬜ The changed code again, with a checklist of common rounding mistakes.
⬜ A mutation test run that rejects tests that miss code changes.
⬜ The ticket’s acceptance criteria, confirming each rule has a test that checks its stated result.

A separate verifier instance checks each research report before release but receives only the report text. Spot checks find approved reports whose cited sources don’t say what the report claims. Which two changes make the verifier effective? (select two)

⬜ Run three verifiers on the report text and release only when two approve.
⬜ Give the verifier the cited excerpt for each claim, placed right next to that claim.
⬜ Have the writing subagent re-check its own citations in the same session.
⬜ Ask for a verdict on each claim, supported or not supported, quoting the exact source line it relied on.

A reviewer posts several “critical” findings a week, such as possible null dereferences. About half turn out to be wrong, and developers now argue with every critical label. What should the team require?

⬜ A confidence score, posting critical findings only above 0.8.
⬜ A second reviewer, posting critical findings only when both report them.
⬜ A failing test or command output attached to each critical finding, showing the problem actually occurs.
⬜ A lower severity label for every finding.

Many review comments land on files nobody edits by hand, and on spacing problems another CI step already fails the build for. Developers now dismiss whole reviews unread. What change to the review prompt fits best?

⬜ Report only findings the reviewer is highly confident about.
⬜ Cap each review at ten comments ordered by severity.
⬜ Comment only on changed lines and ignore everything else.
⬜ List what not to review: generated code, lockfiles and anything existing CI checks already enforce.

A team keeps Message Batches results in the API and downloads each month’s results for audit at month end. Results for a batch created 35 days earlier could not be downloaded. What should change?

⬜ Download from the results URL saved when the batch was created.
⬜ Download and store each batch’s results when it ends, within the 29 days the API keeps them.
⬜ Resubmit the batch to regenerate its results before the audit.
⬜ Set a longer results retention period when creating each batch.

After a new schema version was deployed, every extraction request fails with a 400 invalid_request_error pointing at an unsupported schema keyword. The retry logic retries each request five times with backoff, and the queue is backing up. What should change?

⬜ Switch to plain prompting with the schema in the prompt to keep the queue moving.
⬜ Stop retrying these errors right away, alert the team and fix the schema.
⬜ Keep retrying but cap retries at two per request.
⬜ Send failures to a dead-letter queue and retry them hourly until the fix ships.

A Message Batch of 10,000 extraction requests has ended: 9,812 succeeded, 150 errored and 38 expired. Results come back in a different order from submission. What should the job do next?

⬜ Resubmit the 188 failed requests in their original order.
⬜ Match results by custom_id and resubmit the errored and expired requests.
⬜ Match results by custom_id and resubmit only the errored requests.
⬜ Match results by line number and resubmit the errored and expired rows.

Some scans fail extraction again and again because pages are unreadable, and the retry loop keeps resending the same document, so the job never finishes. Which two controls make recovery safe? (select two)

⬜ Retry with backoff and sharper scan rendering until one response passes validation.
⬜ Limit each document to three logged extraction attempts, stopping automatic retries when the budget is used up.
⬜ Send unresolved documents to human review with the scan, earlier outputs and each attempt’s validation errors.
⬜ After three failures, mark the job complete and drop the document without review.

A team moves extraction to the Message Batches API. To save tokens, only the first request carries the long field definitions; the other 4,999 say “Apply the same instructions to this document,” and most of those results are poor. What explains this, and what is the fix?

⬜ Batch requests share one system prompt; put the definitions once in a batch-level system field.
⬜ Each request is processed independently; include the complete definitions in each one and use prompt caching to cut the cost.
⬜ Batches discard system prompts; move the definitions into the first request’s user message.
⬜ Requests share a cache, not a conversation; set cache_control on the first request so others reuse it.

When an invoice has no tax ID, the extractor can call lookup_vendor_tax_id or mark the field absent. The rule: look it up for registered companies, mark it absent for private sellers. Claude switches between the two paths at random. Which prompt change helps most?

⬜ Add one example per seller type showing the source excerpt, its lookup_vendor_tax_id call (if any) and the final JSON.
⬜ Add completed JSON examples for both seller types without the tool calls.
⬜ Say “use when needed” in the tool description and let Claude decide.
⬜ Force lookup_vendor_tax_id on every invoice and discard the result for private sellers.

A report writer says a new clinic cut emergency visits by 20%. A reviewer subagent marks it unsupported, and the writer points to a passage that may support a narrower claim. The statement will shape a funding vote. What should the coordinator do?

⬜ Keep the writer’s version once a person confirms the passage exists.
⬜ Run a third reviewer and publish whichever reading two of three support.
⬜ Escalate the claim, the passage and both reviews to a human analyst for a final ruling.
⬜ Publish the narrower claim and note that the reviewer disputed the 20% figure.

Two reviewer subagents check each weekly report with the same instruction, “review for quality.” Their comments overlap while real problems go unnoticed. One is strong at source provenance, the other at spotting claims that go beyond the evidence. How should they be set up?

⬜ Give one a provenance checklist (source exists, publication date, primary or secondary) and the other a claim-strength checklist, then merge their findings.
⬜ Have the second reviewer read the first one’s comments and focus where the first raised doubts.
⬜ Give both the same full checklist and keep only findings both report.
⬜ Have both score each section from 1 to 5 and escalate sections with the biggest gap.

A research document subagent analyzes each of 30 sources in its own pass, then runs a final integration pass over all 30 full texts again. That pass often hits the context limit and repeats per-source findings instead of comparing sources. What should the integration pass receive and do?

⬜ All 30 full texts again in three batches of ten, summarizing each batch separately.
⬜ The same 30 full texts, with instructions to skip findings already reported.
⬜ Only the per-source findings, with instructions to find cross-source issues such as contradictions, duplicates and coverage gaps.
⬜ Only the per-source findings, with instructions to rank them and merge them into one list.

A verification subagent marks every claim in a report pass or fail, and editors get about 200 failures a week. Most are minor wording issues, but a few are unsupported figures that must never ship. How should the verification output change?

⬜ Report only failures the subagent considers important and drop minor ones.
⬜ Attach a severity and a confidence score to each failure, sending unsupported figures straight to editors and batching wording issues.
⬜ Keep pass or fail and have a second subagent re-check every failure first.
⬜ Replace per-claim results with one quality score per report.

A test-generation job validates its JSON output. Four failures recur: owner is empty because the repository has no CODEOWNERS entry; test paths use backslashes; ticket_id is empty because the PR names no ticket; coverage_delta doesn’t match the numbers in the prompt. Which two would a retry with the error attached likely fix? (select two)

⬜ The empty owner, where no CODEOWNERS entry covers the changed files.
⬜ The empty ticket_id, where the description names no ticket.
⬜ The test paths written with backslashes instead of the forward slashes the schema requires.
⬜ The coverage_delta that doesn’t match the before and after figures in the prompt.

A review prompt says: “Do not comment on logging.” Claude now skips missing audit logs in payment code, which security requires, and ignores log lines that expose card numbers. Which two prompt changes fit? (select two)

⬜ Explain the reason: logging style is already enforced by a linter, so style comments only add noise.
⬜ Repeat the instruction in capitals at the start and end of the prompt.
⬜ State the exceptions: always report logging that exposes sensitive customer data or misses a required audit event.
⬜ Remove the instruction and let Claude comment on any logging issue.

A CI step sends Claude one report per run, with one extraction tool each for JUnit, coverage and lint reports. On a model that supports forced tool use, the request forces the JUnit extractor, so coverage and lint reports come back empty. Most file names reveal the type accurately; some reveal nothing. What should the request set?

⬜ tool_choice any every time, plus a retry when the tool doesn’t match the file name.
⬜ tool_choice any every time, with the file name in the prompt as a hint.
⬜ Force the extractor the file name suggests, and the JUnit extractor when the name is unclear.
⬜ Force the matching extractor when the file name identifies the report, and any when it doesn’t.

A review job’s JSON schema requires at least one item in findings. For clean pull requests, Claude sometimes invents a minor finding and sometimes replies in prose, which breaks the parser. What should change?

⬜ Keep the schema and retry prose replies, asking for JSON.
⬜ Allow an empty findings array so a clean pull request returns valid JSON with no invented findings.
⬜ Keep the minimum and have the parser drop findings labeled minor.
⬜ Keep the schema and add an example where the single finding says no issues were found.

To stop invented values, a team made termination_date optional in its contract schema. Fabrication stopped, but the downstream loader now crashes on records where the key is missing entirely. What should the schema do?

⬜ Keep it optional and tell Claude to always include the key, set to null when absent.
⬜ Make termination_date required with a type of date string or null, so the key is always present.
⬜ Make it required as date string or null, defaulting to the signing date when the contract is silent.
⬜ Keep it optional and have the loader skip records without the key.

---

Domain 5: Context Management and Reliability (15%)

Midway through a research task, the requester writes: “A human analyst must take over now. Run no more searches and generate no new analysis.” Two planned searches would complete the topic, and the findings so far are stored as structured claim-source records. What should the coordinator do?

⬜ Pause the searches, but have the synthesis agent write a summary of existing findings before the transfer.
⬜ Transfer the task to a human analyst now, passing along the structured findings already collected.
⬜ Transfer now, but queue the two remaining searches so their results reach the analyst later.
⬜ Finish the two remaining searches first so the analyst receives a complete handoff package.

A research coordinator’s system prompt says only “escalate to the operator when uncertain.” In testing it escalates transient search failures that a retry would fix, and it silently picks one reading of ambiguous requests instead of asking. Which change fixes both behaviors most effectively?

⬜ Add a hook on escalate_to_operator calls that blocks escalations whose reason is a transient search failure.
⬜ Deploy a separate classifier model, trained on past runs, to decide which requests need the operator.
⬜ Add explicit escalation criteria to the system prompt with few-shot examples of cases to escalate and cases to handle autonomously.
⬜ Have the coordinator rate its confidence from 1 to 10 before each decision and escalate below a threshold.

A team’s triage assistant handles build-failure reports and can escalate to an on-call engineer. A developer writes: “This test broke my branch again, this is absurd.” The fix is routine and within the assistant’s scope. How should it respond?

⬜ Escalate to the on-call engineer with a structured handoff that includes the failure details and the message.
⬜ Score the message’s sentiment and escalate when frustration crosses a set threshold.
⬜ Acknowledge the frustration, apply the routine fix, and escalate only if the developer then asks for a human.
⬜ Acknowledge the frustration, then ask whether the developer wants the assistant’s fix or an on-call engineer first.

A CI review prompt asks Claude to attach a self-reported confidence value to each finding, and findings above 0.9 skip human review. Error rates within those skipped findings must stay measured per rule family as the codebase changes. Which design meets this need?

⬜ Each month, have humans review a random sample of skipped findings drawn from every rule family.
⬜ Each month, re-run the calibration checks on the labeled validation set and adjust the 0.9 threshold.
⬜ Each month, run a second independent Claude instance over the skipped findings and track disagreement per rule family.
⬜ Each month, have humans review every finding Claude marked low confidence, grouped by rule family.

A weekly report slash command outputs benchmark timings, an incident account and flagged code issues, all as bullet points. Reviewers can’t compare benchmarks across weeks, and the incident reads as fragments instead of a chronological story. Which prompt change fixes both complaints?

⬜ Add few-shot examples of past bullet-point reports so the format stays consistent each week.
⬜ Have the command render the benchmarks as a table, the incident as prose and the flagged issues as a structured list.
⬜ Use one section template that renders the benchmarks as a table and every other section as a structured list.
⬜ Switch the whole report to flowing prose so each section connects to the next.

During an unattended nightly audit, an analysis subagent finds that the vendor changelog and the team’s benchmark report give different latency figures for the same library release. The main session drafts the final report after all subagents finish. What should the subagent return?

⬜ Only the figure from the more recently published source, noting that the older one was superseded.
⬜ One consolidated figure computed as the midpoint of the two values.
⬜ Pause mid-analysis and ask the developer which source to trust before continuing.
⬜ Both figures with their sources, flagged as a conflict, so the main session can reconcile them before drafting.

Some documents report two credible figures for the same metric, from studies with different dates and methods. The output schema holds one value per field, so one figure is silently dropped. Analysts downstream need both figures with their source context. What is the best fix?

⬜ Tell the model to extract the figure from the most recent study and ignore older values.
⬜ Change the schema so a metric holds a list of values, each with source name, date and method, plus a conflict flag.
⬜ Add a validation retry that re-sends the document with the flagged field so the model corrects the value.
⬜ Add a field-level confidence score and send documents with two candidate values to human review for a final choice.

Downstream systems flag many extracted market-size figures as contradictory. An audit shows the differing values are all accurate: the source documents cover different reporting periods. Which change to the extraction system prevents this misinterpretation?

⬜ Send both extractions back to the model with a validation error so it corrects the disagreement.
⬜ Keep only one value per metric, using the figure from the document judged most recent.
⬜ Mark each pair of differing values as a conflict with source attribution and send it to a human reviewer.
⬜ Add a publication or data-collection date field to the extraction schema, nullable when the document gives none.

A parsing step in an extraction pipeline reports every failure as a generic ’extraction failed’ status, whether the PDF was corrupted or the request timed out. What should the parsing component return so the coordinator can decide whether to retry, split the document or skip it?

⬜ The failure type, any pages already extracted as partial results, and suggested alternative approaches.
⬜ Nothing until it has retried transient failures internally with exponential backoff; only persistent failures reach the coordinator.
⬜ The full raw parser logs attached to each error so the coordinator has complete diagnostic detail.
⬜ A success status with null extraction fields so downstream validation flags the document later.

During a debugging session, a developer tells Claude Code: “Find out why this test fails, but don’t change any files; I’ll make the fix myself.” Claude finds the cause, a one-character typo. What is the correct behavior?

⬜ Ask the developer whether the no-edit instruction still applies to a fix this small.
⬜ Report the root cause and show the suggested change as text, leaving every file untouched.
⬜ Enter plan mode, present the edit as a plan, and apply it after the developer approves.
⬜ Apply the one-line fix and show the diff so the developer can review it afterward.

A Claude Code session writes a pre-refactor assessment of a legacy module. The report states reproduced test failures and hedged guesses from old code comments with the same certainty. Uncertain items must stay visible so the team can investigate them. Which change fixes this?

⬜ Send the draft to a second independent Claude instance to verify each finding.
⬜ Add a self-critique pass where the agent removes any claim it can’t verify against the code.
⬜ Tell the agent to attach a confidence score from 1 to 10 to every finding.
⬜ Define report sections that separate verified findings from unconfirmed claims, keeping each source’s original wording.

Claude Code runs refactoring tasks autonomously after an engineer approves each plan in plan mode, and every change also goes through pull request review. Which two rules should trigger a mid-task handoff to an engineer? (select two)

⬜ Hand off when CLAUDE.md and the team’s conventions give no guidance on a design decision the task requires.
⬜ Hand off whenever Claude reports a self-rated confidence below the team’s autonomy threshold.
⬜ Hand off when repeated fix attempts leave the same test failing and each attempt adds no new information.
⬜ Hand off whenever the refactor turns out to touch more than ten files across several modules.

Senior engineers labeled 400 of Claude’s pull request reviews, including reviews that found no issues, across several languages and finding categories. Overall accuracy is 96%, and leadership wants to end mandatory human review. What should you check first?

⬜ Compare the 96% with the measured accuracy of human reviewers and proceed if Claude scores higher.
⬜ Have Claude rate its confidence on each review and skip human review above a threshold.
⬜ Break the 96% down by language and finding category and confirm that every segment performs consistently.
⬜ Grow the labeled set to 2,000 reviews to narrow the margin of error on the overall figure.

In production, a support agent’s lookup_order fails for three reasons: backend timeouts, badly formatted order numbers and order IDs that don’t exist. The MCP server returns “lookup failed” for all three, so the agent escalates almost every failure. What change enables correct recovery?

⬜ Map all three failures to one customer-facing message that the agent relays word for word.
⬜ Return an error category (transient, validation, not_found), an isRetryable flag and a suggested next step in each tool error.
⬜ Tell the agent in the system prompt to retry a failed lookup once, then ask the customer to re-enter the number.
⬜ Add retries with exponential backoff inside the MCP server and return failures only after they’re exhausted.

A customer asks a support agent to match a competitor’s lower advertised price. The pricing policy covers only adjustments for items discounted on the company’s own site and says nothing about competitor prices. How should the agent handle this?

⬜ Call escalate_to_human and hand the request to a person for review.
⬜ Decline, telling the customer the policy doesn’t allow competitor price matching.
⬜ Ask the customer for proof of the competitor’s price before deciding.
⬜ Offer the own-site price adjustment amount by applying the closest policy rule.

A long Claude Code session debugging an agent’s escalation logic is nearly out of context because of verbose discovery output. The developer must free context now, keep the refund-threshold findings and continue the same investigation. What should they do?

⬜ Delegate the rest of the investigation to a subagent so new output stays out of the main context.
⬜ Run /clear to reset the context, then restate the goal in a fresh conversation.
⬜ Run /autocompact with a lower token threshold so compaction happens sooner.
⬜ Run /compact with focus instructions telling the summary to keep the refund-threshold findings.

An extraction assistant can route cases to a human reviewer. A user reports a wrong invoice total, and the assistant offers a corrected re-extraction that would likely fix it. The user replies: “No, have a person check it.” What should the assistant do?

⬜ Acknowledge the frustration again and offer a side-by-side view of extracted and source values.
⬜ Escalate only if the message scores above a frustration threshold in sentiment analysis.
⬜ Run the re-extraction first, then escalate with the new result if the user is still unhappy.
⬜ Route the case to the human reviewer now, without running the re-extraction.

A synthesis report lists extracted revenue figures in the order the source documents were processed. Each figure carries its reporting period and source. Analysts compare exact quarterly values and say they can’t follow the trend. Which output change fixes this?

⬜ Group the figures under a heading for each source document so provenance stays visible.
⬜ Turn the whole report into one uniform table so every section renders the same way.
⬜ Order the revenue figures chronologically by reporting period.
⬜ Rewrite the figures as prose describing the overall trend.

A system outputs one confidence score per document, and documents above 0.85 skip human review. Reviewers, whose capacity is fixed, still find frequent date-field errors in documents above 0.85. Which change improves review routing?

⬜ Raise the document-level threshold from 0.85 to 0.95 so more borderline documents get reviewed.
⬜ Output a confidence score per field and calibrate each field’s review threshold on a labeled validation set.
⬜ Tell the model to report lower confidence when a field’s source text is ambiguous.
⬜ Add random sampling of documents that skip review to measure that population’s error rate.

A research system’s web search subagent hits frequent timeouts from its external API. One quick retry fixes most of them, but a few persist. Today every timeout goes straight to the coordinator, costing extra turns and tokens. How should the subagent handle timeouts?

⬜ After a failed local retry, return one generic ‘search unavailable’ status for all remaining failures.
⬜ Retry timeouts locally with backoff, and report persistent failures to the coordinator with the attempted query and any partial results.
⬜ Report every timeout to the coordinator immediately as structured error context.
⬜ Keep retrying inside the subagent with increasing backoff until the call succeeds.

A research coordinator’s system prompt has explicit escalation criteria and five few-shot examples, all of which end in escalation. In production it now escalates routine cases it could resolve, such as a single search timeout. What change is most effective?

⬜ Have the coordinator rate its confidence for each case and escalate only below a calibrated threshold.
⬜ Add more escalation examples covering more failure types.
⬜ Add examples of cases to resolve autonomously alongside the escalation examples.
⬜ Replace the examples with a longer, more precise numbered list of criteria.

A developer changed a document analysis subagent’s loop to send only the latest message and tool result in each Messages API request. Sessions stay well under the context limit, but the subagent now repeats completed lookups and contradicts its earlier findings. What should change?

⬜ Resend all earlier tool_result blocks but leave out the assistant turns that requested them.
⬜ Send the full message history, including every earlier assistant turn and tool result, in each request.
⬜ Mark the earlier turns with cache_control so the API serves them from cache without resending them.
⬜ Replace the earlier turns with a model-written summary sent with the latest exchange.

A synthesis subagent receives a 70K-token aggregated input. Its drafts cite findings from the beginning and end but skip well-supported findings from the middle. Final reports must quote exact figures from the detailed results. How should the input be restructured?

⬜ Move the research question and instructions to the top, before the subagent results.
⬜ Put a key-findings summary at the top and mark each subagent’s detailed results with clear section headings.
⬜ Split the input and call the synthesis agent once per subagent output with a running summary.
⬜ Have each subagent compress its results into a short summary before aggregation.

A custom audit subagent reports every call to a deprecated API, but its findings leave out file paths and line numbers. The main session has to search the codebase again to locate each call, filling its context with discovery output. Which change fixes this?

⬜ Add a required report format with file path and line range fields to the subagent’s system prompt body.
⬜ List the required output fields in the subagent’s description field.
⬜ Have the main session run Grep after each delegation to attach file locations.
⬜ Narrow the subagent’s tools frontmatter to Grep and Read.

A coordinator script spawns one Claude Code agent per module for an overnight migration across 40 modules. Three hours in, the machine crashes. Which design lets a restarted run skip modules that already finished?

⬜ Have each agent write its status and results to a state file, and have the coordinator load a manifest on restart.
⬜ Resume each agent’s named session with –resume so its context is restored.
⬜ Have each agent keep a scratchpad of key findings and read it when context degrades.
⬜ Run /compact in each session before every phase so sessions stay small.

A find_service MCP tool returns every match for a name fragment. For “raise the payments timeout,” three actively used services match, and Claude edits the most recently deployed one, often the wrong one. What should change?

⬜ Have Claude rate its confidence in the chosen service and edit only when confidence is high.
⬜ Add few-shot examples to CLAUDE.md showing the right service for common timeout requests.
⬜ Change find_service to rank matches by relevance and return only the top one.
⬜ Add a CLAUDE.md instruction: when find_service returns several matches, list them and ask the developer to choose.

A Claude Code audit for deprecated API usage couldn’t read some directories, but its final report lists findings and mentions no gaps. The team still wants the partial results. Which two practices fix this? (select two)

⬜ Have the agent distinguish directories with no findings from directories it couldn’t read, instead of reporting both as clean.
⬜ Remove the unreadable directories from the report so it contains only confirmed findings.
⬜ Stop the audit and return an error whenever a directory can’t be read.
⬜ Annotate the report by area, marking which directories were fully scanned and which were skipped because they couldn’t be read.

A team sends Claude Code changes to senior review when Claude’s self-rated confidence is below 7. An audit finds regressions in complex concurrency refactors that Claude rated 9 or 10, the same scores it gives routine renames. What should the team do?

⬜ Raise the threshold so only changes rated 10 skip senior review.
⬜ Calibrate the threshold against a labeled set of past changes and their regression outcomes.
⬜ Define explicit review criteria in the prompt, with examples of changes that do and don’t need review.
⬜ Add a self-review pass where Claude re-examines each change and updates its rating.

Validation retries fix date-format errors in one pass, but when a scan has no readable invoice number, retries never succeed and the model eventually invents one. Downstream billing needs a real invoice number. How should these documents be handled?

⬜ Raise the retry limit and include the previous extraction and the validation error each time.
⬜ Make invoice_number nullable so the model returns null instead of inventing a value.
⬜ Add few-shot examples of invoice-number extraction from varied scanned layouts.
⬜ Detect when the invoice number is missing from the source and route those documents to human review.

After 30 or more turns of correcting extracted invoices in one session, the assistant starts using superseded statuses and wrong totals. Compaction turned exact values into loose summaries, and each re-validation result adds over 30 fields to context. Which two changes prevent these errors? (select two)

⬜ Enable structured outputs with a strict schema so every response’s IDs, amounts and statuses are validated.
⬜ Keep a persistent structured block of invoice IDs, amounts and statuses outside the summarized history and send it with every prompt.
⬜ Rewrite the compaction prompt so every amount, ID and status is kept word for word.
⬜ Trim each re-validation result to the fields the current invoice needs before it enters context.

During multi-hour billing dispute investigations, compaction erases the agent’s earlier reasoning. It still quotes amounts and order numbers correctly, but it forgets which explanations it already ruled out and repeats the same lookups. What should change?

⬜ Re-run the backend lookups after each compaction to rebuild the lost findings.
⬜ Rewrite the compaction prompt so every ruled-out explanation is kept word for word.
⬜ Extract amounts, dates and order numbers into a persistent case-facts block sent with every prompt.
⬜ Have the agent write key findings to a scratchpad file and consult it after compaction.

A billing dispute covers two orders. lookup_order verifies the first but times out on the second, and retries fail during a backend outage expected to last hours. The customer asks for a human. How should the agent build the handoff?

⬜ Organize it into sections: verified findings for the first order, and the unchecked second order annotated with the failure reason.
⬜ Hold the escalation and keep retrying until the second order’s data arrives.
⬜ Escalate the first order now and open a separate follow-up case for the second.
⬜ Attach the session’s complete raw tool outputs and error responses as evidence.

A customer disputes charges on three orders. lookup_order returns full data for two, and the lookup for the third times out even after retries. The same order-system outage also blocks the human support team. How should the agent respond?

⬜ Hold the reply and keep retrying the third lookup until data comes back.
⬜ Escalate the whole case so one human resolves all three disputes together.
⬜ Resolve the two verified orders and mark the third as unresolved because its order data is unavailable.
⬜ Resolve the two verified orders and leave the third out of the reply until the system recovers.

Billing disputes require a customer’s full transaction history, and dispute signals can appear in any line or field (descriptors, notes, adjustments), so nothing can be removed before analysis. After these lookups, later turns misquote amounts. Which design change fixes this?

⬜ Delegate the analysis to a subagent, passing it the customer ID and dispute details, and have it return a findings summary.
⬜ Add a PostToolUse hook in the main agent that trims each transaction history to relevant fields.
⬜ Summarize the conversation right after each history lookup.
⬜ Spawn an analysis subagent and have it pull the dispute details from the main agent’s history.

A coordinator’s escalation rule says “escalate when you are not sure you can recover.” Its two few-shot examples show only the failure and the chosen action. In testing it copies the action of whichever example looks most similar, even when the failure type differs, and production will include failure types testing never produced. Which two rewrites make the guidance effective? (select two)

⬜ Show the reasoning behind the decision in each example, not just the failure and the action.
⬜ Replace the vague rule with checkable conditions, such as escalating only when a failure persists after retries.
⬜ Add one example for each failure type seen in testing so every failure matches an example.
⬜ Have the coordinator rate its confidence from 1 to 10 and escalate below a threshold.

Every refund waits a day in a staff queue, where reviewers reject about one in ten, mostly orders that were already refunded. Leadership wants refunds up to $20 to skip review. What should decide which ones skip it?

⬜ Deterministic code checks that the order exists, the amount is within $20 and no refund was previously posted.
⬜ Deterministic code checks that the amount is within $20 and the order exists, without checking earlier refunds.
⬜ Automatic approval of every refund up to $20, with staff auditing a random tenth each week.
⬜ The agent’s own classification of the case as routine in its summary.

A random audit of 400 resolved support cases shows 97% accuracy overall, and 12 of the audited cases were account problems. Leadership wants to end human review of account-problem cases. What should the team do first?

⬜ Draw a fresh random sample of 400 cases of all types and measure account-case accuracy within it.
⬜ End review of account problems if none of the 12 audited account cases were wrong.
⬜ Sample enough account-problem cases on their own to measure that type’s accuracy, then decide.
⬜ Keep human review only for cases that later get a complaint or are reopened.

Every research subagent returns claims with a source and date, yet the final brief sometimes prints figures with no source, or with another report’s date. Most errors involve claims that several sources supported. Which two changes keep attribution intact? (select two)

⬜ Have the report subagent restore missing sources at the end by searching the original documents.
⬜ Require the synthesis output to map each merged claim to all of its contributing sources and their dates.
⬜ Have synthesis write merged claims in prose, followed by a bibliography of every source used.
⬜ Validate each stage’s output in code and reject any claim that reaches the next stage without its source and date.

At 7:40 a.m., a research system can’t retrieve today’s central bank rate decision, which the brief’s lead section requires and can’t publish without. Other sections are useful on their own and due at 8 a.m., and the duty editor may approve a brief without the lead. Two minor news sources also failed. What should the coordinator do?

⬜ Hold the whole brief and escalate, releasing nothing until the rate decision is verified.
⬜ Escalate the blocked lead section to the duty editor and, if approved, release the other sections by 8 a.m. with the minor gaps noted.
⬜ Release every section by 8 a.m. with a placeholder lead, then ask the editor to approve it afterward.
⬜ Fill the lead with yesterday’s rate decision, labeled with its date, and release on time.

A support case has an open return and a disputed charge. A billing result settles the charge, but the return is waiting for warehouse evidence that arrives later. The agent must continue without losing either status. Which two state updates are needed? (select two)

⬜ Mark the charge issue resolved with its billing evidence, and keep the overall case open for the return.
⬜ Keep one status for the whole case, waiting on warehouse, and note the charge result as free text.
⬜ Record the return’s missing evidence and next action in its own issue entry for a later turn.
⬜ Mark the whole case resolved, and reopen it when the warehouse evidence arrives.

An enrichment agent checks each supplier’s VAT number before an import agent loads the record. When the registry times out, the enrichment agent leaves vat_verified out, and the importer treats a missing field as verified. Timed-out records must be rechecked the next day; rejected numbers go to the supplier team. What handoff change closes the gap?

⬜ Set vat_verified to false on timeout and have the importer reject records marked false.
⬜ Add a warning to the enrichment agent’s prose message and pass the record on unchanged.
⬜ Retry the registry until it responds, holding each record until the check completes.
⬜ Send an explicit verification state (verified, failed or not checked) with its reason inside the structured record.

A coordinator passes a synthesis subagent eight source excerpts separated by dashed lines, each with its source name on the line above. Reports sometimes quote a figure from one excerpt but credit the neighboring source. What change fits best?

⬜ List the eight source names in a table after the last excerpt, in excerpt order.
⬜ Add a rule telling synthesis to take particular care with attribution.
⬜ Wrap each excerpt in its own document tags, with the source name and content in separate subtags.
⬜ Replace the dashes with blank lines and Markdown headings above each excerpt.

A coordinator sends all collected sources to a synthesis subagent in one request. For big topics the request fails with a context-length error, and the coordinator retries with half the sources, sometimes twice. What should it do instead?

⬜ Estimate four characters per token and split when the estimate looks too high.
⬜ Count the request’s tokens before sending, and split the sources when the count passes a set budget.
⬜ Keep retrying, but drop the least-cited half of the sources each time.
⬜ Use the model with the largest context window and keep sending everything at once.

A freight extraction system sends every document over 20 pages or in several languages to human review. Reviewers find 95% of those extractions already correct, while errors in short documents pass straight through. What should decide review?

⬜ A lower page threshold of ten pages, still sending all multilingual documents.
⬜ A complexity score Claude assigns, with high scores going to review.
⬜ The current rules, with more reviewers added.
⬜ Failed validation checks plus any fields the extractor marks as uncertain, regardless of document length.

A customs extractor must assign a tariff code to each product. Some descriptions fit two codes with different duty rates, and the extractor picks one without saying so. Wrong codes lead to fines. Which two changes fit? (select two)

⬜ Have the extractor flag descriptions that fit more than one code, listing each candidate with its duty rate.
⬜ Have the extractor pick the best match and record a confidence score next to it.
⬜ Send each flagged tariff code to a customs specialist who decides before the declaration is filed.
⬜ Add a rules table of common products and codes and let the extractor handle the rest.

A support agent runs one long session per chat channel, serving customers one after another. Last week it offered a pickup at the previous customer’s address to the next customer. How should the design change?

⬜ Start a new agent session for each case and load only that customer’s verified case facts.
⬜ Start a new session per case with a brief summary of the previous customer’s case.
⬜ Keep one session and compact it between customers.
⬜ Start a new session per case but reuse the previous case’s tool results.

Policy says legal threats go to a human. A customer writes: “If my delivery date is wrong again, I will take you to small claims court. When will it arrive?” The agent could answer the date from lookup_order. Which two actions are correct? (select two)

⬜ Escalate under the legal-threat policy, even though the agent could answer the delivery question.
⬜ Answer the delivery question first and escalate only if the customer repeats the threat.
⬜ Include in the handoff the order details, the customer’s exact words and what the agent has already verified.
⬜ Include a summary of the customer’s tone in the handoff and leave out the exact wording.

After six hours in one session, a research coordinator cites sources it rejected earlier, repeats questions subagents already answered and drifts from the report format, although its context window isn’t full. What should the team do?

⬜ Repeat the format rules and the list of rejected sources at the end of each new prompt.
⬜ Move to a model with a bigger context window and keep the session running.
⬜ Have the coordinator review its whole six-hour history and list its own mistakes.
⬜ Start a fresh session seeded with a concise summary of accepted findings, their sources and open questions.

This week’s Key Findings lists a drop in teen smoking, replicated in three studies, next to a rise in vaping from one small online survey. Council members may read both as equally certain. How should the report change?

⬜ Keep both in Key Findings and add the survey’s sample size in brackets.
⬜ Separate findings into a well-established section and a contested section, each with its own evidence summary.
⬜ Keep both, listing the replicated finding first.
⬜ Move the vaping result to a methodology note.

A state health data portal has returned errors all morning. The search subagent retried it 40 times this run, slowing the whole pipeline, and the draft says nothing about the missing state figures. The report is due at 9 a.m. What should the system do?

⬜ After three consecutive failures, stop calling the portal for the rest of the run and state in the report that this week’s state figures are unavailable.
⬜ Keep retrying with backoff until it responds, delaying the report if needed.
⬜ Use last week’s cached figures with a footnote and keep retrying in the background.
⬜ After three failures, stop and have synthesis estimate the state figures from county data.

Two sources give the cost of a flu hospital stay: a national 2024 study in euros and a local 2026 study in dollars. The report shows both in dollars in one table, and readers must be able to check each figure against its source. How should the table present them?

⬜ Convert both to 2026 dollars and drop the original figures.
⬜ Convert both and note the exchange rate and source years in a footnote.
⬜ Convert both and describe the method once in an appendix.
⬜ Show each converted value next to its original amount in the source currency and year, with the exchange rate used.

Engineers build a research system with Claude Code. In each new session, Claude spends the first 15 minutes exploring the repository to find the subagent definitions, prompts and citation checker. What helps most?

⬜ Paste the full repository file tree into CLAUDE.md.
⬜ Add a short map of key folders and entry points to each engineer’s ~/.claude/CLAUDE.md.
⬜ Add a short map of key folders and entry points to the project CLAUDE.md.
⬜ Create a skill that explores the repository and prints its structure at session start.

A document subagent reads 400-page regulatory filings and returns prose summaries. When synthesis needs to quote a passage, it reopens the full filing and searches for it, filling its context. Which two output changes help most? (select two)

⬜ Return each finding with the document path and the page and paragraph range that supports it.
⬜ Return each finding with its page number only and let synthesis re-read that page.
⬜ Return each finding with the filing’s title and publication year.
⬜ Include a short verbatim excerpt with each finding so synthesis can quote it without reopening the filing.

Credit decisions the support agent rates low-confidence go to a review team, and each review takes about 12 minutes because reviewers read the whole conversation and bill to find the evidence. Accuracy is fine. How should reviews be presented?

⬜ Show each decision with the bill lines and customer statements that support it, quoted next to the decision.
⬜ Show each decision with links to the full conversation and bill.
⬜ Show each decision with the agent’s own written rationale.
⬜ Give reviewers a second model’s summary of the conversation and bill.

A support agent keeps a case-facts list that it appends to in long conversations. A customer gives a delivery address for a new SIM, then corrects it twenty turns later. The handoff lists both addresses, and the SIM ships to the old one. How should facts be recorded?

⬜ Keep only the first value for each fact, since customers state details most carefully at the start.
⬜ Rebuild the facts list from the whole conversation at handoff and let the specialist pick.
⬜ Record the latest address in a separate field and keep everything else appended.
⬜ Record each fact with its turn and timestamp so a later value for a field replaces the earlier one.

Subagents search a claims database and return every matching record in full, sometimes 400 per task. The coordinator only needs which claims match and how many, but its context fills after a few tasks. Which two changes fit? (select two)

⬜ Have subagents return claim IDs with the few fields the question needs, not whole records.
⬜ Have subagents compress each record into a shorter prose summary before returning them all.
⬜ Switch the coordinator to a larger-context model and keep the full records.
⬜ Return counts and a sample of IDs for large sets, and let the coordinator fetch specific claims by ID when needed.

A review coordinator runs four analysis subagents in parallel. The dependency scanner sometimes hangs for 40 minutes, the CI step hits its time limit, and no review is posted at all. What should the coordinator do?

⬜ Wait however long it takes and raise the CI time limit to two hours.
⬜ Give each subagent a timeout and treat a hung one as a structured failure, posting the other findings with the gap noted.
⬜ Cancel the whole review once any subagent passes five minutes and rerun all four.
⬜ Time out the scanner and, when it expires, cancel the review and post a failure notice.

A nightly job generates tests for 200 modules in sequence. When one module fails to compile, the job exits, so later modules get no tests that night; module 37 failed four nights in a row. What should the job do?

⬜ Stop at the first failure but page on-call to fix the module quickly.
⬜ Run the modules in parallel batches of 20 so a failure stops only its batch.
⬜ Record the failed module with its compile error, continue with the rest and list failures in the summary.
⬜ Mark module 37 as skipped in the config and keep exiting on any other failure.

---