Claude Code Configuration & Workflows

CLAUDE.md is a markdown file at a project's root that Claude Code reads automatically at the start of every session in that repository — no one has to paste it in, link it, or remind Claude it exists. That's exactly why what goes in it matters: content here loads into every session's context whether or not that particular session needs it, so it should be durable and broadly relevant — conventions, house rules, architectural decisions, the things a new contributor (human or Claude) genuinely needs to know before touching the codebase.

A one-off instruction — "refactor this one function," "check whether this PR fixes issue #42" — doesn't belong in CLAUDE.md. It belongs in the prompt for that specific task. Putting task-specific instructions in CLAUDE.md means every future session pays the context cost of loading them, and worse, they'll eventually go stale and contradict the actual current state of the work.

CLAUDE.md is scoped to the project. Claude Code also reads personal/global configuration that lives outside any repository — settings and instructions that apply across all of a user's projects, not just this one. A project's CLAUDE.md and a user's global config both load, but they answer different questions: "what does this project need every session to know" versus "what do I, this user, always want, regardless of which project I'm in."

Every tool call Claude Code wants to make — reading a file, editing one, running a shell command, calling an MCP tool — passes through a permission check before it executes. A permission rule can allow a specific tool (or a specific pattern, like a particular Bash command prefix) to run without asking, deny it outright, or fall through to asking the user for a decision.

Layered on top of individual rules is the session's permission mode — the default posture when no specific rule matches. A cautious mode asks before anything that isn't explicitly pre-approved; a more permissive mode (useful for a tight edit-test loop you're actively watching) auto-accepts file edits while still asking before shell commands; a read-only planning mode blocks any mutating action entirely so Claude can only investigate and propose. None of these modes override an explicit deny rule or a blocking hook — those still win regardless of mode.

Scoping matters most for exactly the two tool categories that can do real damage unattended: shell commands (arbitrary code execution — could delete a branch, hit a production API, exfiltrate data) and file edits (could silently rewrite something outside the intended scope). A permission setup that's broad "for convenience" is broad for whatever goes wrong, too — the point of allow/ask/deny rules is to make the blast radius of an unattended mistake match what was actually intended to be authorized.

The exam won't ask you to recite what CLAUDE.md is. It gives you a team's requirements and several plausible configuration choices, and tests whether you can:

• Tell apart something loaded once and read passively (CLAUDE.md), something invoked on demand by name (a slash command), something the model discovers and decides to use (a skill), and something that runs regardless of what the model decided (a hook).
• Recognize when a requirement needs deterministic enforcement — and reach for a hook or a permission deny rule, not a politely-worded instruction.
• Notice when a permission setup is scoped more broadly than the task actually needs.
• Treat MCP servers as just another source of tools subject to the same permission model, not a separate trust boundary.

The scenario below is built in exactly that shape — work through it before checking the answer.

Three of this domain's pieces solve the same underlying problem — giving Claude an instruction or workflow it wouldn't otherwise have — through three different loading strategies, and mixing them up is the easiest way to misconfigure a repo.

CLAUDE.md is always-loaded: every session in the project reads it, whether or not this particular task touches what it describes. That's appropriate for things every session needs, and wasteful (and eventually noisy) for something only one workflow ever uses.

A slash command is explicitly invoked: a prompt or short workflow saved as a file and triggered by typing its name, like a team's own release-checklist command. Nothing about it loads automatically — if nobody types it, it costs nothing and does nothing. That fits a workflow a person consciously decides to kick off.

A skill is discovered when relevant: a packaged set of instructions with a description Claude reads and matches against the current task, pulling in the fuller instructions only when they're likely to apply — a skill for reviewing database migrations only engages on a session that's actually touching one. That's a middle ground between paying the context cost every session and only being usable if someone remembers the exact command name.

A Claude Code session's context window is finite, and a long session — many tool calls, large file reads, extended back-and-forth — eventually approaches that limit. When it does, the harness automatically compacts the conversation: summarizing or trimming earlier turns so the session can keep going without silently losing track of what happened.

This is largely automatic, but a few things sit within a user's or project's control. A user can trigger compaction proactively rather than waiting for it, or start a fresh session once a task is genuinely done rather than letting one conversation grow indefinitely. A project can influence how much of the compaction "budget" its own configuration consumes — an unnecessarily long CLAUDE.md, or a habit of dumping huge raw tool outputs into the conversation instead of summarizing them, means compaction has to happen sooner and discards more of the actual task history to make room.

The practical implication: context management isn't purely something to clean up after the fact. Keeping CLAUDE.md focused, having tools return distilled results instead of raw dumps, and using subagents to keep a large sub-investigation's exploration out of the main session's context (Domain 1's delegation boundary, reused here) all reduce how often, and how aggressively, compaction has to run.