Domain 2 – Questions

Q9. The team wants formatting to run automatically after Claude Code Write/Edit operations. Use: A) A CLAUDE.md rule B) Ask Claude nicely per session C) A skill describing formatting D) A PostToolUse hook matching Write|Edit running the formatter

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 .claude/hooks/format_changed_file.py"
          }
        ]
      }
    ]
  }
}

# .claude/hooks/format_changed_file.py
# Illustrative formatter hook. Requires prettier in the project's node_modules.
import json
from pathlib import Path
import subprocess
import sys

payload = json.load(sys.stdin)
project = Path(payload["cwd"]).resolve()
raw = Path(payload["tool_input"]["file_path"])
file = (raw if raw.is_absolute() else project / raw).resolve()
if not file.is_relative_to(project):
    raise ValueError("Changed file is outside this project")
if file.suffix in {".js", ".jsx", ".ts", ".tsx", ".json", ".css"}:
    subprocess.run([str(project / "node_modules/.bin/prettier"), "--write", str(file)], check=True, cwd=project)

Q10. Shared repo conventions (build commands, style rules) belong in: A) The project's CLAUDE.md checked into git B) Each engineer's settings.local.json C) A slash command D) ~/.claude/CLAUDE.md

Q11. A 20-line prompt the team runs daily with one variable (a ticket id) should become: A) Rely only on automatic skill matching B) An explicitly invoked slash command with $ARGUMENTS (including one provided by a skill) C) A hook D) A subagent

---
description: Review a ticket using the team checklist
---
Review ticket $ARGUMENTS.
Confirm the reported problem, available evidence, and proposed next step.
Do not change the ticket; return your findings.

Q12. Claude Code in CI must run tests while network access and pushing are blocked. Enforce via: A) Narrow tool permissions, restricted credentials, and a network sandbox/egress policy, with hooks for additional checks B) --dangerously-skip-permissions C) Trusting the model D) Prompt instructions

Q13. Code review keeps bloating the main session's context. The canonical fix: A) /compact more often B) A read-only reviewer subagent with its own context window C) A bigger model D) Shorter diffs

Q14. In CI, which gate may be blocking? A) Deterministic checks (tests, lint) — with AI review as advisory comments B) Claude's subjective code-quality opinion C) Nothing D) Any AI output

Q41. A developer on a shared repo wants her Claude Code sessions in this one project to run claude-haiku for cheap bulk edits — but the override must never reach teammates through git. A) Put "model": "claude-haiku-4-5" in <repo>/.claude/settings.json B) Put "model": "claude-haiku-4-5" in <repo>/.claude/settings.local.json C) Add "prefer haiku for this repo" to the project CLAUDE.md D) Put the model key into the enterprise managed policy file

{
  "model": "claude-haiku-4-5"
}

Q42. Mid-session, nobody typed /go-live, yet the go-live skill's checklist loaded and the ship procedure ran. Which statement names who chose and who executed — exactly? A) The user chose it; Claude Code executed it B) The model chose it; the model executed it C) Nobody chose it; the harness fired it on a lifecycle event D) The model chose it; Claude Code executed it

---
name: review-diff
description: Review a code diff and report actionable correctness issues.
context: fork
agent: Explore
---
Inspect the relevant diff and surrounding code without making changes.
Return each finding with its file location, evidence, and practical impact.

Q43. The team re-types the same 20-line release-checklist prompt several times a week, varying only the target environment. Every option below can deliver that text into a session — which is the guidance choice? A) A slash command at .claude/commands/release.md using $ARGUMENTS for the environment B) A skill whose description matches "release" so the model loads it C) Paste the checklist into the project CLAUDE.md so it is always present D) A subagent whose system prompt is the checklist

---
description: Review a ticket using the team checklist
---
Review ticket $ARGUMENTS.
Confirm the reported problem, available evidence, and proposed next step.
Do not change the ticket; return your findings.

Q44. Reviewers keep merging unformatted generated code. Each option below can produce formatted output — which one automatically runs after matching Write/Edit operations? A) Add "always run prettier after edits" to the project CLAUDE.md B) A skill the model loads when formatting seems relevant C) A PostToolUse hook matching Write|Edit that runs prettier on the written file D) A slash command /format that authors run before pushing

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "python3 .claude/hooks/format_changed_file.py"
          }
        ]
      }
    ]
  }
}

# .claude/hooks/format_changed_file.py
# Illustrative formatter hook. Requires prettier in the project's node_modules.
import json
from pathlib import Path
import subprocess
import sys

payload = json.load(sys.stdin)
project = Path(payload["cwd"]).resolve()
raw = Path(payload["tool_input"]["file_path"])
file = (raw if raw.is_absolute() else project / raw).resolve()
if not file.is_relative_to(project):
    raise ValueError("Changed file is outside this project")
if file.suffix in {".js", ".jsx", ".ts", ".tsx", ".json", ".css"}:
    subprocess.run([str(project / "node_modules/.bin/prettier"), "--write", str(file)], check=True, cwd=project)

Q45. The model key is set in user settings, shared project settings.json, settings.local.json, and a CLI flag, while the managed policy pins permissions. For settings keys, what is the precedence chain, strongest first? A) project settings > settings.local.json > CLI flags > user settings > managed policy B) CLI flags > managed policy > settings.local.json > project settings > user settings C) managed policy > settings.local.json > CLI flags > project settings > user settings D) managed policy > CLI flags > settings.local.json > project settings > user settings

Q46. A session opens at the root of a monorepo carrying an enterprise CLAUDE.md, a user CLAUDE.md, a project CLAUDE.md, a nested packages/api/CLAUDE.md, and .claude/rules/terraform.md with paths: ["terraform/**/*"] frontmatter. What is in context at session start? A) Enterprise + user + project memory all load together as a union; the nested file and the paths-scoped rule join only when work touches their subtree or matching files B) Only the project CLAUDE.md — the most specific memory file overrides the rest C) All five files — memory always loads in full at session start D) Only the enterprise file — the top layer overrides everything beneath it

Q47. Official docs describe skills as "model-invoked." Decoded exactly, the term means: A) the model executes the skill's bundled scripts itself, inside its own inference B) the model CHOOSES the skill by reading its frontmatter description, and Claude Code — the harness — performs the invocation C) the skill only runs when the user invokes it by typing /name D) the harness selects the skill deterministically when a lifecycle event fires

---
name: review-diff
description: Review a code diff and report actionable correctness issues.
context: fork
agent: Explore
---
Inspect the relevant diff and surrounding code without making changes.
Return each finding with its file location, evidence, and practical impact.

Q48. In SKILL.md frontmatter, context: fork (with an agent: key on its own line beneath it) means exactly: A) the skill clones the repository into a temporary git worktree before running B) the skill runs concurrently with the main conversation and merges its transcript back in C) the skill forks a full copy of the current session, history included, and continues both D) the skill body runs in an isolated subagent context — the named agent executes it there, so verbose output never pollutes the main conversation; omitting context loads the body inline, the default

---
name: review-diff
description: Review a code diff and report actionable correctness issues.
context: fork
agent: Explore
---
Inspect the relevant diff and surrounding code without making changes.
Return each finding with its file location, evidence, and practical impact.

Q49. A public repo has the @claude workflow committed and ANTHROPIC_API_KEY in secrets. Maintainers' @claude comments trigger runs, but when an outside contributor comments "@claude fix this," nothing happens at all. Root cause? A) The API key is missing from the contributor's fork B) The workflow file lacks the pull_request_review_comment event C) The Action checks the commenter's permission before running — the contributor lacks write access, the deliberate gate against drive-by prompt injection via public comments D) The pinned model version has been deprecated

Q50. A developer's local sessions always follow her personal conventions — concise answers, vitest over jest — but headless @claude runs on GitHub ignore them completely while still honoring every rule in the repo's CLAUDE.md. Root cause? A) The Actions runner only checks out the repo — project CLAUDE.md, settings, rules, and skills load, but her ~/.claude/CLAUDE.md user layer does not exist in CI; on GitHub, the committed layers are the only voice B) Headless mode disables the memory system entirely, so any CLAUDE.md compliance is coincidental C) The enterprise managed policy strips user memory from CI runs D) Her conventions file is missing the frontmatter that marks it CI-eligible

Q250. A legal-research group runs Claude Code sessions that last most of a working day. Auto-compaction regularly kicks in, and afterwards the case citations Claude gathered early on are gone from the conversation. The group wants a script that pulls every citation out of the transcript at the exact point before anything is summarised, whether a person typed the command or the context limit triggered it. On which hook event should the script be registered? A) Stop, because it fires each time Claude finishes a response and can therefore scan the transcript frequently B) SessionEnd, because it fires once the session closes and can read the complete transcript in one pass C) UserPromptSubmit, filtering for prompts whose text starts with the compaction slash command D) PreCompact with no matcher, so it runs before both manual and automatic compaction and receives the transcript path

{
  "hooks": {
    "PreCompact": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 .claude/hooks/extract_citations.py"
          }
        ]
      }
    ]
  }
}

Q251. A data-science platform requires every Python file to use a 100-character line limit, and the build fails on anything else. The rule sits in the committed project CLAUDE.md. A contractor's personal instruction file says "wrap at 79 characters", and several of the contractor's sessions have produced files that failed the build. Which statement about fixing this is exactly right? A) Adding a lineLength key to the committed .claude/settings.json makes Claude Code enforce the width on every generated file B) Any CLAUDE.md level is guidance the model weighs; a PostToolUse hook on Write and Edit that runs the formatter makes the width deterministic C) Project CLAUDE.md is loaded after the personal file, so it deterministically overrides it and the failures must come from something else D) Moving the rule into an organisation-wide managed CLAUDE.md guarantees compliance because users cannot override managed instructions

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs ruff format --line-length 100"
          }
        ]
      }
    ]
  }
}

Q252. A mobile team's CLAUDE.md says "new screens must support accessibility." Claude Code keeps producing screens where a single icon has a content description, while buttons have no labels and touch targets are too small. Tests and CI are already configured. What is the root cause of the thin results? A) The instruction names a goal but no observable criteria, so Claude meets it minimally; it needs checkable requirements that tests can verify B) The instruction must live in a .claude/rules file to become binding, since CLAUDE.md content is treated as optional background C) CLAUDE.md is only consulted for files at the repository root, so screen files in nested folders never see the instruction D) Claude Code drops CLAUDE.md after each compaction, so the instruction fades as the session grows longer

Q253. A game studio keeps separate standards for shader code, level data files and localisation strings. A lead put each standard in its own file under .claude/rules/ so that only the relevant one would be in context while Claude works in that area. None of the files has frontmatter. What actually happens? A) All three files load at the start of every session, so every standard is in context regardless of what is edited B) Claude Code infers the scope from each file name and loads it only for folders with a matching name C) Each file stays dormant until a CLAUDE.md imports it, so none of the three standards reaches Claude D) Claude Code refuses to start and reports that every rules file requires a paths header

---
paths:
  - "shaders/**"
  - "**/*.hlsl"
---
# Shader standards
- Use half precision for colour values unless a comment justifies float.
- Every shader declares its target profile at the top.

Q254. A Go team registers gofmt -w on the edited file as a PreToolUse hook matching Edit and Write, expecting every file Claude touches to end up formatted. After a week, files Claude modified are still unformatted in review. What is the cause? A) Formatting is only applied when the requirement is written in CLAUDE.md so that Claude runs the tool itself B) Hooks cannot launch external binaries, so gofmt is skipped and only built-in checks run C) The matcher must be Bash because formatters are shell commands, so an Edit matcher never fires D) PreToolUse runs before the edit is applied, so gofmt formats the old file and Claude's change lands afterwards

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs gofmt -w"
          }
        ]
      }
    ]
  }
}

Q255. At a fintech company, two developers each start a Claude Code session in the same checkout: one upgrades the logging library, the other adds a new report endpoint on a different branch. Within an hour one session's test run picks up the other's half-written files, and a branch switch in one session changes the files the other is editing. What is the underlying cause and fix? A) Claude Code does not support concurrent sessions; run the two tasks one after the other in a single session B) The two sessions share a single context window; clear the conversation in each session before switching tasks C) Both sessions lack a lock file in settings; enable file locking so edits from one session are hidden from the other D) Both sessions share one working directory; give each its own git worktree on its own branch and run one session per worktree

git worktree add ../app-logging -b chore/logging-upgrade
git worktree add ../app-report -b feat/report-endpoint
cd ../app-logging && claude   # session one
cd ../app-report && claude    # session two

Q256. An API rename means the client docs for four language SDKs (Python, Go, Java, Ruby) must all be rewritten, and each rewrite requires reading that SDK's source in depth. Holding all four codebases in one conversation would exceed the context window, and the work should run at the same time. Which plan meets both constraints? A) Run one session over all four SDKs in turn and compact the conversation between each language B) Start four sessions in the same checkout, each switching to its own branch before it begins editing C) Create a git worktree per SDK and run one Claude Code session in each, then merge the four branches D) Create one skill with forked context that walks through all four SDKs inside a single forked run

Q257. A health-records team requires every new database migration to be named V__.sql. Claude Code usually complies, but about one migration in ten gets a name like V3__AddTable.sql, which breaks the deploy tool. A teammate proposes adding three good and three bad examples to the project CLAUDE.md. What change actually guarantees non-conforming names never land? A) Create a .claude/rules file scoped to the migrations folder that restates the naming pattern with examples B) Add a PreToolUse hook on Write that checks the file path against the pattern and exits with code 2 and a reason C) Add the six examples to CLAUDE.md with the heading IMPORTANT so the model weighs them above other guidance D) Ask a review subagent at the end of each session to list any migrations whose names do not match the pattern

import json, re, sys

event = json.load(sys.stdin)
path = event.get("tool_input", {}).get("file_path", "")
name = path.rsplit("/", 1)[-1]
if "/migrations/" in path and not re.fullmatch(r"V\d{12}__[a-z0-9_]+\.sql", name):
    print(f"Migration name {name} must match V<yyyymmddHHMM>__<snake_case>.sql", file=sys.stderr)
    sys.exit(2)
sys.exit(0)

Q258. Before changing how permissions are checked in a large Rails monolith, a developer asks Claude Code how authorization works. The logic is spread across concerns, mixins, callbacks and a policy layer in roughly thirty files. Claude opens two files and gives a confident but partial answer. Which approach gives a thorough answer without filling the main conversation with file dumps? A) Paste the full list of thirty file paths into the prompt and ask Claude to read all of them in this session B) Run the compaction command first so that the main conversation has more room for the files it reads C) Enable extended thinking so Claude reasons more carefully about the two files it has already read D) Delegate the tracing to the Explore subagent, asking it to follow every call path and return a summary

Q259. A nightly job runs claude -p with the prompt "Confirm every feature flag in flags.yaml is still referenced in the code" and a JSON output format. It reports "all flags in use" every night, yet engineers keep finding dead flags. What is the most likely cause? A) A single instance cannot check itself; a second headless instance must confirm every verdict the first one gives B) The prompt asks for a verdict with no required evidence, so Claude samples some flags and generalises; require each flag listed with the file and line where it is used C) The JSON output format truncates long answers, so the list of unused flags is cut off before it is printed D) Print mode runs without file tools, so Claude answers from the prompt text alone and never reads flags.yaml

claude -p "For EVERY key in flags.yaml, search the source tree.
Return JSON: [{\"flag\": ..., \"references\": [\"path:line\", ...]}].
A flag with an empty references list is UNUSED. Do not summarise; list every flag." --output-format json

Q260. Compliance at an insurance firm states that Claude Code must never open files under the secrets/ folder in any engineer's session. The rule is currently a sentence in the project CLAUDE.md, and one engineer's personal instruction file tells Claude to "read whatever you need to finish the task." Where should the rule live so that it holds in every session? A) In a CLAUDE.local.md at the repository root, because it is read last and overrides earlier instruction files B) In the committed .claude/settings.json as a deny rule on reading secrets/, backed by a hook for shell access C) In an organisation-wide managed CLAUDE.md, because personal instruction files cannot remove managed instructions D) In a .claude/rules file with paths set to secrets/, so the prohibition loads whenever those files come up

{
  "permissions": {
    "deny": [
      "Read(./secrets/**)",
      "Edit(./secrets/**)",
      "Bash(cat secrets/*)"
    ]
  }
}

Q261. A platform engineer wrote a release-notes skill that drafts notes from merged pull requests, and it works well on her laptop. Teammates who pulled the latest main branch report that it does not exist for them. She had saved it at ~/.claude/skills/release-notes/SKILL.md. What is the simplest change that gives it to everyone who clones this repository? A) Register the skill by name in the project settings file so that Claude Code knows to load it for all users B) Paste the skill body into the project CLAUDE.md so that it is loaded into every teammate's sessions C) Add a user-invocable line to the skill frontmatter so that it becomes visible to users other than its author D) Move it to .claude/skills/release-notes/SKILL.md inside the repository and commit that directory

Q262. A consultant opens Claude Code inside a client's repository, which is cloned under a shared workspace folder. Claude starts insisting on a changelog entry for every change, and nothing in the repository says so. The consultant suspects an instruction file somewhere above the repository. Which command answers this directly inside the running session? A) /doctor, which checks the installation and reports problems with the Claude Code setup B) /memory, which lists the instruction files loaded for the session and lets you open each one C) /clear, which empties the conversation so the session starts again without inherited instructions D) /init, which scans the repository and writes a CLAUDE.md describing the conventions it finds

Q263. A design-system repository keeps Storybook story files next to their components, as Card.stories.tsx beside Card.tsx, across about sixty folders at different depths. The team wants its story-writing conventions applied only when Claude works on story files. Which setup does that? A) An import line in the root CLAUDE.md that pulls in a separate story-conventions file at startup B) A CLAUDE.md inside src/ with the story conventions, so they load whenever Claude works under that folder C) A rules file whose paths list is ["**/.stories.tsx"], so it applies to story files at any depth D) A rules file whose paths list is ["src/.stories.tsx"], so it applies to story files under the source folder

Q264. A team lead wrote the team's commit-message convention into her own ~/.claude/CLAUDE.md, and her sessions follow it perfectly. The CI job that runs claude -p on a build runner to prepare release commits ignores the convention entirely, and so do her teammates' sessions. What explains this? A) Print mode skips every instruction file, so headless runs never see conventions from any CLAUDE.md B) User-level instructions apply only after they are imported from the project CLAUDE.md of each repository C) User-level instructions load only in interactive sessions that are started by the same account that created the file D) The file lives in her home directory on her machine, so the runner and teammates never have it; it belongs in the committed project CLAUDE.md

Q265. A dependency-audit skill lists every transitive package, its licence and its known advisories, often thousands of lines. After running it, developers find Claude drifting toward the audit instead of the feature they were building. The team adds context: fork to the skill's frontmatter. Which statement about that change is exactly right? A) It runs the skill in a separate subagent context and returns only the final result to the main conversation B) It switches the skill to a smaller model, which produces shorter output and therefore less clutter in the session C) It stops Claude from invoking the skill automatically, so the audit only runs when a user types its name D) It copies the whole current conversation into the skill so the audit can use everything discussed so far

---
name: dependency-audit
description: Audit transitive dependencies for licence and advisory issues.
context: fork
---
List every transitive dependency with licence and known advisories.
Return only: packages needing action, why, and the suggested fix.

Q266. A developer must add account deletion to a SaaS product. Legal rules about what must be kept for audit, how backups are handled, and how long invoices are retained are not written down anywhere; only the developer and a lawyer know them. Before any code is written, what is the best way to bring the unstated constraints into the design? A) Ask Claude to scan the existing deletion jobs and infer the legal retention rules from how the code behaves today B) Start with a failing end-to-end deletion test and let each failure reveal which data and systems are involved C) Ask Claude to interview the developer with targeted questions about retention, backups and audit needs, then write a spec from the answers D) Ask Claude to compare three open-source account-deletion libraries and recommend the one with the most features

Q267. The team replaced an old logging helper and updated the project CLAUDE.md last week. Everyone's sessions now use the new helper except one developer's, which still writes calls to the old helper. That developer has pulled the latest main. The lead suspects a personal or local instruction file still describes the old helper. Which step confirms or rules out that suspicion before anything is edited? A) Make the new-helper instruction in the project CLAUDE.md more emphatic and see whether the behaviour changes B) Have the developer delete the whole ~/.claude directory so that only the project configuration remains C) Ask Claude in that session which logging helper it should use, and compare its answer with the project file D) Run /memory in that developer's session and check each loaded file for the outdated logging instruction

Q268. An incident-response team writes postmortems with twelve required sections. Engineers paste their own saved versions of a long drafting prompt into Claude Code, and the versions have drifted so some drafts miss sections. The team wants one versioned procedure anyone can run on demand with an incident ID. What should they build? A) Give each engineer a shell alias that runs Claude Code headless with the drafting prompt from a local text file B) Put the full drafting prompt in the root CLAUDE.md so it is present in every session for every engineer C) Add a rules file scoped to postmortems/** so the drafting procedure appears whenever those files are opened D) Create a committed project skill such as .claude/skills/postmortem/SKILL.md with an argument hint for the incident ID

---
name: postmortem
description: Draft a postmortem with all twelve required sections for an incident.
argument-hint: <incident-id>
---
Draft the postmortem for incident $ARGUMENTS.
Include every section: summary, impact, customer impact, timeline, detection,
root cause, contributing factors, what went well, what went poorly, actions,
owners, follow-up dates. Mark any section with missing data as TODO.

Q269. A developer has four tasks queued for Claude Code this afternoon. Which one most warrants starting in plan mode rather than asking for the change directly? A) Bump one library by a patch version exactly as a published security advisory instructs B) Move app state from a global store to a server-cache library across seventy components, with several possible migration orders C) Correct a misspelled word in one user-facing error message that a support ticket quoted exactly D) Rename a confusingly named local variable inside a single function that already has full test coverage

Q270. A monorepo's 700-line CLAUDE.md mixed Go, SQL, Helm and front-end conventions, and Go error-handling advice kept appearing in SQL files. The team split it into four files and added an import line for each at the top of the root CLAUDE.md. The bleed continues exactly as before. What is the root cause? A) Imported files are pulled in at launch, so all four sets are in context for every file; conditional loading needs rules files with paths globs B) A user-level instruction file loaded before the project file is repeating the Go advice in every session C) Imported files are loaded only after a matching file is opened, so the conventions arrive too late to shape the edit D) Import lines only resolve absolute paths, so the four files silently fail to load and older cached copies are used

Q271. A consultancy uses one repository and Claude Code to produce reports for many clients. A regulated bank needs British spelling, a mandatory risk-disclosure section and a stricter source policy, but only for its own reports; every other client keeps the defaults in the root CLAUDE.md. Analysts start each job from the client's folder. Which configuration fits? A) Add the bank's rules as environment variables in the project settings file so that they are applied to each run B) Create clients/bank/CLAUDE.md with the extra rules, so jobs started in that folder load it on top of the root defaults C) Add an "if the client is the bank" block to the root CLAUDE.md so the model applies the stricter rules when it recognises that client D) Put the bank's rules into each analyst's personal instruction file so that every report they write follows them

Q272. A database team defines three Claude Code subagents: schema-reader should only inspect code, migration-writer creates migration files, and release-runner executes the deploy script. In a trial, schema-reader edited a file while "helpfully" fixing a typo. How should the team make sure each subagent can only use the tools of its role? A) Give all three subagents every tool and have the main agent route tasks so that each role gets suitable work B) Add a deny rule for Edit and Write to the project settings so that no agent in the session can modify files C) Add a sentence to each subagent's system prompt stating which tools it may use and which it must avoid D) Set the tools field in each subagent's definition, for example Read, Grep and Glob only for schema-reader

---
name: schema-reader
description: Inspects schema and data-access code and reports findings. Never modifies files.
tools: Read, Grep, Glob
---
You analyse database schema and queries and report findings with file references.

Q273. A billing agent built on the Agent SDK can call an issue_refund tool. Finance now requires a named approver to sign off every refund before money moves; the agent should still identify refunds and prepare them. Which change meets the requirement? A) Keep issue_refund but cap each run at one turn so the agent can issue at most a single refund per conversation B) Keep issue_refund and add a system prompt rule saying the agent must never issue a refund without approval C) Keep issue_refund and add a PostToolUse hook that notifies the approver about each refund as soon as it is issued D) Remove issue_refund from the agent and give it a propose_refund tool that only writes a pending request to the approval queue

from claude_agent_sdk import ClaudeAgentOptions

options = ClaudeAgentOptions(
    mcp_servers={"billing": billing_server},
    allowed_tools=[
        "mcp__billing__lookup_order",
        "mcp__billing__propose_refund",
    ],
    disallowed_tools=["mcp__billing__issue_refund"],
)

Q274. A custom agent loop built on the Messages API triages support tickets. Its registry currently offers eight tools, including refund_order, close_account and reset_password, and a new tool is added most months. The triage job needs only read_ticket, search_kb and add_label. A security review asks for a configuration that stays safe as the registry grows. Which one? A) Build the request's tools array from an explicit list of read_ticket, search_kb and add_label, so nothing else is ever offered B) Offer every registry tool except refund_order, close_account and reset_password, which are filtered out by name C) Offer every registry tool and log each call to a restricted tool so the security team can review misuse weekly D) Offer every registry tool and state in the system prompt that only the three triage tools may be used

TRIAGE_TOOLS = ["read_ticket", "search_kb", "add_label"]

def tools_for_triage(registry):
    return [registry[name] for name in TRIAGE_TOOLS]

response = client.messages.create(
    model=MODEL,
    max_tokens=1024,
    tools=tools_for_triage(REGISTRY),
    messages=messages,
)

import os
from typing import Annotated

import anthropic
from anthropic import beta_tool
from pydantic import Field

from app.tickets import service  # your own ticket service

client = anthropic.Anthropic()  # reads ANTHROPIC_API_KEY
MODEL = os.environ.get("CLAUDE_MODEL", "claude-sonnet-5")


@beta_tool(name="add_label", description="Add one triage label to a ticket.")
def add_label(
    ticket_id: Annotated[str, Field(description="The ticket id, e.g. T-2291.")],
    label: Annotated[str, Field(description="One label from the triage list, e.g. billing.")],
) -> str:
    return service.add_label(ticket_id, label)


# read_ticket, search_kb, close_ticket, issue_refund are defined the same way
REGISTRY = {t.name: t for t in [read_ticket, search_kb, add_label, close_ticket, issue_refund]}
TRIAGE_TOOLS = ["read_ticket", "search_kb", "add_label"]


def triage(messages: list) -> object:
    runner = client.beta.messages.tool_runner(
        model=MODEL, max_tokens=1024,
        tools=[REGISTRY[name] for name in TRIAGE_TOOLS],  # only these exist for this agent
        messages=messages,
        max_iterations=8,
    )
    return runner.until_done()

{
  "name": "add_label",
  "description": "Add one triage label to a ticket.",
  "input_schema": {
    "type": "object",
    "properties": {
      "ticket_id": {"type": "string", "description": "The ticket id, e.g. T-2291.", "title": "Ticket Id"},
      "label": {"type": "string", "description": "One label from the triage list, e.g. billing.", "title": "Label"}
    },
    "required": ["ticket_id", "label"],
    "additionalProperties": false
  }
}