CCAR-F practice questions: Claude Code workflows.

What belongs in a project's CLAUDE.md file?

• Build and test commands, project conventions, and gotchas Claude needs on every task, kept short
• Environment variables and service credentials the project needs, so Claude can run commands without asking
• The full architecture documentation and API references, so Claude has complete knowledge in every session
• A running log of past sessions and their outcomes, so Claude can pick up where the last one ended

A team wants every file Claude Code edits to be run through the formatter, without relying on the model to remember. Which mechanism is right?

• A custom slash command that formats the tree, which the developer runs at the end of a session
• A formatting subagent that the main session delegates to once the edits are complete
• A CLAUDE.md instruction asking Claude to run the formatter after each edit it makes
• A PostToolUse hook matched to the edit tools that runs the formatter on the changed file

How would you run Claude Code non-interactively inside a CI job?

• A subagent launched from a developer's local session, with the CI job waiting on its result
• Print mode with the -p flag, passing the prompt and a restricted allowed-tools list
• An interactive session on the runner with the permission mode set to accept every action
• A plan-mode session, since planning does not edit files and so needs no approvals

A session has been running for hours and answers are getting worse and slower. What is the first thing to try?

• Switch the session to a larger model so it can hold more of the accumulated conversation
• Paste the full transcript so far back in as a new user message so nothing is lost
• Compact or clear the context, then re-brief the task with only what the next step needs
• Disable hooks for the rest of the session, since each hook adds latency to every tool call

A developer complains Claude Code re-explores the codebase every session. The cheapest fix is:

• A subagent that explores the codebase and reports back at the start of each session
• A memory file the developer pastes into the first message of every session
• A longer first prompt each session that walks through the directory layout
• A CLAUDE.md with the project's structure, commands, and conventions

You want Claude Code to plan before it edits on a large refactor. Which feature matches?

• Plan mode, which explores and proposes an approach before any file changes
• Headless mode with a prompt asking for a written plan and no tool access
• A PreToolUse hook that rejects edit calls until a plan file exists in the repository
• A custom slash command that runs the test suite before each edit is applied

A repeated workflow, 'update the changelog from recent commits', should be one command. Which Claude Code feature?

• A subagent dedicated to changelog work, invoked from the main session
• A PostToolUse hook on git commit that appends the message to the changelog
• A custom slash command or skill that captures the prompt and steps
• An MCP server exposing a changelog tool that reads the git history

Which permission approach is right for a shared CI runner using Claude Code?

• Accept every tool call automatically, since no developer is present to approve
• Deny every tool so the run is a pure text response with no side effects
• An explicit allow list of tools and commands, with no interactive approvals
• Prompt the developer who pushed the commit for each tool approval via chat

Where does an MCP server configuration belong when it should apply to everyone working in the repository?

• In each developer's user-level settings, synced through a dotfiles repository
• In the project-scoped configuration checked into the repository
• In a SessionStart hook that registers the servers when Claude Code launches
• In the system prompt for the session, listed as servers Claude should connect to

A hook that blocks a tool call should communicate the reason. Why?

• So the block is written into the transcript for the developer to review later on
• So the hook's exit code can be mapped to the right billing category
• So the model can override the block when the reason does not apply
• So the model can adjust its plan instead of retrying the same blocked action

Which task is a good fit for a Claude Code subagent?

• A large, self-contained investigation whose details would clutter the main session
• Changing the permission settings so the main session can run a tool
• Reading CLAUDE.md at the start of a session and summarizing its rules back to the user
• Applying a one-line change that the main session has already located

A team notices Claude Code sometimes runs the test suite three times in a row. Which is the right lever?

• Removing the test command from the allowed tools and running tests in CI instead
• Increasing the max turns so the session can finish before the loop is cut off
• A hook or CLAUDE.md rule defining when tests run, plus a check of the loop for missing stop conditions
• A stricter system prompt telling Claude to run the tests only once per task

What does the /compact style operation do in a long session?

• Trims tool results from the transcript but keeps every user and assistant turn
• Summarizes the conversation so far to free context while keeping the essentials
• Switches to a model with a larger window so the session can continue
• Restarts the session with the same CLAUDE.md loaded and an empty conversation history

A developer wants Claude Code to stop before committing so they can review. Best approach?

• A CLAUDE.md line asking Claude to confirm with the user before running git commit
• Keep commit outside the allowed actions, or gate it with a hook that requires confirmation
• A PostToolUse hook on git commit that opens the diff for the developer to review
• Run the whole session in plan mode so no commands execute until the developer approves the plan

Which of these belongs in CLAUDE.md rather than a subagent or a skill?

• The linter command and a note that the tests need the local database running
• The API keys for the staging environment so tests can run end to end
• A 200-page design document describing every subsystem in the product and how they connect
• A weekly status report template the team fills in every Friday

You need Claude Code to review a pull request in CI and post comments, with no ability to push code. Which controls?

• Interactive mode on the runner so a reviewer can approve each tool call
• Print mode with full permissions, relying on the prompt to say 'do not push code'
• Print mode with a read-only tool allow list and the git push command denied
• Plan mode, since planning cannot push code and can still read the diff

A Claude Code session is asked to fix a bug and, without being asked, refactors three unrelated files. What reduces this?

• A larger context window so Claude can see why the other files are unrelated
• A PostToolUse hook that reverts any edit outside the file named in the prompt
• Running the fix headless so there is no room for exploratory editing
• Explicit scope in the prompt, CLAUDE.md conventions about minimal diffs, and plan mode for review

What is the purpose of a PreToolUse hook?

• Compact the context when a tool result is too large
• Inspect or block a tool call before it executes
• Run a command after the model has finished its response
• Swap the model for a cheaper one on routine tool calls

A monorepo has several services with different test commands. Where should that live for Claude Code?

• A subagent per service that carries that service's commands in its own prompt
• The first message of each session, restated whenever the service changes
• CLAUDE.md, with a short per-service map of test commands and conventions
• The repository README, which Claude Code reads automatically at session start

Which hook event would you use to run a security scan on every file Claude writes?

• A slash command the developer runs after each session to scan changed files
• A PreToolUse hook on the Read tool, so files are scanned before Claude opens them
• A PostToolUse hook matched to the Write and Edit tools, run after each change lands
• A Stop hook that scans the whole working tree once when Claude finishes its turn and reports findings

A developer wants Claude Code to ask before running any command that touches the network. Which setting?

• Permission rules that allow safe commands and require confirmation for matching network commands
• A CLAUDE.md instruction telling Claude to ask for confirmation before any command that reaches the network
• A PostToolUse hook on Bash that inspects the command for network calls and logs a warning
• Plan mode for the whole session, so every command is proposed before it is executed

What is the benefit of committing project-scoped MCP configuration to the repo?

• It lets the repo's MCP servers override the user's own server settings for the project
• Every contributor gets the same integrations without manual setup on each machine
• Claude Code caches the server tool lists in git, which speeds up session start
• Server credentials travel with the code, so contributors do not need their own tokens

Claude Code proposes a plan that touches an unrelated module. What is the right response in plan mode?

• Accept the plan, then revert the unrelated edits during code review
• Revise the plan's scope before any edits are made to the tree
• Run the test suite first to see whether the extra module is affected
• Exit plan mode and let Claude discover the right scope as it edits

Which is a sensible use of a Claude Code skill?

• A packaged procedure like 'write a release note from merged PRs' with its own instructions and helper files
• A per-task override that switches the session to a different model for that procedure
• A place to store the API keys and tokens the procedure needs, loaded only when invoked
• A replacement for CLAUDE.md that holds all project conventions and commands in a single file loaded on demand

You want a nightly job where Claude Code triages new issues and labels them. Which pieces?

• Print mode in a scheduled job with a read-only tool set plus one allowed labeling action
• A PostToolUse hook that fires whenever a new issue is created and labels it in place
• A subagent with full permissions, invoked from a cron entry with the issue list as input
• An interactive session left open overnight with auto-accept enabled for all tool calls

A PreToolUse hook exits with code 2 on a tool call. What should happen?

• Claude Code ends the session so the developer can inspect the hook's output manually
• The call is blocked and the hook's message is surfaced so the model can adjust
• The hook is disabled for the rest of the session and the call is retried once
• The call proceeds and the hook's stderr is shown to the user, as with other non-zero exits

Which practice keeps a long Claude Code session productive?

• Pasting the previous session's transcript at the start so no earlier decision is lost
• Keeping one session open so the model keeps every file it has read
• Clearing or compacting between unrelated tasks and re-briefing the next task
• Disabling hooks mid-session so tool calls complete with less overhead

What should a team review when a Claude Code change is opened as a pull request?

• The test output only, because a green suite proves the change is correct
• The diff, the tests it ran, and whether the scope matched the request
• Whether the CLAUDE.md conventions were followed, with the diff left to CI
• The commit message and the model version, since the diff itself was generated

Which is the right place for a rule like 'never edit files under vendor/'?

• A README section, since Claude Code reads project documentation before it edits
• CLAUDE.md for guidance plus a hook or permission deny rule for enforcement
• A comment at the top of each vendored file saying the file is not to be edited
• A dedicated subagent that owns vendor/ and rejects edit requests from the main session

How do subagents help with a large migration in Claude Code?

• They share the main session's context, so every slice sees the same file history and the same earlier decisions
• They run without tools, so they can plan slices while the main session performs the edits
• They bypass the test suite for each slice so the migration completes faster
• Each handles a bounded slice in its own context and returns a summary, keeping the main session coherent

A team wants Claude Code to follow its commit message convention every time. Which approach is reliable?

• State the convention in CLAUDE.md with an example, and validate with a hook on commit
• Delegate all commits to a subagent whose prompt contains the convention
• Tell Claude Code once at the start of the session and rely on it for the rest of the work
• Let Claude Code infer the convention from the existing git log before it commits

Which is a good reason to use headless Claude Code inside a GitHub Action?

• Exploring an unfamiliar codebase, since the runner has a clean checkout to learn from
• Pair programming on a feature branch, with the Action re-running after every push
• Repeatable, reviewable automation such as summarizing a PR, with a fixed tool allow list
• Interactive debugging of a failing build, where the developer talks to Claude in the CI logs

A hook blocks a command but Claude Code keeps retrying variations. What is missing?

• A stricter permission rule that denies the Bash tool entirely for the session
• A longer CLAUDE.md section repeating the rule the hook is enforcing
• A clear block message that says what is disallowed and what to do instead
• A second hook on the Stop event that ends the turn after the first block

What is the difference between a slash command and a skill in practice?

• Slash commands need an MCP server behind them; skills run entirely from Markdown
• Skills run in a separate subagent context by default; slash commands run inside the main session with its full history
• Slash commands are built in; skills are only available through installed plugins
• A slash command is a reusable prompt you invoke; a skill packages a procedure with instructions and supporting files

Which permission stance fits a developer's laptop versus a shared CI runner?

• Allow everything in CI since nobody is there to answer prompts, and deny most on the laptop
• The same rules in both, so behavior is predictable regardless of where it runs
• Deny all writes in both and let a human apply the changes Claude proposes
• Interactive approvals on the laptop; a narrow pre-approved allow list with no prompts in CI

Claude Code keeps reading the same large log file into context on every task. Fix?

• A CLAUDE.md note to grep the log for specific patterns rather than reading it whole, or a tool that returns matches
• Increase the session's context budget so the full log fits without truncation each time
• Compact the session after each read so the earlier copies of the log leave the context before the next task starts
• Move the log's contents into the project CLAUDE.md so it is loaded once at startup and cached

Which statement about CLAUDE.md scope is correct?

• CLAUDE.md is read only from the home directory, so project rules go in settings.json
• Files can live at the project root and in subdirectories, applying to work in those areas
• One CLAUDE.md file per repository is allowed, and it must sit at the repository root
• Subdirectory CLAUDE.md files replace the root file entirely when Claude works in that area

What should a team do before letting Claude Code run database migrations in a shared environment?

• Ask Claude Code to review the migration SQL itself for mistakes before running it against the database
• Disable hooks for the migration step so nothing interrupts a long-running command
• Grant the Claude Code process admin rights so the migration cannot fail on permissions
• Gate the migration command behind approval, run it against a staging copy first, and log the run

A developer asks Claude Code to 'make the tests pass' and it edits the tests to always pass. What prevents this?

• Removing the test files from the working tree during the task so only the source files are editable by the model
• Explicit instructions that tests define behavior and must not be weakened, plus review of test diffs
• A longer timeout, so the model has time to fix the code rather than the tests
• Running in plan mode so the model proposes edits but never applies them

When is a subagent overkill?

• For parallel research across several independent parts of the codebase
• For a one-line lookup the main session can answer directly
• For a large investigation that would fill the main session with file contents
• For isolating a noisy tool's output away from the main conversation