# Lesson Quiz — Question Bank

10 questions per lesson. Each question has: category, question text, options (3-4), correct answer, explanation, and review section.

---

## Lesson 01: Slash Commands

### Q1
- **Category**: conceptual
- **Question**: What are the four types of slash commands in Claude Code?
- **Options**: A) Built-in, skills, plugin commands, MCP prompts | B) Built-in, custom, hook commands, API prompts | C) System, user, plugin, terminal commands | D) Core, extension, macro, script commands
- **Correct**: A
- **Explanation**: Claude Code has built-in commands (like /help, /compact), skills (SKILL.md files), plugin commands (namespaced plugin-name:command), and MCP prompts (/mcp__server__prompt).
- **Review**: Overview section

### Q2
- **Category**: practical
- **Question**: How do you pass all user-provided arguments to a skill?
- **Options**: A) Use `${args}` | B) Use `$ARGUMENTS` | C) Use `$@` | D) Use `$INPUT`
- **Correct**: B
- **Explanation**: `$ARGUMENTS` captures all text after the command name. For positional args, use `$0`, `$1`, etc.
- **Review**: Arguments

### Q3
- **Category**: conceptual
- **Question**: When both a skill (.claude/skills/name/SKILL.md) and a legacy command (.claude/commands/name.md) exist with the same name, which takes priority?
- **Options**: A) The legacy command | B) The skill | C) Whichever was created first | D) Claude asks the user to choose
- **Correct**: B
- **Explanation**: Skills take precedence over legacy commands with the same name. The skill system supersedes the older command system.
- **Review**: Skill vs Command Conflict section

### Q4
- **Category**: practical
- **Question**: How do you inject live shell output into a skill's prompt?
- **Options**: A) Use `$(command)` syntax | B) Use `!`command`` (backtick with !) syntax | C) Use `@shell:command` syntax | D) Use `{command}` syntax
- **Correct**: B
- **Explanation**: The `!`command`` syntax runs a shell command and injects its output into the skill prompt before Claude sees it.
- **Review**: Dynamic Context with Shell Commands

### Q5
- **Category**: conceptual
- **Question**: What does `disable-model-invocation: true` do in a skill's frontmatter?
- **Options**: A) Prevents the skill from running entirely | B) Allows only the user to invoke it (Claude cannot auto-invoke) | C) Hides it from the /help menu | D) Disables the skill's AI processing
- **Correct**: B
- **Explanation**: `disable-model-invocation: true` means only the user can trigger the command via `/command-name`. Claude will never auto-invoke it, useful for skills with side effects like deployments.
- **Review**: Frontmatter Reference section

### Q6
- **Category**: practical
- **Question**: You want to create a skill that only Claude can invoke automatically (hidden from the user's / menu). Which frontmatter field do you set?
- **Options**: A) `disable-model-invocation: true` | B) `user-invocable: false` | C) `hidden: true` | D) `auto-only: true`
- **Correct**: B
- **Explanation**: `user-invocable: false` hides the skill from the user's slash menu but allows Claude to invoke it automatically based on context.
- **Review**: Frontmatter Reference section

### Q7
- **Category**: practical
- **Question**: What is the correct directory structure for a new custom skill called "deploy"?
- **Options**: A) `.claude/commands/deploy.md` | B) `.claude/skills/deploy/SKILL.md` | C) `.claude/skills/deploy.md` | D) `.claude/deploy/SKILL.md`
- **Correct**: B
- **Explanation**: Skills live in a directory under `.claude/skills/` with a `SKILL.md` file inside. The directory name matches the command name.
- **Review**: Creating a Custom Command as a Skill section

### Q8
- **Category**: conceptual
- **Question**: How do plugin commands avoid name conflicts with user commands?
- **Options**: A) They use a `plugin-name:command-name` namespace | B) They have a special .plugin extension | C) They are prefixed with `p/` | D) They override user commands automatically
- **Correct**: A
- **Explanation**: Plugin commands use a namespace like `pr-review:check-security` to avoid conflicts with standalone user commands.
- **Review**: Plugin commands section

### Q9
- **Category**: practical
- **Question**: You want a skill to use certain tools without asking for permission each time. Which frontmatter field do you add?
- **Options**: A) `tools: [Read, Grep]` | B) `allowed-tools: [Read, Grep]` | C) `permissions: [Read, Grep]` | D) `restrict-tools: [Read, Grep]`
- **Correct**: B
- **Explanation**: `allowed-tools` pre-approves the listed tools during the turn that invokes the skill, so Claude can use them without a permission prompt; the grant clears when you send your next message. It does not restrict which tools are available — to remove tools while a skill is active, use `disallowed-tools`.
- **Review**: Frontmatter Reference

### Q10
- **Category**: conceptual
- **Question**: What is the `@file` syntax used for in a skill?
- **Options**: A) Importing another skill | B) Referencing a file to include its content in the prompt | C) Creating a symlink | D) Setting file permissions
- **Correct**: B
- **Explanation**: The `@path/to/file` syntax in a skill includes the referenced file's content into the prompt, allowing skills to pull in templates or context files.
- **Review**: File references section

---

## Lesson 02: Memory

### Q1
- **Category**: conceptual
- **Question**: How do CLAUDE.md memory files relate to each other, and what has the highest authority?
- **Options**: A) Higher tiers override lower tiers entirely | B) They are concatenated into context; Managed Policy loads first and cannot be excluded | C) The most recently modified file wins | D) Project Memory has the highest priority
- **Correct**: B
- **Explanation**: CLAUDE.md files are concatenated into context rather than overriding each other — load order sets position in context, not precedence. Managed Policy (admin-managed) loads first and cannot be excluded by individual settings. Auto memory is a separate mechanism.
- **Review**: Memory hierarchy section

### Q2
- **Category**: practical
- **Question**: How do you quickly add a new rule to memory during a conversation?
- **Options**: A) Use the `/memory` slash command or ask conversationally | B) Prefix your message with `#` (e.g., `# always use TypeScript`) | C) Type `/rule "rule text"` | D) Use `@add-memory "rule text"`
- **Correct**: A
- **Explanation**: Use `/memory` to open your CLAUDE.md and auto memory files in your editor, or ask Claude conversationally. Asking Claude to "remember" something (e.g., "remember that we always use TypeScript strict mode") saves it to auto memory; to put it in CLAUDE.md instead, say "add this to CLAUDE.md". The `#` prefix was discontinued and no longer works.
- **Review**: Quick memory updates section in README

### Q3
- **Category**: conceptual
- **Question**: What is the maximum depth for `@path/to/file` imports in CLAUDE.md?
- **Options**: A) 3 levels deep | B) 4 levels deep | C) 10 levels deep | D) Unlimited
- **Correct**: B
- **Explanation**: The `@path` import syntax supports recursive imports up to a maximum depth of 4 hops to prevent infinite loops.
- **Review**: The /memory Command section (Import features)

### Q4
- **Category**: practical
- **Question**: How do you scope a rule file to only apply to files in `src/api/`?
- **Options**: A) Put the rule in `src/api/CLAUDE.md` | B) Add `paths: src/api/**` YAML frontmatter to a `.claude/rules/*.md` file | C) Name the file `.claude/rules/api.md` | D) Use `@scope: src/api` in the rule file
- **Correct**: B
- **Explanation**: Files in `.claude/rules/` support a `paths:` frontmatter field with glob patterns to scope rules to specific directories.
- **Review**: Path-specific rules section

### Q5
- **Category**: conceptual
- **Question**: How many lines of Auto Memory's MEMORY.md are loaded at session start?
- **Options**: A) All lines | B) First 100 lines | C) First 200 lines | D) First 500 lines
- **Correct**: C
- **Explanation**: The first 200 lines of MEMORY.md — or the first 25 KB, whichever comes first — are auto-loaded into context at session start. Topic files referenced from MEMORY.md are loaded on demand.
- **Review**: Auto Memory section

### Q6
- **Category**: practical
- **Question**: You want personal project preferences that are NOT committed to git. Which file should you use?
- **Options**: A) `~/.claude/CLAUDE.md` | B) `CLAUDE.local.md` | C) `.claude/rules/personal.md` | D) `.claude/memory/personal.md`
- **Correct**: B
- **Explanation**: `CLAUDE.local.md` in the project root is for personal project-specific preferences. It should be git-ignored.
- **Review**: Memory Locations Table

### Q7
- **Category**: conceptual
- **Question**: What does the `/init` command do?
- **Options**: A) Initializes a new Claude Code project from scratch | B) Generates a template CLAUDE.md based on your project structure | C) Resets all memory to defaults | D) Creates a new session
- **Correct**: B
- **Explanation**: `/init` analyzes your project and generates a template CLAUDE.md with suggested rules and standards. Re-running it on an existing CLAUDE.md suggests improvements.
- **Review**: /init command section

### Q8
- **Category**: practical
- **Question**: How do you disable Auto Memory completely?
- **Options**: A) Delete the ~/.claude/projects directory | B) Set `CLAUDE_CODE_DISABLE_AUTO_MEMORY=1` | C) Add `auto-memory: false` to CLAUDE.md | D) Use `/memory disable auto`
- **Correct**: B
- **Explanation**: Setting `CLAUDE_CODE_DISABLE_AUTO_MEMORY=1` disables auto memory. Value `0` forces it on. Unset = default on.
- **Review**: Turning Auto Memory On or Off

### Q9
- **Category**: conceptual
- **Question**: Can a lower-priority memory tier override rules from a higher-priority tier?
- **Options**: A) Yes, the most recent rule always wins | B) No — CLAUDE.md files are concatenated into context, not overridden; load order sets position, not precedence | C) Yes, if the lower tier uses the `!important` flag | D) It depends on the rule type
- **Correct**: B
- **Explanation**: CLAUDE.md files (user, project, local, rules) are concatenated into context rather than overriding each other — later files appear later in context, not "instead of" earlier ones. Only Managed Policy is special: it loads first and cannot be excluded by individual settings. Auto memory is a separate mechanism, not part of the concatenation order.
- **Review**: Memory hierarchy section

### Q10
- **Category**: practical
- **Question**: You work across two repositories and want Claude to load CLAUDE.md from both. What flag do you use?
- **Options**: A) `claude --multi-repo /path/to/other` | B) `CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 claude --add-dir /path/to/other` | C) `claude --add-dir /path/to/other` on its own | D) `claude --include /path/to/other`
- **Correct**: B
- **Explanation**: `--add-dir` on its own only grants file access to the extra directory — its CLAUDE.md is not loaded by default. Setting `CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1` makes Claude Code also load CLAUDE.md from directories added with `--add-dir`.
- **Review**: Additional directories section

---

## Lesson 03: Skills

### Q1
- **Category**: conceptual
- **Question**: What are the 3 levels of progressive disclosure in the skill system?
- **Options**: A) Metadata, instructions, resources | B) Name, body, attachments | C) Header, content, scripts | D) Summary, details, data
- **Correct**: A
- **Explanation**: Level 1: Metadata (~100 tokens, always loaded), Level 2: SKILL.md body (<5k tokens, loaded on trigger), Level 3: Bundled resources (scripts/references/assets, loaded on demand).
- **Review**: How Skills Work: Progressive Disclosure

### Q2
- **Category**: practical
- **Question**: What is the most important factor for a skill to be auto-invoked by Claude?
- **Options**: A) The skill's file name | B) The `description` field in frontmatter with when-to-use keywords | C) The skill's directory location | D) The `auto-invoke: true` frontmatter field
- **Correct**: B
- **Explanation**: Claude decides whether to auto-invoke a skill based on its `description` (plus optional `when_to_use`). It must include specific trigger phrases and scenarios.
- **Review**: Controlling Skill Invocation section

### Q3
- **Category**: conceptual
- **Question**: What is the maximum recommended length for a SKILL.md file?
- **Options**: A) 100 lines | B) 250 lines | C) 500 lines | D) 1000 lines
- **Correct**: C
- **Explanation**: SKILL.md should be kept under 500 lines. Larger reference material belongs in `references/` subdirectory files.
- **Review**: Keep SKILL.md Under 500 Lines section

### Q4
- **Category**: practical
- **Question**: How do you make a skill run in an isolated subagent with its own context?
- **Options**: A) Set `isolation: true` in frontmatter | B) Set `context: fork` with an `agent` field in frontmatter | C) Set `subagent: true` in frontmatter | D) Put the skill in `.claude/agents/`
- **Correct**: B
- **Explanation**: `context: fork` runs the skill in a separate context, and the `agent` field specifies which agent type (e.g., `Explore`, `Plan`, custom agent) to use.
- **Review**: Running skills in subagents section

### Q5
- **Category**: conceptual
- **Question**: What is the approximate context budget allocated to skill metadata (Level 1)?
- **Options**: A) 0.5% of context window | B) 1% of context window | C) 5% of context window | D) 10% of context window
- **Correct**: B
- **Explanation**: Skill metadata occupies about 1% of the context window (fallback: 8,000 characters). This is configurable with `SLASH_COMMAND_TOOL_CHAR_BUDGET` or the `skillListingBudgetFraction` setting.
- **Review**: the "Description budget" paragraph under Automatic Discovery

### Q6
- **Category**: practical
- **Question**: A skill needs to reference a large API specification. Where should you put it?
- **Options**: A) Inline in SKILL.md | B) In a `references/api-spec.md` file inside the skill directory | C) In the project's CLAUDE.md | D) In a separate `.claude/rules/` file
- **Correct**: B
- **Explanation**: Large reference material belongs in the `references/` subdirectory. Claude loads Level 3 resources on demand, keeping SKILL.md lean.
- **Review**: Supporting files structure section

### Q7
- **Category**: conceptual
- **Question**: What is the difference between Reference Content and Task Content in a skill?
- **Options**: A) Reference is read-only, Task is read-write | B) Reference adds knowledge to context, Task provides step-by-step instructions | C) Reference is for documentation, Task is for code | D) There is no difference
- **Correct**: B
- **Explanation**: Reference Content adds domain knowledge to Claude's context (e.g., brand guidelines). Task Content provides actionable step-by-step instructions for a workflow.
- **Review**: Skill content types section

### Q8
- **Category**: practical
- **Question**: What characters are allowed in the `name` field of a skill's frontmatter for a skill you plan to share via claude.ai or the Skills API (Agent Skills spec)?
- **Options**: A) Any characters | B) Lowercase letters, numbers, and hyphens only (max 64 chars) | C) Letters and underscores | D) Alphanumeric only
- **Correct**: B
- **Explanation**: The name must be kebab-case (lowercase, hyphens), max 64 characters. `name` is itself optional — if omitted it defaults to the skill's directory name — but when supplied it must follow these rules. In Claude Code, the `anthropic-skills` name and namespace are reserved for skills synced from claude.ai, so a skill with that name doesn't load; the broader ban on "anthropic" or "claude" applies to claude.ai skill uploads and the Skills API. Claude Code itself (v2.1.299) refuses only names that contain hidden, direction-changing or blank-like characters, `<` or `>`, or that are over 256 characters.
- **Review**: SKILL.md format section

### Q9
- **Category**: conceptual
- **Question**: In what order does Claude search for skills?
- **Options**: A) User > Project > Enterprise | B) Enterprise > Personal > Project (plugin uses namespace) | C) Project > User > Enterprise | D) Alphabetical order
- **Correct**: B
- **Explanation**: Priority order is: Enterprise > Personal > Project. Plugin skills use a namespace (plugin-name:skill) so they don't conflict.
- **Review**: Skill Types & Locations

### Q10
- **Category**: practical
- **Question**: How do you prevent Claude from automatically invoking a skill while still allowing users to use it manually?
- **Options**: A) Set `user-invocable: false` | B) Set `disable-model-invocation: true` | C) Remove the description field | D) Set `auto-invoke: false`
- **Correct**: B
- **Explanation**: `disable-model-invocation: true` prevents Claude from auto-invoking but keeps the skill available in the user's `/` menu for manual use.
- **Review**: Controlling Skill Invocation

---

## Lesson 04: Subagents

### Q1
- **Category**: conceptual
- **Question**: What is the main advantage of subagents over inline conversation?
- **Options**: A) They are faster | B) They operate in a separate, clean context window preventing context pollution | C) They can use more tools | D) They have better error handling
- **Correct**: B
- **Explanation**: Subagents get a fresh context window, receiving only what the main agent passes. This prevents the main conversation from being polluted with task-specific details.
- **Review**: Overview section

### Q2
- **Category**: practical
- **Question**: What is the priority order for agent definitions?
- **Options**: A) Project > User > CLI | B) CLI > Project > User | C) User > Project > CLI | D) They all have equal priority
- **Correct**: B
- **Explanation**: Full order is managed settings > `--agents` flag > project (`.claude/agents/`) > user (`~/.claude/agents/`) > plugin. Of the options listed, CLI > Project > User is the correct relative ordering.
- **Review**: File locations section

### Q3
- **Category**: conceptual
- **Question**: Which built-in subagent is optimized for read-only codebase exploration?
- **Options**: A) general-purpose | B) Plan | C) Explore | D) Bash
- **Correct**: C
- **Explanation**: The Explore subagent is the read-only codebase search agent. Since v2.1.198 it inherits the session model, capped at Opus on the Claude API — `model: haiku` is opt-in, not the default. It supports three thoroughness levels: quick, medium, very thorough.
- **Review**: Built-in subagents section

### Q4
- **Category**: practical
- **Question**: How do you restrict which subagents a coordinator agent can spawn?
- **Options**: A) Use `allowed-agents:` field | B) Use `Agent(agent_name)` syntax in the `tools` field | C) Set `spawn-limit: 2` | D) Use `restrict-agents: [name1, name2]`
- **Correct**: B
- **Explanation**: For an agent running as the main thread with `claude --agent`, `tools: Agent(worker, researcher)` creates an allowlist — it can only spawn subagents named "worker" or "researcher". `Task(...)` still works as an alias (the Task tool was renamed Agent in v2.1.63).
- **Review**: Restrict spawnable subagents section

### Q5
- **Category**: conceptual
- **Question**: What does `isolation: worktree` do for a subagent?
- **Options**: A) Runs the agent in a Docker container | B) Gives the agent its own git worktree so changes don't affect the main tree | C) Prevents the agent from reading any files | D) Runs the agent in a sandbox
- **Correct**: B
- **Explanation**: Worktree isolation creates a separate git worktree. If the agent makes no changes, it auto-cleans up. If changes are made, the worktree path and branch are returned.
- **Review**: Worktree isolation section

### Q6
- **Category**: practical
- **Question**: How do you force a subagent to always run in the background (never inline)?
- **Options**: A) Set `background: true` in the agent config | B) Use `async: true` in the agent config | C) Press Ctrl+D after starting it | D) Use `--background` CLI flag
- **Correct**: A
- **Explanation**: `background: true` in the agent configuration makes the subagent always run as a background task and prevents it from running inline. Subagents Claude spawns from the main conversation already run in the background by default (v2.1.198; always, in the desktop app and VS Code, since v2.1.302), but a subagent's own nested Agent calls run in the foreground by default in `claude -p`, the Agent SDK, the desktop app and VS Code. Users can also press Ctrl+B to send a running foreground task to the background.
- **Review**: Background subagents section

### Q7
- **Category**: conceptual
- **Question**: What does the `memory` field with scope `project` do for a subagent?
- **Options**: A) Gives read access to the project CLAUDE.md | B) Creates a persistent memory directory scoped to the current project | C) Shares the main agent's conversation history | D) Loads the project's git history
- **Correct**: B
- **Explanation**: The `memory` field creates a persistent directory for the subagent. Scope `project` means the memory is tied to the current project. The first 200 lines or 25KB of the agent's MEMORY.md, whichever comes first, auto-load.
- **Review**: Persistent memory section

### Q8
- **Category**: practical
- **Question**: How do you include a phrase in a subagent's description to encourage Claude to automatically delegate tasks to it?
- **Options**: A) Add "priority: high" | B) Include "use PROACTIVELY" or "MUST BE USED" in the description | C) Set `auto-delegate: true` | D) Add "trigger: always"
- **Correct**: B
- **Explanation**: Including phrases like "use PROACTIVELY" or "MUST BE USED" in the description strongly encourages Claude to automatically delegate matching tasks.
- **Review**: Automatic delegation section

### Q9
- **Category**: conceptual
- **Question**: What are the valid `permissionMode` values for a subagent?
- **Options**: A) read, write, admin | B) manual, acceptEdits, bypassPermissions, plan, dontAsk, auto | C) safe, normal, dangerous | D) restricted, standard, elevated
- **Correct**: B
- **Explanation**: Subagents support six permission modes: manual (runs reads without asking and prompts for everything else — shown as Manual; its config value is `default`, and manual is accepted as an alias since v2.1.200), acceptEdits (auto-accepts file edits), bypassPermissions (skips all), plan (read-only), dontAsk (auto-denies unless pre-approved), auto (background classifier decides).
- **Review**: Configuration fields section

### Q10
- **Category**: practical
- **Question**: How do you resume a subagent that returned an agentId from a previous run?
- **Options**: A) Use `/resume agent-id` | B) Ask Claude to resume it — Claude messages the subagent with the SendMessage tool, using its agent ID or name | C) Use `claude -r agent-id` | D) Subagents cannot be resumed
- **Correct**: B
- **Explanation**: Each invocation starts a new instance. To continue earlier work, ask Claude to resume the subagent: Claude uses the SendMessage tool with the agent's ID or name, and the subagent resumes with its full conversation history. The built-in Explore and Plan agents are one-shot and can't be resumed.
- **Review**: Resumable agents section

---

## Lesson 05: MCP

### Q1
- **Category**: conceptual
- **Question**: What are the four MCP transport protocols, and which is recommended?
- **Options**: A) HTTP (recommended), Stdio, SSE (deprecated), WebSocket (`ws`) | B) REST (recommended), GraphQL, gRPC, Thrift | C) TCP, UDP, HTTP | D) Stdio (recommended), HTTP, SSE
- **Correct**: A
- **Explanation**: HTTP is recommended for remote servers. Stdio is for local processes (most common currently). SSE is deprecated but still supported. WebSocket (`type: "ws"`) holds a persistent bidirectional connection for servers that push events unprompted; it is added with `claude mcp add-json` or `.mcp.json`, not with `--transport`, and supports header-only auth.
- **Review**: MCP Installation Methods section

### Q2
- **Category**: practical
- **Question**: How do you add a GitHub MCP server via CLI?
- **Options**: A) `claude mcp install github` | B) `claude mcp add --transport http github https://api.githubcopilot.com/mcp/` | C) `claude plugin add github-mcp` | D) `claude connect github`
- **Correct**: B
- **Explanation**: Use `claude mcp add` with the `--transport` flag, a name, and the server URL. GitHub's remote server also needs an auth header: `claude mcp add --transport http github https://api.githubcopilot.com/mcp/ --header "Authorization: Bearer YOUR_GITHUB_PAT"`.
- **Review**: MCP configuration management section

### Q3
- **Category**: conceptual
- **Question**: With `ENABLE_TOOL_SEARCH=auto`, what happens when MCP tool definitions reach 10% of the context window?
- **Options**: A) They are truncated | B) Tool search kicks in: MCP tools are deferred and discovered on demand | C) Claude shows an error | D) Extra tools are disabled
- **Correct**: B
- **Explanation**: By default (`ENABLE_TOOL_SEARCH` unset) tool search is already on and all MCP tools are deferred. `auto` is threshold mode: tools load upfront until their definitions reach 10% of the context window, then all are deferred (`auto:N` sets a custom percentage). Tool search needs a model that supports `tool_reference` blocks: Opus 4, Sonnet 4, Haiku 4.5 and later.
- **Review**: MCP Tool Search section

### Q4
- **Category**: practical
- **Question**: How do you use environment variable fallbacks in MCP config?
- **Options**: A) `${VAR || "default"}` | B) `${VAR:-default}` | C) `${VAR:default}` | D) `${VAR ? "default"}`
- **Correct**: B
- **Explanation**: `${VAR:-default}` provides a fallback value if the environment variable is not set. If `VAR` is unset and has no default, the server still loads with the literal `${VAR}` text, and `claude mcp list` and `/mcp` warn about the missing variable.
- **Review**: Environment variable expansion section

### Q5
- **Category**: conceptual
- **Question**: What is the difference between MCP and Memory for data access?
- **Options**: A) MCP is faster, Memory is slower | B) MCP is for live/changing external data, Memory is for persistent/static preferences | C) MCP is for code, Memory is for text | D) They are interchangeable
- **Correct**: B
- **Explanation**: MCP connects to live, changing external data sources (APIs, databases). Memory stores persistent, static project context and preferences.
- **Review**: MCP vs Memory section

### Q6
- **Category**: practical
- **Question**: What happens when a team member first encounters a project-scoped `.mcp.json`?
- **Options**: A) It loads automatically | B) They get an approval prompt to trust the project's MCP servers | C) It's ignored unless they opt in via settings | D) Claude asks the admin to approve
- **Correct**: B
- **Explanation**: Project-scoped `.mcp.json` triggers a security approval prompt on each team member's first use. This is intentional — it prevents untrusted MCP servers.
- **Review**: MCP Scopes section

### Q7
- **Category**: conceptual
- **Question**: What does `claude mcp serve` do?
- **Options**: A) Starts an MCP server dashboard | B) Makes Claude Code itself act as an MCP server for other applications | C) Serves MCP documentation | D) Tests MCP server connections
- **Correct**: B
- **Explanation**: `claude mcp serve` turns Claude Code into an MCP server, enabling multi-agent orchestration where one Claude instance can be controlled by another.
- **Review**: Claude as MCP Server section

### Q8
- **Category**: practical
- **Question**: What is the default maximum output size for MCP tools?
- **Options**: A) 5,000 tokens | B) 10,000 tokens | C) 25,000 tokens | D) 50,000 tokens
- **Correct**: C
- **Explanation**: Default max is 25,000 tokens (`MAX_MCP_OUTPUT_TOKENS`). A warning appears at 10k tokens. Text results over 50,000 characters are saved to a file.
- **Review**: MCP Output Limits section

### Q9
- **Category**: conceptual
- **Question**: When both `allowedMcpServers` and `deniedMcpServers` match a server in managed config, which wins?
- **Options**: A) Allowed wins | B) Denied wins | C) The last one configured wins | D) Both are applied independently
- **Correct**: B
- **Explanation**: In managed MCP configuration, deny rules always take precedence over allow rules.
- **Review**: Managed MCP Configuration section

### Q10
- **Category**: practical
- **Question**: How do you reference an MCP resource in a conversation?
- **Options**: A) Use `/mcp resource-name` | B) Use `@server-name:protocol://resource/path` mention syntax | C) Use `mcp.get("resource")` | D) Resources are auto-loaded
- **Correct**: B
- **Explanation**: MCP resources are accessed via `@server-name:protocol://resource/path` mention syntax in conversation.
- **Review**: MCP Resources section

---

## Lesson 06: Hooks

### Q1
- **Category**: conceptual
- **Question**: What are the five types of hooks in Claude Code?
- **Options**: A) Pre, Post, Error, Filter, and Transform hooks | B) Command, HTTP, MCP Tool, Prompt, and Agent hooks | C) Before, After, Around, Through, and Beside hooks | D) Input, Output, Filter, Transform, and Validate hooks
- **Correct**: B
- **Explanation**: Command hooks run shell scripts, HTTP hooks call webhook endpoints, MCP Tool hooks invoke an MCP tool, Prompt hooks use single-turn LLM evaluation, and Agent hooks use subagent-based verification. Agent hooks are experimental and may change.
- **Review**: Hook types section

### Q2
- **Category**: practical
- **Question**: A hook script exits with code 2. What happens?
- **Options**: A) Non-blocking warning shown | B) Blocking error — stderr is shown as an error to Claude, tool use is prevented | C) Hook is retried | D) Session ends
- **Correct**: B
- **Explanation**: Exit code 0 = success/continue, exit code 2 = blocking error (stderr shown as error), any other non-zero = non-blocking error (a `<hook name> hook error` notice with the first line of stderr appears in the transcript, and the action goes ahead). Since v2.1.295, setting `"onFailure": "block"` on a command or HTTP hook makes such failures block like exit 2.
- **Review**: Exit codes section

### Q3
- **Category**: conceptual
- **Question**: What JSON fields does a PreToolUse hook receive on stdin?
- **Options**: A) `tool_name` and `tool_output` | B) `session_id`, `tool_name`, `tool_input`, `hook_event_name`, `cwd`, and more | C) Only `tool_name` | D) The full conversation history
- **Correct**: B
- **Explanation**: Hooks receive a JSON object on stdin with: session_id, transcript_path, hook_event_name, tool_name, tool_input, tool_use_id, cwd, and permission_mode.
- **Review**: JSON Input (via stdin)

### Q4
- **Category**: practical
- **Question**: How can a PreToolUse hook modify the tool's input parameters before execution?
- **Options**: A) Return modified JSON on stderr | B) Return JSON with `updatedInput` field on stdout (exit code 0) | C) Write to a temp file | D) Hooks cannot modify inputs
- **Correct**: B
- **Explanation**: A PreToolUse hook can output JSON with `"updatedInput": {...}` on stdout (with exit 0) to modify the tool's parameters before Claude uses them. `updatedInput` goes under `hookSpecificOutput` and replaces the whole input object; since v2.1.300 it is validated like Claude's own input, so unknown keys are dropped and input the tool rejects denies the call.
- **Review**: PreToolUse section

### Q5
- **Category**: conceptual
- **Question**: Which hook event supports `CLAUDE_ENV_FILE` for persisting environment variables into the session?
- **Options**: A) PreToolUse | B) UserPromptSubmit | C) SessionStart | D) All events
- **Correct**: C
- **Explanation**: `CLAUDE_ENV_FILE` is available to SessionStart, Setup, CwdChanged, and FileChanged hooks, which use it to persist environment variables into the session. Of the options listed, SessionStart is the one that supports it — PreToolUse and UserPromptSubmit do not, and it is not available to all events.
- **Review**: SessionStart section

### Q6
- **Category**: practical
- **Question**: You want a hook that only runs once when a skill is first loaded, not on every tool call. What field do you add?
- **Options**: A) `run-once: true` | B) `once: true` on a hook in the skill's frontmatter | C) `single: true` | D) `max-runs: 1`
- **Correct**: B
- **Explanation**: Hooks declared in a skill's frontmatter support `once: true` — Claude Code removes the hook after its first successful run (a run that fails, blocks, or times out leaves it in place). `once` is honored only in skill frontmatter.
- **Review**: Component-scoped hooks section

### Q7
- **Category**: conceptual
- **Question**: A Stop hook is defined in a subagent's frontmatter. What does it automatically convert to?
- **Options**: A) A PostToolUse hook | B) A SubagentStop hook | C) A SessionEnd hook | D) It stays as a Stop hook
- **Correct**: B
- **Explanation**: When a Stop hook is placed in a subagent's frontmatter, it auto-converts to SubagentStop so it runs when that specific subagent finishes.
- **Review**: Component-scoped hooks section

### Q8
- **Category**: practical
- **Question**: How do you match a hook to all MCP tools from a specific server?
- **Options**: A) `matcher: "mcp_github"` | B) `matcher: "mcp__github__.*"` (regex pattern) | C) `matcher: "mcp:github:*"` | D) `matcher: "github-mcp"`
- **Correct**: B
- **Explanation**: Use regex patterns for matchers. MCP tools follow the `mcp__server__tool` naming convention, so `mcp__github__.*` matches all GitHub MCP tools.
- **Review**: Matcher patterns section

### Q9
- **Category**: conceptual
- **Question**: How many hook events does Claude Code support in total?
- **Options**: A) 16 | B) 25 | C) 33 | D) 40
- **Correct**: C
- **Explanation**: Claude Code supports 33 hook events. They fall into four groups: session lifecycle (`SessionStart`, `Setup`, `SessionEnd`), prompt and message handling (`UserPromptSubmit`, `UserPromptExpansion`, `MessageDisplay`), tool use and permissions (`PreToolUse`, `PostToolUse`, `PermissionRequest`, …), and agent, task, and environment coordination (`SubagentStart`, `TaskCreated`, `CwdChanged`, `WorktreeCreate`, `PreModelSwitch`, `PostModelSwitch`, …).
- **Review**: Hook events table

### Q10
- **Category**: practical
- **Question**: You want to debug why a hook isn't firing. What's the best approach?
- **Options**: A) Add print statements to the hook script | B) Use the `--debug` flag and `Ctrl+O` to open the transcript viewer | C) Check the system log | D) Hooks don't have debugging tools
- **Correct**: B
- **Explanation**: `claude --debug` (or `--debug-file <path>`, or `/debug` mid-session) logs hook runs to the debug log, including which hooks fire, their inputs, and outputs; `Ctrl+O` opens the transcript view to see hook outcomes.
- **Review**: Debugging section

---

## Lesson 07: Plugins

### Q1
- **Category**: conceptual
- **Question**: What is the core manifest file for a plugin and where does it live?
- **Options**: A) `plugin.yaml` in the root directory | B) `.claude-plugin/plugin.json` | C) `package.json` with a "claude" key | D) `.claude/plugin.md`
- **Correct**: B
- **Explanation**: The plugin manifest lives at `.claude-plugin/plugin.json`. The manifest is optional; when present, `name` (kebab-case identifier) is its only required key; `description`, `version`, `author`, `homepage`, `repository` and `license` are optional metadata.
- **Review**: Plugin definition structure section

### Q2
- **Category**: practical
- **Question**: How do you load a plugin from a local directory so you can try it in a session before publishing?
- **Options**: A) Use `/plugin test ./my-plugin` | B) Use `claude --plugin-dir ./my-plugin` | C) Use `claude plugin validate ./my-plugin` | D) Copy it to ~/.claude/plugins/
- **Correct**: B
- **Explanation**: The `--plugin-dir` flag loads a plugin from a local directory for testing. It's repeatable for loading multiple plugins. `claude plugin validate ./my-plugin` checks the manifest and components but doesn't load the plugin into a session.
- **Review**: Testing section

### Q3
- **Category**: conceptual
- **Question**: What environment variable is available inside plugin hooks and MCP configs to reference the plugin's installation directory?
- **Options**: A) `$PLUGIN_HOME` | B) `${CLAUDE_PLUGIN_ROOT}` | C) `$PLUGIN_DIR` | D) `${CLAUDE_PLUGIN_PATH}`
- **Correct**: B
- **Explanation**: `${CLAUDE_PLUGIN_ROOT}` resolves to the plugin's installed directory, enabling portable path references in hooks and MCP configs.
- **Review**: Plugin-Provided MCP Servers section in Lesson 05 (MCP)

### Q4
- **Category**: practical
- **Question**: A plugin has a command called "check-security" in the "pr-review" plugin. How does a user invoke it?
- **Options**: A) `/check-security` | B) `/pr-review:check-security` | C) `/plugin pr-review check-security` | D) `/pr-review/check-security`
- **Correct**: B
- **Explanation**: Plugin commands use a `plugin-name:command-name` namespace to avoid conflicts with user commands and other plugins.
- **Review**: Plugin Commands section in Lesson 01 (Slash Commands)

### Q5
- **Category**: conceptual
- **Question**: Which components can a plugin bundle?
- **Options**: A) Only commands and settings | B) Skills, agents, commands, hooks, MCP servers, LSP config, settings, templates, scripts | C) Only commands, hooks, and MCP servers | D) Only skills and agents
- **Correct**: B
- **Explanation**: Plugins can bundle: skills/, agents/, commands/, hooks/hooks.json, .mcp.json, .lsp.json, settings.json, templates/, scripts/, docs/, tests/. Note that `commands/` is legacy — official guidance is to use `skills/` for new plugins, though existing `commands/` directories keep working.
- **Review**: Plugin Structure Example section

### Q6
- **Category**: practical
- **Question**: How do you install a plugin from GitHub?
- **Options**: A) `claude plugin add github:username/repo` | B) `/plugin marketplace add username/repo`, then `/plugin install plugin-name@marketplace-name` | C) `npm install @claude/username-repo` | D) `git clone` then `claude plugin register`
- **Correct**: B
- **Explanation**: Add the GitHub repo as a marketplace with `/plugin marketplace add username/repo`, then install with `/plugin install plugin-name@marketplace-name`. You can also do both in one step: `/plugin install plugin-name --marketplace username/repo` inside a session (v2.1.275+), or `claude plugin install plugin-name --marketplace username/repo` from your shell (v2.1.292+). There is no `github:` install form.
- **Review**: Installation methods section

### Q7
- **Category**: conceptual
- **Question**: What does the `settings.json` `agent` key do in a plugin?
- **Options**: A) Specifies authentication credentials | B) Sets the main thread agent for the plugin | C) Lists available subagents | D) Configures agent permissions
- **Correct**: B
- **Explanation**: The `agent` key in a plugin's settings.json specifies which agent definition to use as the main thread agent when the plugin is active.
- **Review**: Plugin Settings section

### Q8
- **Category**: practical
- **Question**: How do you manage plugin lifecycle (enable/disable/update)?
- **Options**: A) Edit a config file manually | B) Use `/plugin enable`, `/plugin disable`, `claude plugin update <name>` | C) Use `claude plugin-manager` | D) Reinstall the plugin
- **Correct**: B
- **Explanation**: `/plugin enable` and `/plugin disable` are real slash commands. For updating an installed plugin, `claude plugin update <name>` is the form documented in the plugins reference, and the one Claude Code points you to when an update is available.
- **Review**: Plugin CLI Commands section

### Q9
- **Category**: conceptual
- **Question**: What is the main advantage of a plugin over standalone skills/hooks/MCP?
- **Options**: A) Plugins are faster | B) Single-command install, versioned, marketplace distribution, bundles everything together | C) Plugins have more permissions | D) Plugins work offline
- **Correct**: B
- **Explanation**: Plugins package multiple components into one installable unit with versioning, marketplace distribution, and automatic updates — vs. manual setup of standalone components.
- **Review**: Standalone vs Plugin Approach

### Q10
- **Category**: practical
- **Question**: Where do plugin hooks configuration live within the plugin directory?
- **Options**: A) `.claude-plugin/hooks.json` | B) `hooks/hooks.json` | C) `plugin.json` hooks section | D) `.claude/settings.json`
- **Correct**: B
- **Explanation**: Plugin hooks are configured in `hooks/hooks.json` within the plugin directory structure.
- **Review**: Plugin Structure Example

---

## Lesson 08: Checkpoints

### Q1
- **Category**: conceptual
- **Question**: What four things do checkpoints capture?
- **Options**: A) Git commits, branches, tags, stashes | B) Messages, file modifications, tool usage history, session context | C) Code, tests, logs, configs | D) Inputs, outputs, errors, timing
- **Correct**: B
- **Explanation**: Checkpoints capture conversation messages, file modifications made by Claude's tools, tool usage history, and session context.
- **Review**: Overview section

### Q2
- **Category**: practical
- **Question**: How do you access the checkpoint browser?
- **Options**: A) Use `/restore` command | B) Press `Esc + Esc` (double-escape) or use `/rewind` | C) Use `/history` command | D) Press `Ctrl+Z`
- **Correct**: B
- **Explanation**: Double-escape (Esc+Esc) or the `/rewind` command opens the checkpoint browser to select a restore point.
- **Review**: Accessing checkpoints section

### Q3
- **Category**: conceptual
- **Question**: How many rewind options are available, and what are they?
- **Options**: A) 3: Undo, Redo, Reset | B) 6: Restore code+conversation, Restore conversation, Restore code, Summarize from here, Summarize up to here, Never mind | C) 2: Full restore, Partial restore | D) 4: Code, Messages, Both, Cancel
- **Correct**: B
- **Explanation**: The 6 options are: Restore code and conversation (full rollback), Restore conversation only, Restore code only, Summarize from here (compress forward), Summarize up to here (compress backward), Never mind (cancel). The two summary options give bidirectional context compaction.
- **Review**: Rewind options section

### Q4
- **Category**: practical
- **Question**: You used `rm -rf temp/` via Bash in Claude Code, then want to rewind. Will the checkpoint restore those files?
- **Options**: A) Yes, checkpoints capture everything | B) No, Bash filesystem operations (rm, mv, cp) are not tracked by checkpoints | C) Only if you used the Edit tool instead | D) Only if autoCheckpoint was enabled
- **Correct**: B
- **Explanation**: Checkpoints track file changes made by Claude's own Write/Edit tools in the main thread. Bash commands (rm, mv, cp), subagent edits (except a foreground `context: fork` skill), edits made outside Claude Code, and symlinked/hardlinked paths are all outside checkpoint tracking.
- **Review**: Limitations section

### Q5
- **Category**: conceptual
- **Question**: How long are checkpoints retained?
- **Options**: A) Until session ends | B) 7 days | C) 30 days | D) Indefinitely
- **Correct**: C
- **Explanation**: Checkpoints are saved with the session, so `/rewind` works after you resume it; snapshots are deleted about 30 days after the session last saved one (`cleanupPeriodDays`); only the 100 most recent checkpoints keep file snapshots. The window is governed by `cleanupPeriodDays`.
- **Review**: Checkpoint Retention section

### Q6
- **Category**: practical
- **Question**: What does "Summarize from here" do when rewinding?
- **Options**: A) Deletes the conversation from that point | B) Compresses the conversation into an AI-generated summary while preserving the original in the transcript | C) Creates a bullet-point list of changes | D) Exports the conversation to a file
- **Correct**: B
- **Explanation**: Summarize compresses the conversation into a shorter AI-generated summary. The original full text is preserved in the transcript file.
- **Review**: Rewind Options section

### Q7
- **Category**: conceptual
- **Question**: When are checkpoints created automatically?
- **Options**: A) Every 5 minutes | B) On every user prompt | C) Only when you manually save | D) After every tool use
- **Correct**: B
- **Explanation**: Automatic checkpoints are created with every user prompt, capturing the state before Claude processes the request.
- **Review**: Automatic checkpoints section

### Q8
- **Category**: practical
- **Question**: How do you disable automatic checkpoint creation?
- **Options**: A) Use `--no-checkpoints` flag | B) Set `fileCheckpointingEnabled: false` in settings | C) Delete the checkpoints directory | D) Checkpoints cannot be disabled
- **Correct**: B
- **Explanation**: Set `fileCheckpointingEnabled: false` in your configuration to disable automatic checkpoint creation (default is true; requires v2.1.119+). Env equivalent: `CLAUDE_CODE_DISABLE_FILE_CHECKPOINTING`.
- **Review**: Configuration section

### Q9
- **Category**: conceptual
- **Question**: Are checkpoints a replacement for git commits?
- **Options**: A) Yes, they're more powerful | B) No, they are complementary — checkpoints are session-scoped and expire, git is permanent and shareable | C) Yes, for small projects | D) Only in solo development
- **Correct**: B
- **Explanation**: Checkpoints are temporary (30-day retention), session-scoped, and cannot be shared. Git commits are permanent, auditable, and shareable. Use both together.
- **Review**: Integration with git section

### Q10
- **Category**: practical
- **Question**: You want to compare two different approaches. What's the recommended checkpoint workflow?
- **Options**: A) Create two separate sessions | B) Checkpoint before approach A, try it, rewind to checkpoint, try approach B, compare results | C) Use git branches instead | D) There's no good way to compare approaches
- **Correct**: B
- **Explanation**: The branching strategy: checkpoint at clean state, try approach A, note results, rewind to the same checkpoint, try approach B. Compare both outcomes.
- **Review**: Workflow patterns section

---

## Lesson 09: Advanced Features

### Q1
- **Category**: conceptual
- **Question**: What are the six permission modes in Claude Code?
- **Options**: A) read, write, execute, admin, root, sudo | B) manual, acceptEdits, plan, auto, dontAsk, bypassPermissions | C) safe, normal, elevated, admin, unrestricted, god | D) view, edit, run, deploy, full, bypass
- **Correct**: B
- **Explanation**: The six modes are: manual (runs reads without asking and prompts for everything else — shown as Manual; its config value is `default`, and manual is accepted as an alias since v2.1.200), acceptEdits (auto-accepts file edits), plan (read-only analysis), auto (background classifier decides), dontAsk (auto-denies unless pre-approved), bypassPermissions (skips all checks).
- **Review**: Permission Modes section

### Q2
- **Category**: practical
- **Question**: How do you activate planning mode?
- **Options**: A) Only via `/plan` command | B) Via `/plan`, `Shift+Tab`/`Alt+M`, `--permission-mode plan` flag, or default config | C) Via `--planning` flag only | D) Planning is always on
- **Correct**: B
- **Explanation**: Planning mode can be activated multiple ways: /plan command, Shift+Tab/Alt+M keyboard shortcut, --permission-mode plan CLI flag, or as a default in config.
- **Review**: Planning Mode section

### Q3
- **Category**: conceptual
- **Question**: What does the `opusplan` model alias do?
- **Options**: A) Uses only Opus for everything | B) Uses Opus for planning phase and Sonnet for implementation | C) Uses a special planning-optimized model | D) Enables plan mode automatically
- **Correct**: B
- **Explanation**: `opusplan` is a model alias that uses Opus for the planning phase (higher quality analysis) and Sonnet for the execution phase (faster implementation).
- **Review**: Planning Mode section

### Q4
- **Category**: practical
- **Question**: On a model where thinking can be turned off (for example Sonnet 5), how do you toggle extended thinking on or off during a session?
- **Options**: A) Type `/effort max` | B) Press `Option+T` (macOS) or `Alt+T` | C) Include "ultrathink" in prompt | D) It's always enabled and cannot be toggled
- **Correct**: B
- **Explanation**: Option+T (macOS) or Alt+T toggles extended thinking on/off for the session. (`Ctrl+O` toggles verbose mode to show/hide the reasoning text.) On Opus 5.5 (the default model since v2.1.280), Sonnet 5.5 (what the `sonnet` alias resolves to on the Anthropic API since v2.1.284), Haiku 5.5 (what the `haiku` alias resolves to on the Anthropic API since v2.1.293), and the Fable models, thinking can't be turned off: the toggle, `alwaysThinkingEnabled` and `MAX_THINKING_TOKENS=0` have no effect there. For one-off deep reasoning, include "ultrathink" in your prompt; for session-level control, use the `/effort` command.
- **Review**: Extended Thinking section

### Q5
- **Category**: conceptual
- **Question**: Does the "ultrathink" keyword trigger deep reasoning?
- **Options**: A) Yes, it triggers deep reasoning for one response without changing session settings | B) No, it's treated as regular prompt text | C) Yes, but only on Opus 4.6 | D) Yes, and it permanently changes the effort level
- **Correct**: A
- **Explanation**: Including "ultrathink" in your prompt adds an in-context instruction for the model to reason more on that turn. It does not change the effort level sent to the API—use `/effort max` for session-level deep reasoning.
- **Review**: Extended Thinking section

### Q6
- **Category**: practical
- **Question**: How do you run Claude in a CI/CD pipeline with structured JSON output and a turn limit?
- **Options**: A) `claude --ci --json --limit 3` | B) `claude -p --output-format json --max-turns 3 "review code"` | C) `claude --pipeline --format json` | D) `claude run --json --turns 3`
- **Correct**: B
- **Explanation**: Print mode (`-p`) with `--output-format json` and `--max-turns` is the standard CI/CD integration pattern.
- **Review**: Headless Mode

### Q7
- **Category**: conceptual
- **Question**: What does the Task List feature (Ctrl+T) provide?
- **Options**: A) A list of running background processes | B) A persistent to-do list that survives context compaction, shareable via `CLAUDE_CODE_TASK_LIST_ID` | C) A history of past sessions | D) A queue of pending tool calls
- **Correct**: B
- **Explanation**: The Task List (Ctrl+T) is persistent across context compactions and can be shared across sessions via named task directories using `CLAUDE_CODE_TASK_LIST_ID`.
- **Review**: Task List section

### Q8
- **Category**: practical
- **Question**: How do you edit a plan externally (in your preferred editor) during planning mode?
- **Options**: A) Copy-paste from the terminal | B) Press `Ctrl+G` to open the plan in an external editor | C) Use `/export-plan` command | D) Plans can't be edited externally
- **Correct**: B
- **Explanation**: Ctrl+G opens the current plan in your configured external editor for modification.
- **Review**: Planning Mode section

### Q9
- **Category**: conceptual
- **Question**: What is the difference between `dontAsk` and `bypassPermissions` modes?
- **Options**: A) They are the same | B) `dontAsk` auto-denies unless pre-approved; `bypassPermissions` skips all checks entirely | C) `dontAsk` is for files; `bypassPermissions` is for commands | D) `bypassPermissions` is safer
- **Correct**: B
- **Explanation**: dontAsk auto-denies permission requests unless they match pre-approved patterns. bypassPermissions skips all safety checks entirely — it's dangerous for routine use.
- **Review**: Permission Modes section

### Q10
- **Category**: practical
- **Question**: How do you hand off a CLI session to the desktop app?
- **Options**: A) Use `/export` command | B) Use `/desktop` command | C) Copy the session ID and paste in the app | D) Sessions can't transfer between CLI and desktop
- **Correct**: B
- **Explanation**: The `/desktop` command hands off the current CLI session to the native desktop application for visual diff review and multi-session management.
- **Review**: Desktop App section

---

## Lesson 10: CLI Reference

### Q1
- **Category**: conceptual
- **Question**: What are the two primary modes of the Claude CLI?
- **Options**: A) Online and offline mode | B) Interactive REPL (`claude`) and Print mode (`claude -p`) | C) GUI and terminal mode | D) Single and batch mode
- **Correct**: B
- **Explanation**: Interactive REPL is the default conversational mode. Print mode (-p) is non-interactive, scriptable, pipeable — it exits after one response.
- **Review**: CLI architecture section

### Q2
- **Category**: practical
- **Question**: How do you pipe a file into Claude and get JSON output?
- **Options**: A) `claude --file error.log --json` | B) `cat error.log | claude -p --output-format json "explain this"` | C) `claude < error.log --format json` | D) `claude -p --input error.log --json`
- **Correct**: B
- **Explanation**: Pipe content via stdin to print mode (-p) and use --output-format json for structured output.
- **Review**: Interactive vs Print Mode section

### Q3
- **Category**: conceptual
- **Question**: What is the difference between `-c` and `-r` flags?
- **Options**: A) Both do the same thing | B) `-c` continues the most recent session; `-r` resumes by name or ID | C) `-c` creates a new session; `-r` resumes | D) `-c` is for code; `-r` is for review
- **Correct**: B
- **Explanation**: `-c/--continue` resumes the most recent conversation. `-r/--resume "name"` resumes a specific session by name or session ID.
- **Review**: Session management section

### Q4
- **Category**: practical
- **Question**: How do you guarantee schema-valid JSON output from Claude?
- **Options**: A) Just use `--output-format json` | B) Use `--output-format json --json-schema '{"type":"object",...}'` | C) Use `--strict-json` flag | D) JSON output is always schema-valid
- **Correct**: B
- **Explanation**: `--output-format json` alone produces best-effort JSON. Adding `--json-schema` with a JSON Schema definition guarantees the output matches the schema.
- **Review**: Output & Format

### Q5
- **Category**: conceptual
- **Question**: Which flag only works in print mode (-p) and has no effect in interactive mode?
- **Options**: A) `--model` | B) `--system-prompt-file` | C) `--verbose` | D) `--max-turns`
- **Correct**: D
- **Explanation**: `--max-turns` limits the number of agentic turns and applies only in print mode (`-p`); it exits with an error when the limit is reached. `--system-prompt-file`, like the other system-prompt flags, works in both interactive and print modes.
- **Review**: Advanced Features

### Q6
- **Category**: practical
- **Question**: How do you restrict Claude to only use read-only tools for a security audit?
- **Options**: A) `claude --read-only "audit code"` | B) `claude --permission-mode plan --tools "Read,Grep,Glob" "audit code"` | C) `claude --safe-mode "audit code"` | D) `claude --no-write "audit code"`
- **Correct**: B
- **Explanation**: Combine `--permission-mode plan` (read-only analysis) with `--tools` (allowlist of specific tools) to restrict Claude to only read operations.
- **Review**: Tool & Permission Management

### Q7
- **Category**: conceptual
- **Question**: What is the agent definition priority order?
- **Options**: A) Project > User > CLI | B) CLI > Project > User | C) User > CLI > Project | D) All are equal priority
- **Correct**: B
- **Explanation**: Full order is managed settings > `--agents` flag > project (`.claude/agents/`) > user (`~/.claude/agents/`) > plugin. Of the options listed, CLI > Project > User is the correct relative ordering.
- **Review**: Agents configuration section

### Q8
- **Category**: practical
- **Question**: From your shell, how do you start a new session from the saved session `feature-auth` so the original session stays unchanged?
- **Options**: A) `claude --clone feature-auth` | B) `claude --resume feature-auth --fork-session` | C) `claude --branch feature-auth` | D) `claude --resume feature-auth`
- **Correct**: B
- **Explanation**: `--fork-session` (used with `--resume` or `--continue`) creates a new session ID instead of reusing the original, so the original conversation is preserved. Plain `--resume` reopens the same session and adds to it. Inside a running session, `/branch` does the equivalent and switches you into the copy; `/fork` copies the conversation into a new background session.
- **Review**: Session Fork section

### Q9
- **Category**: conceptual
- **Question**: What exit code does `claude auth status` return when the user is logged in?
- **Options**: A) 1 | B) 0 | C) 200 | D) It doesn't return an exit code
- **Correct**: B
- **Explanation**: `claude auth status` exits with code 0 when logged in, 1 when not. This makes it scriptable for CI/CD authentication checks.
- **Review**: CLI commands table

### Q10
- **Category**: practical
- **Question**: How do you process multiple files in a batch with Claude?
- **Options**: A) `claude --batch *.md` | B) Use a for loop: `for file in *.md; do claude -p "summarize: $(cat $file)" > ${file%.md}.json; done` | C) `claude -p --files *.md "summarize all"` | D) Batch processing is not supported
- **Correct**: B
- **Explanation**: Use shell for-loops with print mode to process files one at a time. Each invocation is independent and can produce structured output.
- **Review**: Batch processing section

---

**Last Updated**: October 18, 2026
**Claude Code Version**: 2.1.302
**Sources**:
- https://code.claude.com/docs/en/hooks
- https://code.claude.com/docs/en/skills
- https://code.claude.com/docs/en/mcp
- https://code.claude.com/docs/en/memory
- https://code.claude.com/docs/en/sub-agents
- https://code.claude.com/docs/en/permission-modes
- https://code.claude.com/docs/en/checkpointing
- https://code.claude.com/docs/en/plugins-reference
- https://code.claude.com/docs/en/cli-reference
- https://code.claude.com/docs/en/model-config#extended-thinking
- https://code.claude.com/docs/en/plugins/install
- https://code.claude.com/docs/en/commands
- https://code.claude.com/docs/en/plugins/cli-reference
- https://code.claude.com/docs/en/plugins
- https://code.claude.com/docs/en/hooks#pretooluse-decision-control
- https://code.claude.com/docs/en/mcp#environment-variable-expansion-in-mcp-json
- https://code.claude.com/docs/en/mcp#configure-tool-search
- https://code.claude.com/docs/en/skills#frontmatter-reference
- https://code.claude.com/docs/en/checkpointing#automatic-tracking
- https://code.claude.com/docs/en/mcp#example-connect-to-github-for-code-reviews
- https://code.claude.com/docs/en/changelog#2-1-302
- https://code.claude.com/docs/en/interactive-mode
