Pytania do Claude Certified Architect: wszystkie 60 z wyjaśnieniami

A customer support resolution agent built with the Claude Agent SDK reaches backend systems through custom MCP tools (get_customer, lookup_order, process_refund, escalate_to_human). The engineering team wrote a wrapper loop that ends the conversation whenever the assistant's text matches a closing phrase like "let me know if there's anything else." Production logs show that in 11% of sessions the loop terminates while a tool_use block is still pending, so the refund is never actually executed. What is the correct way to drive the agentic loop?

• A. Terminate only when stop_reason is end_turn; whenever stop_reason is tool_use, execute the requested tool, append the tool_result to the message list, and continue the loop.
• B. Expand the regex allowlist of closing phrases so it recognizes every polite sign-off the model might emit before stopping.
• C. Add a max-iteration cap and stop the loop once the assistant produces two consecutive text-only responses.
• D. Run a lightweight intent classifier on each assistant message to decide whether the turn represents a genuine completion.

When the support agent invokes escalate_to_human, human agents report they must re-read the entire raw conversation to understand each case, and average handle time for escalated tickets has risen. What should the agent do at the moment of escalation to fix this?

• A. Attach the full untrimmed transcript of the conversation so the human has complete information.
• B. Enable extended thinking on the escalation turn so the model reasons longer before handing off.
• C. Escalate earlier in ambiguous cases so humans receive tickets before much conversation has accumulated.
• D. Produce a structured handoff summary — the customer's issue, verified identifiers, tool results and account state gathered, actions already attempted, and the specific recommended next step.

Company policy states that any refund above $500 must be approved by a manager rather than auto-issued. The support agent, however, has autonomously called process_refund for amounts over $500 in several audited cases. What is the best way to guarantee the policy holds?

• A. Add a PreToolUse interception hook on process_refund that blocks any call with an amount over $500 and redirects the flow to escalate_to_human.
• B. Add a line to the system prompt instructing the agent to always escalate refunds over $500 instead of processing them.
• C. Remove process_refund from the agent's toolset entirely so every refund is handled by a human.
• D. Fine-tune the model on historical tickets so it learns the $500 threshold from past manager approvals.

get_customer and lookup_order call two different backend systems that return dates in different formats (ISO vs. US) and amounts with inconsistent currency notation. Logs show the model occasionally misreads these heterogeneous fields, e.g., treating a refund amount in the wrong units. What is the most robust remedy?

• A. Instruct the model in the system prompt to normalize all dates and currency values before reasoning about them.
• B. Add a PostToolUse hook that normalizes each tool's raw output into one canonical schema before it is appended to the context.
• C. Increase the context window so the model has more room to keep the varied formats straight.
• D. Spin up a dedicated formatting subagent that the coordinator calls after every backend lookup.

The coordinator has already run get_customer and confirmed the account, then spawns subagents to check order history and refund eligibility in parallel. Those subagents return results that contradict the confirmed account — some even re-run get_customer and pick a different customer match. What is the correct fix?

• A. Enlarge the shared context window so the subagents can see the coordinator's earlier turns.
• B. Store the confirmed customer record in a global variable that the SDK automatically injects into every subagent.
• C. Instruct each subagent to call get_customer itself at the start so it independently establishes the account.
• D. Include the coordinator's already-verified findings — the confirmed customer record and identifiers — explicitly in each subagent's Task prompt, since subagents do not inherit the coordinator's conversation context.

process_refund handles both full order refunds and small partial goodwill credits. Logs show the agent issues full refunds when only a partial credit was warranted in 17% of cases because it cannot tell from the single tool which behavior it is invoking. What is the best fix?

• A. Raise the agent's context window so the entire refund policy document fits alongside the conversation.
• B. Split process_refund into two tools, process_full_refund and process_partial_credit, each with a distinct description and explicit boundary on when to use it.
• C. Add three few-shot examples of partial-credit conversations to the system prompt while keeping the single tool.
• D. Set tool_choice to "any" so the model is compelled to select a tool on every refund turn.

When the customer database is briefly unreachable, get_customer returns a plain empty result, and the agent tells the customer "I can't find any account with that information" and closes the case. Real accounts are being turned away during transient outages. What should the MCP tool return instead?

• A. Automatically retry get_customer in a tight loop until the database responds, however long that takes.
• B. Increase the get_customer connection timeout so slow database responses are no longer cut off.
• C. A structured error with an errorCategory (e.g. transient) and isRetryable metadata that lets the agent distinguish an access failure from a valid empty result and respond accordingly.
• D. Treat every non-successful get_customer response as an escalation trigger and route all of them to escalate_to_human.

For refunds above the agent's $500 authority, process_refund correctly declines, but it returns a generic isError response. Logs show the agent then retries the same $640 refund three times before eventually giving a confusing reply. How should the tool signal this condition?

• A. Have the agent retry with exponential backoff, since repeated attempts eventually succeed for most declined refunds.
• B. Raise the agent's refund authority limit above $640 so the call no longer fails.
• C. Instruct the agent in the system prompt to never retry a refund more than once.
• D. Return a structured error with errorCategory "business" and isRetryable set to false, so the agent stops retrying and routes the request to escalate_to_human.

In longer billing-dispute conversations, the agent uses progressive summarization to keep the history compact. Testers find that after several turns it quotes the wrong refund amount and an incorrect order date, even though those values appeared earlier. What is the best remedy?

• A. Maintain a persistent 'case facts' block (order id, amount, dates, customer expectation) stored outside the summarized history and re-injected verbatim each turn.
• B. Switch to a model with a larger context window so no summarization is needed.
• C. Call get_customer and lookup_order again on every turn to refetch the numbers.
• D. Enable extended thinking so the model reasons more carefully before quoting figures.

A customer gives only the name "Maria Garcia." get_customer returns three distinct matching accounts. Logs show the agent proceeds with the most recently active match, and in several cases it has processed refunds against the wrong customer's order. What is the correct behavior?

• A. Continue with the most recently active of the three accounts, since it is the most likely current customer.
• B. Pick the match with the highest fuzzy name-similarity score and proceed.
• C. Escalate every multiple-match case straight to a human agent.
• D. Ask the customer for an additional identifier (order number, email, or ZIP) to disambiguate before taking any account action.

Your team standardized naming and error-handling conventions by adding them to ~/.claude/CLAUDE.md on the tech lead's machine. Everything works for the lead, but three newly onboarded engineers who cloned the repo report that Claude Code ignores the conventions entirely, even though git status shows a clean checkout. What is the most effective fix?

• A. Add an @import to the repo-root CLAUDE.md pointing at ~/.claude/CLAUDE.md so the personal file is pulled in for everyone
• B. Have each engineer run /memory after cloning to force-reload the user-scoped memory files
• C. Move the conventions into the project-scoped .claude/CLAUDE.md (or repo root) so they are committed to version control and load for every clone
• D. Convert the conventions into a skill under .claude/skills/ so they activate on demand for all users

Your team's /investigate-flaky skill greps the entire test suite, reads dozens of files, and prints verbose exploration before it answers. Developers notice that after running it, the main session is cluttered with raw output and Claude's subsequent answers in that session degrade in quality. What is the best fix?

• A. Add a step to CLAUDE.md instructing Claude to summarize the skill's output before continuing
• B. Set context:fork in the skill's SKILL.md frontmatter so its verbose exploration runs in an isolated context and only the result returns to the main session
• C. Increase the context window so the accumulated exploration output no longer causes degradation
• D. Restrict the skill with an allowed-tools list so it reads fewer files during exploration

A team's .claude/skills/dep-audit/ skill is meant to be run manually before releases, but Claude keeps auto-invoking it mid-session whenever dependency files come up, dumping roughly 4,000 lines of resolution output into unrelated refactoring sessions. The team still wants engineers to be able to run /dep-audit explicitly. What is the most effective fix?

• A. Call /compact automatically at the end of the skill so the audit output is condensed before work continues
• B. Set disable-model-invocation: true in the skill's SKILL.md frontmatter so the skill runs only when a user explicitly invokes /dep-audit
• C. Delete the skill's description frontmatter so Claude can no longer match it to conversation topics
• D. Move the audit instructions into CLAUDE.md so they load once at startup instead of triggering mid-session

A shared generate-docs skill is supposed to read source and write Markdown into docs/, but twice it has run Edit and shell rm and overwritten source files. Adding the reminder "only write to docs/, never edit source" to the skill body has not reliably stopped it. What is the best way to guarantee the skill cannot touch source?

• A. Add a stronger system-prompt instruction forbidding edits to any file outside docs/
• B. Require the skill to run in plan mode every time so a human approves each action
• C. Declare allowed-tools in the skill's SKILL.md frontmatter, restricting it to Read/Glob/Write so the harness blocks Edit and Bash entirely
• D. Add a global PreToolUse hook that inspects every Edit across all sessions and rejects ones outside docs/

A shared /scaffold-component skill expects a component-name argument, but telemetry shows teammates invoke it with no argument or a malformed one about a third of the time, producing empty or misnamed scaffolds. What is the most effective way to reduce these malformed invocations?

• A. Add an argument-hint field to the skill's SKILL.md frontmatter so the expected argument and format are shown at the invocation prompt
• B. Document the correct usage in the project CLAUDE.md so it is always loaded into context
• C. Rename the skill to /scaffold-component-with-name so the required input is implied by the name
• D. Have the skill body instruct Claude to ask the user for the name whenever it is missing

A developer needs three changes that all touch the shared PaymentStatus enum and the several functions that switch on it. They sent each change as a separate sequential message; after the third message the project no longer compiles because the earlier edits did not anticipate the later ones. What is the best way to structure the request?

• A. Run each of the three changes in its own fresh session so they stay cleanly isolated
• B. Enable plan mode and approve the three changes one at a time in sequence
• C. Keep them sequential but ask Claude to re-read the enum before each message
• D. Batch the three interacting changes into a single message so Claude edits the enum and all dependent switch sites together with full mutual context

Asking Claude to "make the input validation more robust and idiomatic" yields inconsistent output across runs: sometimes it adds zod, sometimes hand-written checks, sometimes nothing meaningful. The team wants the validation style to come out consistent. What is the most effective refinement?

• A. Expand the request into a longer, more detailed prose description of what "robust" and "idiomatic" mean
• B. Provide 2-3 concrete input-to-output examples showing the exact validation style and library you want
• C. Fine-tune a model on the team's existing validation code so it internalizes the house style
• D. Add a standing CLAUDE.md rule stating that validation should always be robust and idiomatic

During a 200-file framework migration carried out in one long session, logs show Claude re-migrating files it already converted and skipping others as the conversation grows. What technique best keeps the migration on track?

• A. Switch to a larger-context model so the whole file list stays in the window
• B. Run /compact frequently to keep the history short
• C. Maintain a scratchpad manifest file that records migrated vs pending files and update it after each file, so progress survives context growth
• D. Do the entire migration in a single large message to avoid state loss between turns

To rename a widely-used internal API, Claude must first locate every call site across a large monorepo. Doing this discovery inline reads dozens of files and floods the main session with search output before any edits begin, and the later edits then start to wander. What is the best approach?

• A. Delegate the discovery to an Explore subagent that searches the monorepo and returns only a summary of call sites, keeping the main context focused on the edits
• B. Read every candidate file into the main session first so all call sites are visible before editing
• C. Run /compact after each search so the accumulated output is repeatedly condensed
• D. Move to a larger-context model so the exploration output no longer competes with the edits

Midway through a coherent multi-hour refactor, the session approaches its context limit. The history is full of superseded intermediate diffs, but the current task and goal are unchanged and the latest file states are still valid. What should the developer do to keep going without losing the thread?

• A. Start a brand-new session with no prior context and re-describe the task
• B. Fork the session to branch off a divergent line of work
• C. Request a larger context window and continue as-is
• D. Run /compact to condense the accumulated history into a summary while continuing the same task

In a long debugging session Claude repeatedly runs the full test suite; each run dumps roughly 2,000 lines of passing-test noise into the context. Over time Claude starts overlooking the failing-test details and the constraints stated at the start of the session. What is the best fix?

• A. Switch to a larger-context model so all the test output fits comfortably
• B. Trim each test run's output to the relevant failing-test lines before it accumulates, and keep the key constraints in a summary placed at the top of the context
• C. Enable extended thinking so Claude reasons harder over the full accumulated output
• D. Instruct Claude to re-read the entire session history at the start of every turn

The synthesis subagent's reports read as generic overviews: in 30% of runs they omit the specific figures and named sources the web-search subagent surfaced. Tracing shows the Task prompt sent to the synthesis subagent contains only the report topic and formatting instructions. What is the best fix?

• A. Increase the coordinator's context window so more findings stay resident across delegations
• B. Have the coordinator embed the web-search and document-analysis findings verbatim in the synthesis subagent's Task prompt
• C. Add a 'recall the earlier research' instruction to the synthesis subagent's system prompt
• D. Give the synthesis subagent its own web-search tool so it can re-gather the missing figures

The coordinator dispatches three independent regional web-search subagents (EU, US, APAC), but issues each Task call only after the previous subagent returns. End-to-end research latency is about 3x the slowest single search. What change most reduces latency?

• A. Emit all three Task calls in a single assistant response so the subagents execute concurrently
• B. Merge the three regional searches into one subagent that loops over regions internally
• C. Add a fixed iteration cap so the coordinator stops waiting after a set number of rounds
• D. Set tool_choice to 'any' so the coordinator selects tools faster

A newly configured coordinator answers research questions directly from its own knowledge instead of delegating; its attempts to invoke subagents never appear in the trace. The subagent definitions exist and work when tested standalone. What is the root cause?

• A. The subagents were registered at user scope while the coordinator runs at project scope
• B. The coordinator's model is too small to plan multi-agent delegation
• C. The coordinator's allowedTools list omits 'Task', so it cannot spawn subagents
• D. tool_choice is forced to a specific tool, blocking delegation

For open-ended briefs like 'assess the competitive landscape for X', the coordinator runs a fixed three-step chain (search then summarize then format). Reviewers note the reports consistently miss emerging subtopics that only surface mid-investigation. What orchestration change best fits this workload?

• A. Add few-shot examples of good reports to the formatting step
• B. Raise the temperature of the synthesis subagent to encourage broader coverage
• C. Keep the fixed chain but add a second formatting pass
• D. Switch to dynamic decomposition so the coordinator spawns follow-up subtasks based on what earlier findings reveal

After the shared search and document-analysis phase completes, stakeholders want two report variants from the same evidence — a one-page executive brief and a technical deep-dive — without re-running the costly searches. What is the best way to produce both?

• A. Continue the same session, generate the brief, then ask for the deep-dive in the next turn
• B. Fork the session at the end of the research phase into two branches, one per report variant
• C. Start two fresh sessions and re-run the search subagents for each
• D. Increase the context window so both reports fit in one generation

Logs show the document-analysis subagent attempting to invoke the web-search subagent directly to fill gaps, producing routing errors and duplicated searches. How should the topology be corrected?

• A. Route all requests through the coordinator: subagents return gaps to it, and it dispatches any follow-up web searches
• B. Let subagents call each other but add a lock to prevent duplicate searches
• C. Merge the document-analysis and web-search subagents into one general subagent
• D. Give every subagent the full tool set so none needs to call another

A weekly market report is produced by --resume of a named coordinator session. This week the report cites last week's prices as current, because the resumed session replays cached web-search tool results. What is the best fix?

• A. Fork the prior session so the stale results are copied into a new branch
• B. Keep using --resume but instruct the coordinator to ignore old tool outputs
• C. Increase the context window so both old and new results coexist
• D. Start a fresh session, inject a concise summary of the prior report's conclusions, and re-run the searches

The coordinator's agentic loop sometimes stops before the report subagent has run: it ends whenever the latest assistant text contains the phrase 'research complete'. Intermittently the synthesis subagent uses that phrase mid-analysis, halting the workflow. How should loop termination be driven?

• A. Add a minimum iteration count before the coordinator is allowed to stop
• B. Use a stricter regex that also requires the word 'final'
• C. Continue the loop while stop_reason is tool_use (appending each tool result) and stop only on end_turn
• D. Have a classifier judge whether the report is truly finished

The synthesis subagent is initialized with the full registry of 18 tools shared across the system (web_search, fetch_url, parse_pdf, extract_tables, generate_chart, render_report, and others). Traces show that in 22% of runs it issues a fresh web_search or parse_pdf call instead of combining the findings the coordinator already passed in its prompt, adding 6-9 s of latency per run. What is the most effective fix?

• A. Restrict the synthesis subagent to the small set of tools its role actually needs, removing the search and parsing tools from its configuration
• B. Increase the synthesis subagent's context window so all prior findings fit and it stops re-fetching them
• C. Add a system-prompt line instructing the synthesis subagent to never call web_search or parse_pdf
• D. Force tool_choice to "any" so the model commits to exactly one deliberate tool call per turn

The document-analysis subagent must call classify_document before running any field extraction, because the extraction schema depends on the detected type. Relying on a prompt instruction, it skips classification in 9% of runs and extracts against the wrong schema. The coordinator invokes it once per document, and the required first step is always the same. What is the best fix?

• A. Set tool_choice to "any" so the subagent is required to use some tool on the opening turn
• B. On the first turn, set tool_choice to the forced form {"type":"tool","name":"classify_document"} so classification always runs before extraction
• C. Strengthen the system prompt with an emphatic "ALWAYS classify before extracting" plus two worked examples
• D. Add an interception hook that inspects each extraction call and blocks it whenever no classification has run

The document-analysis subagent handles mixed inputs: some are PDFs requiring parse_pdf, and some are already plain-text snippets that need no tool at all. It is currently configured with tool_choice "any". Logs show it calling parse_pdf on plain-text inputs — returning garbage — in 18% of cases. What is the best fix?

• A. Force tool_choice to the parse_pdf tool so parsing behavior is deterministic
• B. Keep "any" but add a preprocessing stage that strips plain-text inputs out before dispatch
• C. Set tool_choice to "auto" so the model can respond directly when no tool is required
• D. Add more few-shot examples of plain-text inputs to the subagent's prompt

The web-search subagent is equipped with two tools, search_web and search_academic, each carrying a one-line description ("search the web" / "search academic sources"). It routes queries to the wrong tool in 31% of cases — for example, sending peer-reviewed-literature queries to search_web. What is the best first step?

• A. Consolidate the two tools into a single unified search tool
• B. Add a separate router model that classifies each query and selects the tool programmatically
• C. Set a forced tool_choice so the subagent always uses one designated search tool
• D. Expand and differentiate both tool descriptions — specifying input formats, example queries, source coverage, and explicit boundaries for when to use each

The synthesis subagent merges findings from the web-search and document-analysis subagents into a unified narrative but drops the record of which source each claim came from. The report-generation subagent can then no longer attach citations, and 40% of the report's sentences ship uncited. What is the best fix?

• A. Have the report-generation subagent re-run web_search to find a supporting source for each sentence
• B. Add a citation post-processor that guesses the most likely source for each uncited sentence
• C. Preserve claim-to-source mappings through the synthesis step so each synthesized claim carries its originating source(s) into report generation
• D. Instruct synthesis to insert "(source)" placeholders that a human fills in after the report is generated

Two sources report different market-size figures for the same market — $4.2B (2021 data) versus $6.8B (2023 data). The synthesis subagent silently picks $6.8B and presents it as the single authoritative fact. Reviewers, seeing the discarded figure elsewhere, flag the report as unreliable. What is the best fix?

• A. Always keep the larger or more recent figure and drop the other before synthesis
• B. Average the two figures into a single blended number
• C. Route every conflicting statistic to a human reviewer before synthesis can continue
• D. Annotate both statistics with their source and collection/publication date, so the temporal difference is surfaced rather than misread as a contradiction

The coordinator passes each subagent's output forward verbatim: the web-search subagent's full scraped page bodies — roughly 38k tokens — flow straight into the synthesis subagent's prompt. Synthesis quality has dropped and it now misses findings buried in the middle of the passed-in content (lost-in-the-middle). What is the best fix?

• A. Trim each subagent's output to its relevant extracted findings before passing it downstream, and lead the synthesis prompt with a key-facts summary under section headers
• B. Move synthesis to a larger-context model so all 38k tokens fit comfortably
• C. Keep passing the raw pages but add a prompt instruction telling synthesis to focus on the important parts
• D. Have synthesis re-fetch and re-summarize each page itself before combining them

A coordinator agent is asked to produce a migration plan for a 400,000-line legacy billing monolith. The engineer hard-codes an upfront decomposition into five subagent tasks (billing, invoicing, tax, reporting, auth). Production runs show the final plan omits an entire 'dunning' subsystem and a currency-conversion layer that no subagent was ever assigned. What is the most effective decomposition strategy?

• A. Raise the coordinator's maximum iteration count so it has more turns to notice the missing subsystems on its own
• B. Run an initial mapping pass that enumerates the repository's actual modules, then dynamically spawn one subagent per discovered component
• C. Expand the fixed list from five to twelve subagent tasks based on the engineer's prior knowledge of the billing domain
• D. Give the coordinator a larger context window so the entire monolith fits inside a single prompt

The coordinator spawns a subagent with a single Task call to trace how a payment webhook propagates through the orders module. Logs show the subagent re-runs Grep to rediscover the entrypoint the coordinator had already located two turns earlier, and reaches a conclusion that contradicts the coordinator's established finding. What is the root cause?

• A. The subagent's allowedTools list is missing the Task tool, so it cannot delegate the trace further
• B. The Message Batches API strips prior turns, so the multi-turn context was silently dropped
• C. Subagents do not inherit the coordinator's conversation, so prior findings must be passed explicitly in the Task prompt
• D. tool_choice was set to "auto" instead of forcing the Grep tool for the trace

An engineer runs --resume on a named exploration session from three days ago to continue a refactor. Since then a teammate moved several files and renamed a package. The resumed agent replays cached Read and Grep results from the old history and proposes edits against paths that no longer exist. What is the best way to continue the work?

• A. Use --resume but manually enlarge the context window so more of the stale history is retained
• B. fork_session from the three-day-old session to branch the work onto a new line
• C. Re-run the same session with /compact to shrink the stale tool outputs before editing
• D. Start a fresh session and inject a short summary of the prior conclusions, discarding the stale tool results

A security scan flags that the team's committed .mcp.json contains a hardcoded GitHub personal-access token used by an MCP server. The team wants the server config to stay shared and version-controlled, but each engineer (and CI) must supply their own credential without leaking it. What should they do?

• A. Encrypt the .mcp.json file and commit the encrypted blob, decrypting it at session start.
• B. Reference the credential as ${GITHUB_TOKEN} in .mcp.json so each environment supplies its own value from the environment at load time.
• C. Move the server to user-scoped ~/.claude.json so the token lives on a single trusted machine.
• D. Store the token in the project CLAUDE.md so it loads with memory and is easy to rotate.

The agent connects to a database MCP server to help engineers query a legacy schema. Traces show that before every real query it fires 6-10 exploratory tool calls (list_tables, describe_table, sample_rows) to rediscover what exists, adding seconds of latency and thousands of tokens per session. The schema changes rarely. What is the best way to reduce this overhead?

• A. Force tool_choice to "any" so the model commits to a productive tool sooner.
• B. Raise the context window so more exploratory results fit without truncation.
• C. Add a short-lived cache in front of the query tool so repeated probes return faster.
• D. Expose the schema catalog as an MCP resource the agent reads once upfront, instead of probing with repeated exploratory tool calls.

The team added a code-intelligence MCP server that does semantic, cross-file symbol search over an indexed monorepo. In practice the agent almost always reaches for the built-in Grep tool instead, so it misses semantically related call sites that don't share literal text. The MCP tool's description currently reads only "Search the code index." What is the most effective first step?

• A. Enrich the MCP tool's description with example queries and a note that it performs semantic, cross-file search that literal text matching misses, so the agent prefers it over Grep.
• B. Remove Grep from the agent's allowedTools so the MCP search tool is the only option.
• C. Add a CLAUDE.md rule instructing the agent to never use Grep for code search.
• D. Force tool_choice to the MCP search tool on every turn.

The agent is asked to rename a shared constant throughout a generated client file. Its Edit call fails with a non-unique-match error because the target string appears on many lines that must all be updated consistently, and no single surrounding context makes one occurrence unique. What is the correct way to complete the change?

• A. Switch to a Bash sed global substitution to bypass the Edit tool.
• B. Retry the identical Edit call with tool_choice forced so it applies despite the ambiguity.
• C. Delete the file and have the agent regenerate it from scratch with the new constant.
• D. Read the whole file, then Write it back with the modification, since Edit requires a unique match and this change spans repeated occurrences.

An engineer asks the tool to determine which of 30 services emits a particular Kafka event. Answering requires grepping and reading across dozens of files, producing thousands of lines of intermediate tool output. Done inline, this verbose discovery floods the main session's context and later steps degrade from lost-in-the-middle effects. What is the best approach?

• A. Increase the main session's context window so all of the intermediate tool output fits
• B. Delegate the discovery to an Explore subagent that returns only the concise finding, keeping the verbose output out of the main context
• C. Turn on plan mode so the tool plans the searches before it runs them
• D. Disable Grep and instead Read each candidate file directly in the main session

A senior engineer added the team's coding-convention instructions to ~/.claude/CLAUDE.md, and the tool follows them perfectly on her machine. A newly onboarded teammate clones the same repository, but the tool ignores those conventions for him. What is the correct fix?

• A. Move the conventions into the project's .claude/CLAUDE.md (or root CLAUDE.md) checked into version control, since user-level memory is personal and not shared via VCS
• B. Add the conventions to the teammate's ~/.claude.json MCP configuration so they load for him
• C. Convert the conventions into a Skill so they load on demand whenever they are relevant
• D. Register the conventions in a .claude/config.json commands array so they sync with the repository

A CI pipeline calls Claude Code to review each pull request, and a shell gate script greps stdout for the word "CRITICAL" to fail the build. The gate is flaky because Claude phrases severe findings differently each run — "severe issue," "major bug," "critical defect." What is the most effective fix?

• A. Add a post-processing library with a synonym dictionary that normalizes severity wording before the grep runs
• B. Invoke Claude with --output-format json plus a --json-schema so findings are emitted as machine-parseable structured fields the gate reads deterministically
• C. Instruct the prompt to "always use the exact word CRITICAL for severe issues" and rely on that wording
• D. Set temperature to 0 so the phrasing of findings stays stable between runs

In the pipeline, the same Claude Code session that generates an implementation also performs the automated review step. It consistently rates its own output clean, yet human reviewers keep finding real bugs it missed. What is the most effective change?

• A. Run the review in a separate, independent Claude Code instance that shares no context with the generating session
• B. Enable extended thinking on the generating session before it reviews its own code
• C. Instruct the generating session to "review critically and assume the code contains bugs"
• D. Lower the pass threshold so more borderline findings surface in the same session

Locally, the author's Claude generates tests that follow team conventions (naming, arrange-act-assert structure). In CI on a clean checkout, the generated tests ignore those conventions. The conventions are documented only in the author's ~/.claude/CLAUDE.md. What is the best fix?

• A. Pass the conventions as a --system-prompt argument in the CI command on every run
• B. Add the conventions to the CI build server's ~/.claude/CLAUDE.md so the runner picks them up
• C. Reproduce the author's local machine environment inside the CI job
• D. Move the conventions into the project's committed .claude/CLAUDE.md so every checkout — local and CI — loads them from version control

The project's always-loaded CLAUDE.md has grown to embed a long, detailed code-review rubric. That rubric is needed only by the review job, but it is now injected into every CI job — test generation, doc updates — inflating token cost and diluting the model's focus on those tasks. What is the best fix?

• A. Delete the rubric from CLAUDE.md and inline its full text into each review command invocation
• B. Split CLAUDE.md into two files and symlink the right one into place per job
• C. Keep the rubric in CLAUDE.md but wrap it in comment markers so it is visually separated
• D. Move the review rubric into an on-demand Skill under .claude/skills so only the review job loads it, keeping CLAUDE.md lean for always-on context

The CI reviewer posts naming-convention and style comments, but developers report that roughly 60% of these particular comments are wrong or trivial. They have started ignoring the bot entirely — including its genuine security findings. What is the most effective response?

• A. Add a single global confidence threshold so only comments the model rates above 0.8 are posted
• B. Temporarily disable the naming-convention category, then rewrite its prompt with explicit categorical rules before re-enabling it
• C. Route every comment through a human moderation queue before it is posted to the pull request
• D. Train a sentiment classifier on developer reactions and suppress whichever categories draw negative responses

The CI reviewer handles clear-cut defects well but is inconsistent on genuinely ambiguous cases — for example, whether a bare except: is acceptable in a one-off script versus a shared library. Enumerating every possible scenario in the prompt is impractical. What is the best approach?

• A. Add two to four few-shot examples of representative ambiguous cases, each with the reasoning behind its verdict
• B. Write an exhaustive list in CLAUDE.md of every code pattern and its correct verdict
• C. Fine-tune a dedicated model on the team's full history of past review decisions
• D. Lower the bar so every borderline case is flagged and pushed to a human reviewer

In the pipeline, Claude Code generates test cases and then, within the same session, reviews those tests for quality. The review almost never finds problems, yet audits show 20% of the generated tests have weak or tautological assertions. What explains this and what is the fix?

• A. Enable extended thinking in the same session so the self-review reasons more carefully before approving
• B. Have the same session review the tests three times and take a majority vote on each
• C. Add more detailed quality criteria to the existing session's review prompt
• D. A session reviewing its own output is biased toward confirming it, so have a separate, independent Claude instance review the generated tests

Production logs show that 8% of extraction responses fail the downstream JSON.parse() step because Claude wraps its output in markdown code fences or prepends a sentence like "Here is the extracted data:". Prompt tweaks reduced but did not eliminate the failures. What is the most reliable fix?

• A. Add a stern system-prompt line ("Return only valid JSON, no markdown, no commentary") and set temperature to 0 to make formatting deterministic.
• B. Define the target structure as a tool input_schema, force that tool via tool_choice, and read the structured JSON directly from the tool_use block.
• C. Post-process every response with a regex that strips markdown fences and leading prose before calling JSON.parse().
• D. Lower max_tokens so the model has no room to add explanatory prose around the JSON object.

After migrating to tool_use with a strict JSON schema, JSON parse failures dropped to zero. However, reconciliation shows 6% of extracted invoices have line-item amounts that do not sum to the stated invoice total. What does this reveal about schema-based structured output?

• A. The schema is misconfigured; adding "additionalProperties": false will force the line items to reconcile with the total.
• B. tool_choice should be "any" rather than forced so the model can self-correct the arithmetic before returning.
• C. Schema enforcement removes syntax and type errors but not semantic errors, so a downstream arithmetic validation check must flag or trigger a retry on mismatches.
• D. max_tokens is too low, so the model omits line items; raising it will make the totals add up.

For documents that lack a purchase-order number, audit logs show Claude inventing plausible-looking PO numbers about 11% of the time instead of signaling absence. Downstream systems then treat the fabricated values as real. What is the best schema-level fix?

• A. Add a required confidence float to every field so downstream code can discard PO numbers below a threshold.
• B. Switch tool_choice to "auto" so the model can decline to call the extraction tool when the PO number is missing.
• C. Add a few-shot example containing a correctly formatted PO number to anchor the expected pattern.
• D. Make the po_number field nullable in the schema and instruct the model to return null when the value is not present in the source.

The extraction schema uses an enum with six known values for document_type. A new vendor begins sending "credit memo" documents, which are not in the enum, and the model force-fits them to "invoice", corrupting downstream routing. What is the best design change?

• A. Add an "other" value to the enum plus an optional document_type_detail string so novel types are captured verbatim instead of misclassified.
• B. Remove the enum constraint entirely and let the model emit any free-text string for document_type.
• C. Fine-tune a dedicated document-type classifier and run it before extraction to assign the type.
• D. Brainstorm and add every conceivable document type to the enum so no future document falls outside it.

Extractions pass the JSON schema but sometimes violate a business rule (invoice_date later than due_date). The current recovery discards the result and re-runs the identical prompt from scratch; 40% of retries still fail the rule. What is the most effective retry strategy?

• A. Re-run the identical prompt up to five times and accept the first result that happens to pass the rule.
• B. Append the previous failed extraction and the specific validation error messages to a follow-up message, asking the model to correct only the offending fields.
• C. Lower temperature to 0 and re-run the original prompt exactly once.
• D. Move all rule violations to the Message Batches API and reprocess them overnight.

For scanned documents where the tax ID is physically cut off at the page edge and simply absent from the source text, the validation-retry loop retries five times and still fails, burning tokens on every attempt. What is the correct understanding of this situation?

• A. Raise the retry ceiling to ten; with enough attempts the model will eventually recover the tax ID.
• B. Enable extended thinking so the model reasons more deeply and reconstructs the missing tax ID.
• C. Retries can fix format and structural errors but cannot recover information absent from the source, so detect the absence, return null, and route the document to human review instead of retrying.
• D. Switch tool_choice to "any" so the model can select a different extraction tool that will locate the tax ID.

A 50,000-document extraction batch completes and 300 requests returned errors. The team needs to reprocess only the failures and reliably match every result back to its source document. What is the correct approach?

• A. Assign each request a custom_id mapping to its source document, correlate results by custom_id, and submit a new batch containing only the 300 failed custom_ids.
• B. Resubmit the entire 50,000-document batch, since batches are atomic and cannot be reprocessed partially.
• C. Rely on result ordering, since the Batch API guarantees that output order matches input order.
• D. Convert the 300 failures to synchronous calls and use response timestamps to align each result with its source document.

The pipeline handles six document types, each with its own extraction tool. Even when the type is already known from the intake folder that routed the document, the caller still sends all six tools with tool_choice "auto", and in 9% of cases the model invokes the wrong extractor. What is the best fix?

• A. Keep tool_choice "auto" but add sentiment analysis of the document to help the model decide which extractor fits.
• B. When the document type is already known from routing, force the specific extractor with tool_choice {"type": "tool", "name": "extract_invoice"} rather than leaving selection to "auto".
• C. Set tool_choice to "any" so the model is at least required to call some extraction tool.
• D. Merge all six extraction tools into one large tool with a combined schema covering every document type.