Practice — Claude Code Configuration & Workflows
20 questions — none attempted yet.
A developer working in a repo with an existing CLAUDE.md wants Claude to rename one specific variable across three files for this afternoon's PR.
Where should that instruction go?
A new engineer joins a project that has a CLAUDE.md file at the repository root describing testing conventions and architectural decisions.
What has to happen for that file's content to reach a new Claude Code session working in this repo?
An engineer has personal preferences — such as always explaining reasoning before making an edit — that they want applied across every project they work on, not just one repo.
Where do those preferences belong?
A team's CLAUDE.md says "never commit files containing API keys or credentials." Despite this, a credential was committed last month when a session under time pressure skipped the check.
What's the most effective fix?
A team debates what makes something a "hook" in Claude Code, as opposed to a tool the model calls.
Which statement accurately describes a hook?
A team wants every file edit Claude Code makes to be automatically run through their formatter immediately afterward, without relying on Claude remembering to run it.
Which hook configuration fits?
A team configures a PreToolUse hook meant to block any Bash command containing "rm -rf". The hook script runs but always exits 0, and the dangerous command still executes.
What's most likely wrong?
A team is comparing Claude Code's permission modes.
What does a permission mode primarily control?
A team gives Claude Code blanket approval to run any Bash command without asking, "to save time," in a repo that also holds production deployment scripts.
What's the main risk, and the better approach?
A team wants Claude Code to be able to create and update tickets in their issue tracker, which exposes an MCP server with tools for exactly that.
What is Claude Code's role once that MCP server is configured?
A team connects a new MCP server that exposes a "delete-all-records" tool.
How does that tool interact with Claude Code's permission model?
A team has two recurring needs: (1) a specific PR-template workflow someone runs by name whenever they open a PR, and (2) noticing and applying their internal API versioning convention whenever a session happens to touch a public API file, without anyone needing to remember to ask for it.
How should these be split?
A team is unsure how Claude decides to use a particular skill they've written.
How does a skill actually get invoked?
A very long Claude Code session — many large file reads, long tool outputs — starts approaching its context window limit.
What happens by default, and what's actually correct?
A project's CLAUDE.md has grown to several thousand words, including detailed one-off notes from long-finished tasks, and sessions in that repo seem to compact unusually early.
What's the most direct fix?
A team sets up Claude Code for a shared repo: CLAUDE.md documents their conventions, a hook blocks commits when tests haven't passed, and a slash command runs their release checklist.
What best describes why this combination works well together?
A contractor is given access to Claude Code on a client's repo for a two-week, narrowly-scoped bug fix engagement.
Which permission setup best fits this engagement?
A team wants Claude Code to automatically pull the latest branch state at the very start of every session in a repo, and wants to make sure any temp files a session creates get cleaned up when the session ends.
Which hook lifecycle points fit these two needs?
A postmortem says: "Claude decided to run our lint-check hook before the edit, which is why the bad formatting was caught."
What's inaccurate about that description?
A five-engineer team is standardizing Claude Code use on their shared repo. They want: (1) every session to know their branch-naming and commit-message conventions, (2) no PR ever merged without CI passing, (3) engineers to be able to kick off a standard "prepare release notes" workflow by name, and (4) Claude to recognize and follow their internal accessibility-review checklist automatically whenever a session touches UI component code, without anyone having to ask for it.
Which configuration correctly maps each need to a mechanism?