Domain 3 · 20% of exam

Claude Code Configuration & Workflows glossary

49 terms drawn from this domain’s 6 lessons and the sources they cite. A term that matters in more than one domain appears on each of their pages.

The full glossary is searchable across all five domains, and the domain curriculum explains where each term is used.

--allowedTools: The CLI flag listing tools, in permission-rule syntax, that run without a permission prompt. It pre-approves rather than restricts — to restrict which tools exist at all, use `--tools`. code.claude.com › cli-reference
--bare: Minimal mode: it skips auto-discovery of hooks, skills, plugins, MCP servers, auto memory, and CLAUDE.md so scripted runs start fast and reproduce across machines. It is the recommended mode for scripted and SDK calls and is slated to become the `-p` default — at the cost of the CLAUDE.md context CI reviews otherwise rely on. code.claude.com › headless
--continue: The flag (`-c`) that resumes the most recent session in the current directory without any ID tracking. Use `--resume` instead when a script juggles multiple conversations and must target a specific one. code.claude.com › headless
--disallowedTools: The CLI flag with two behaviours: a bare tool name such as `"Edit"` (or `"*"`) removes the tool from Claude's context entirely, while a scoped rule such as `Bash(rm *)` leaves the tool available and denies only matching calls. code.claude.com › permissions
--fork-session: The CLI flag combined with `--continue` or `--resume` to create a new session ID instead of reusing the original, so two divergent fixes can be compared without losing the baseline conversation. `/branch` does the same in-session. code.claude.com › sessions
--json-schema: The print-mode-only flag that validates the agent's final output against a JSON Schema. With `--output-format json` the conforming data lands in the envelope's `structured_output` field — extract it with `jq -r '.structured_output'`, not from the top level. An invalid schema now exits with an explicit error rather than silently falling back to text. code.claude.com › headless
--output-format: The flag choosing the shape of a print-mode run's output: `text` (default), `json` (a machine-parseable envelope with result text, session ID, usage, `total_cost_usd` and a per-model cost breakdown), or `stream-json` (NDJSON in real time, whose last line is always a `result` message). code.claude.com › headless
--resume: The flag that continues a specific existing session by ID or name, restoring the full conversation history, model, agent, permission mode, goals, and unexpired scheduled tasks — except `plan` and `bypassPermissions`, which are never restored. It never creates a session, and lookup is scoped to the current project directory and its git worktrees. Running it from a different directory than the session was created in is the most common cause of getting a fresh session instead. code.claude.com › sessions
-p (--print): The flag that switches Claude Code to non-interactive print mode: it processes the prompt, writes the result to stdout, and exits. Without it a CI job hangs forever waiting for keyboard input. It is the single most directly tested fact in Domain 3. code.claude.com › headless
.claude/rules/: The directory of topic-specific rule files, discovered recursively so subdirectories are included. A rule file with no `paths` frontmatter loads at launch with the same priority as `.claude/CLAUDE.md`; personal rules in `~/.claude/rules/` apply to every project and load before project rules, giving project rules higher priority on conflict. code.claude.com › memory
@ path import: The directive that inlines another file into a CLAUDE.md — a bare `@` immediately before a path on its own line, such as `@./standards/naming.md`. There is no `@import` keyword in current docs. Imports recurse to a maximum depth of four hops, and paths inside code spans or fenced code blocks are never parsed as imports. code.claude.com › memory
/compact: The command that replaces conversation history with a summary. `/compact <instructions>` focuses that summary — for example `/compact Focus on the API changes` — so what survives is the part still relevant to the current iteration rather than a generic recap. code.claude.com › best-practices
/init: The command that generates a starting CLAUDE.md by analysing the codebase, capturing build commands, test instructions, and discovered conventions. If a CLAUDE.md already exists it suggests improvements rather than overwriting. code.claude.com › memory
/memory: The diagnostic command that shows which memory files are loaded in the current session. It reveals loading, it never triggers it — use it to work out why behaviour differs between sessions or teammates.
/rewind: The command (also Esc-Esc on an empty prompt) that opens the rewind menu, offering to restore code, conversation, or both from the automatic per-prompt checkpoints. It is local undo that complements rather than replaces git, and it cannot revert changes made by Bash commands. code.claude.com › checkpointing
$ARGUMENTS: The placeholder expanding to all arguments passed when a skill or command is invoked. If it appears nowhere in the body, Claude Code appends the arguments automatically as `ARGUMENTS: <value>` so they are never silently dropped. Positional access uses `$N` (shorthand for `$ARGUMENTS[N]`) with 0-based indexing, so `$0` is the first argument. code.claude.com › skills
allowed-tools: The skill frontmatter field the exam guide describes as restricting tool access during skill execution. Current docs define it as pre-approving the listed tools for the invoking turn so they run without a permission prompt — every other tool stays available and the grant clears on your next message. code.claude.com › skills
Batch vs sequential feedback: Deliver interacting fixes in a single message so the model sees all the constraints at once; deliver independent fixes one at a time, since batching unrelated issues confuses which feedback applies where.
Batch vs synchronous: Blocking workflows — pre-merge CI checks, real-time review feedback, anything a developer waits on — stay on the synchronous API. Latency-tolerant workflows — overnight technical debt reports, weekly audits, nightly test generation — move to the Batch API for the 50% saving. Moving everything to batch for the savings is the exam's classic wrong answer.
Checkpointing: The separate mechanism that snapshots and reverts file changes, creating one checkpoint per user prompt. Its blind spot is that it tracks only edits made through Claude's own file-editing tools, not changes made via Bash commands. code.claude.com › checkpointing
CLAUDE.local.md: A personal memory file sitting next to `CLAUDE.md` at any level, loaded after it so it has the last word at that level. It is gitignored by convention and scoped to a single working-tree checkout, so sharing preferences across git worktrees means importing a file from your home directory instead. code.claude.com › memory
CLAUDE.md: The memory file Claude Code loads automatically each session, at three authored levels: user (`~/.claude/CLAUDE.md`, personal, never shared via git), project (`.claude/CLAUDE.md` or a root `CLAUDE.md`, version-controlled and shared), and directory (a subdirectory `CLAUDE.md` that loads on demand when Claude reads files there). Docs recommend keeping each file under 200 lines. code.claude.com › memory
CLAUDE.md load order: All discovered CLAUDE.md files are concatenated into context rather than overriding each other, ordered broadest scope first so instructions closest to the launch directory are read last, with `CLAUDE.local.md` appended after `CLAUDE.md` at the same level. It is not a precedence chain: if two rules contradict, Claude may pick one arbitrarily. code.claude.com › memory
context: fork: The skill frontmatter setting that runs the skill in an isolated subagent context, with the skill content becoming the subagent's prompt and no access to the parent conversation. It keeps verbose output out of the main context. The companion `agent` field picks the subagent type — `Explore`, `Plan`, `general-purpose` (the default), or a custom one from `.claude/agents/`. code.claude.com › skills
disallowed-tools: The real access boundary for a skill in current docs: a bare tool name removes the tool from Claude's context entirely, as do `deny` rules in permission settings. code.claude.com › skills
Dynamic context injection: The `` !`<command>` `` syntax in a skill or command body, which runs a shell command before the content is sent and substitutes the output for the placeholder — so Claude receives actual data such as a git diff rather than the command text. code.claude.com › skills
Explore → Plan → Implement → Commit: The recommended four-phase Claude Code workflow, and the scaffold iterative refinement hangs off: exploration and planning precede the first draft, so refinement happens during Implement against a plan that already accounted for constraints. Skip the planning phase when you could describe the diff in one sentence. code.claude.com › best-practices
Explore subagent: A built-in, fast, read-only agent optimised for searching and analysing codebases, with Write and Edit explicitly denied. It is invoked with a thoroughness level — quick, medium, or very thorough — and, uniquely alongside the Plan subagent, skips CLAUDE.md files and the parent session's git status; every other subagent loads both. code.claude.com › sub-agents
fork_session: The boolean option (`forkSession` in TypeScript, default false) used with `resume` to fork to a new session ID instead of continuing the original. The fork starts from a copy of the history up to that point; the original's ID and history are unchanged, leaving two independently resumable sessions. code.claude.com › sessions
GitHub Actions integration: Claude Code in CI triggered by an `@claude` mention in a PR or issue (the default `trigger_phrase`), built on the Claude Agent SDK. The GitHub App needs read and write on Contents, Issues, and Pull requests, and `--max-turns` defaults to 10 inside `claude_args`. code.claude.com › github-actions
Headless operational limits: Piped stdin into `claude -p` is capped at 10MB; exceeding it errors with a non-zero exit. SIGTERM on a `-p` run aborts the in-progress turn, terminates any running Bash process tree, runs `SessionEnd` hooks, and exits with code 143. code.claude.com › headless
Incremental review context: Feeding prior review findings into an automated CI review and instructing Claude to report only new or still-unaddressed issues. Without it, every push re-derives the same comments — including ones the developer deliberately chose not to act on — and duplicate comments erode trust in the review.
Independent review instance: A separate Claude invocation with no access to the generating session's reasoning, so it judges the output on what it sees alone. A reviewer in a fresh context sees only the diff and the criteria, never the justification that produced the change — the strongest form goes further and tries to refute the result rather than re-confirm it. code.claude.com › best-practices
Managed policy CLAUDE.md: The fourth CLAUDE.md scope: an organisation-deployed file at an OS-specific system path (for example `/etc/claude-code/CLAUDE.md`). It applies to every session on the machine and cannot be excluded by any individual setting. code.claude.com › memory
MCP prompt slash command: A prompt exposed by a connected MCP server becomes a slash command in the form `/mcp__servername__promptname`, taking space-separated arguments; its result is injected directly into the conversation. code.claude.com › mcp
paths frontmatter: The YAML array of glob patterns on a rule file that makes it conditional: the rule loads only when Claude works on matching files. It accepts standard globs such as `**/*.ts` plus brace expansion such as `src/**/*.{ts,tsx}`, which is what lets one file cover a file type scattered across many directories at a fraction of root CLAUDE.md's token cost. code.claude.com › memory
Permission modes: The escalating set of modes governing what runs without asking: `default` (reads only), `acceptEdits` (reads, edits, common filesystem commands), `plan`, `auto` (everything with safety checks), `dontAsk` (only pre-approved tools — the recommendation for locked-down CI), and `bypassPermissions` (everything, no prompts). code.claude.com › permission-modes
Plan mode: The mode in which Claude researches and proposes changes without making them — reads and read-only exploration only, with edits blocked until the plan is approved. Enter it with Shift+Tab, a `/plan` prefix, or `claude --permission-mode plan`; `permissions.defaultMode: "plan"` in `.claude/settings.json` makes it the project default. Shift+Tab again leaves without approving, and Ctrl+G opens the plan in your editor. code.claude.com › permission-modes
plugin_errors / mcp_server_errors: Fields on the `stream-json` format's `system/init` event whose keys are omitted entirely when there are no errors, so a CI gate can simply fail the job when either is non-empty. code.claude.com › headless
Refinement technique hierarchy: The order to reach for when steering Claude Code: concrete input/output examples (2-3 pairs) when prose is interpreted differently each run; test-driven iteration, sharing test failures, for complex transformations with many edge cases; and the interview pattern — asking Claude to question you first — for unfamiliar domains where you might miss considerations.
Session: The conversation history the SDK accumulates while an agent works — the prompt, every tool call, every tool result, and every response — written to disk as JSONL under `~/.claude/projects/<encoded-cwd>/*.jsonl`, where the encoded directory is the working directory with every non-alphanumeric character replaced by `-`. Sessions persist the conversation, not the filesystem. code.claude.com › sessions
session_id: The identifier a headless run reports in its JSON result, captured in scripts with `claude -p "..." --output-format json | jq -r '.session_id'` so a later step can pass it to `--resume`. code.claude.com › headless
settings.json: The configuration file the client enforces regardless of what Claude decides, unlike CLAUDE.md. It resolves through a strict precedence chain — managed (enterprise, always wins) > CLI arguments > local > project > user — with locations at `~/.claude/settings.json`, `.claude/settings.json` (shared), `.claude/settings.local.json` (personal), and an OS-specific enterprise `managed-settings.json` path. code.claude.com › settings
Skill invocation control: Two frontmatter switches: `disable-model-invocation: true` makes a skill user-only and keeps its description out of context, while `user-invocable: false` makes it Claude-only and hides it from the `/` menu. code.claude.com › skills
SKILL.md frontmatter: The optional YAML block at the top of a skill. All fields are optional but `description` is recommended, since it drives model-invoked triggering. Fields include `name`, `description`, `argument-hint` (autocomplete hint for expected arguments), `allowed-tools`, `model`, `context`, and `agent`. code.claude.com › skills
Skills system: The unified system behind custom `/commands`. A skill is a directory containing `SKILL.md` (`.claude/skills/<name>/SKILL.md`, the canonical location); a command is a flat Markdown file (`.claude/commands/<name>.md`, kept for backward compatibility). Both produce the same command, a skill wins over a same-named command, and locations resolve enterprise > personal (`~/.claude/skills/`) > project > bundled, with nested clashes qualified as `apps/web:deploy`. code.claude.com › skills
Skills vs CLAUDE.md: Skills are on-demand, task-specific workflows whose bodies load only on invocation; CLAUDE.md is always-loaded universal standards applied to every session with no invocation step. Do not put task-specific procedures in CLAUDE.md, or always-on reference material in skills.
System prompt flags: Four flags with an append-versus-replace distinction: `--system-prompt` and `--system-prompt-file` replace the entire default prompt, while `--append-system-prompt` and `--append-system-prompt-file` add to it. Append to keep the default tool guidance and safety instructions; replace only when the agent's identity differs from Claude Code's.
Writer/Reviewer pattern: Session A implements, a second independent session reviews, and Session A then addresses the feedback. The same split works for tests, with one Claude writing tests and another writing code to pass them. Its documented basis: a fresh context improves code review since Claude will not be biased toward code it just wrote. code.claude.com › best-practices