The 10 concepts of Claude Code

Tap any concept to jump to its 5-card cluster.

• 1Orchestration FrameworkSix layers above a coding assistant
• 2CLAUDE.md HierarchyCascading project memory, user to subdir
• 3Commands vs SkillsSpeed-dial workflows vs forked specialists
• 4Plan ModeBlueprints first, or pick up the hammer
• 5Permission ModesVisitor pass, badge, master key
• 6settings.json SurfaceFive-level cascade and the eight knob groups
• 7CI/CD & BatchHeadless pipelines, session isolation, 50% off
• 8Background & CompositionWorktrees, two-Claude review, /loop, /schedule
• 9Power-User Cheat SheetShortcuts, sessions, ultrathink, headless pipes
• 10End-to-End & RolloutSix-step feature flow + 5-day adoption plan

Claude Code is an orchestration framework

Most developers treat Claude Code like a faster Stack Overflow: type a question, get code, copy-paste. That's the wrong mental model. Claude Code is an agent orchestration framework that happens to be excellent at coding. It runs the same ReAct loop you saw in M12, with the same tool-use pattern from M05, against your real filesystem and shell.

Once you see the six layers stacked on top of the main agent — CLAUDE.md, Skills, Slash Commands, Hooks, Subagents, MCP servers — you stop fighting the tool and start composing it. Most developers only ever touch Layer 0 (CLAUDE.md). The top 1% compose all six.

Tools you use vs systems you configure

BEFORE: Copilot and Cursor are tools you use. Press a key, get a suggestion, accept or reject. They cap out at making you faster at your current workflow — you are the glue between every suggestion.

PAIN: Devin and other full-autonomy SWE-agents go the opposite way: submit, walk away, hope for the best. They trade steerability for autonomy, which is great for benchmarks but painful when you need to course-correct mid-task.

MAPPING: Claude Code sits in between as a system you configure and orchestrate. It takes complete handoffs (multi-file, multi-step) but you stay in the architectural loop. That sweet spot is exactly why the six-layer config surface matters: configure once, get autonomous-but-steerable behavior on every session.

The six configuration layers

1. CLAUDE.md — persistent memoryLoaded automatically every session. Project conventions, key files, things Claude tends to get wrong on this codebase.
2. Skills — on-demand knowledgeSelf-contained playbooks that can run in a forked context, restrict tools, and auto-invoke when their description matches the request.
3. Slash Commands — reusable workflowsMarkdown files that become /your-command. You explicitly trigger them; great for repeating, scoped tasks.
4. Hooks — deterministic automationShell scripts that fire on events (PreToolUse, PostToolUse, Stop). Hooks turn an LLM "rule" into a guaranteed enforcement.
5. Subagents — parallel specialistsFocused agents (security reviewer, doc writer) with their own system prompt and tool subset. Parent delegates and integrates results.
6. MCP servers — external tool connectionsPlug live systems (GitHub, Postgres, Slack, Jira) into Claude as tools using the Model Context Protocol.

Layer 0 alone makes Claude smarter about your codebase. Layered together, they describe a programmable engineering team you configure once and reuse forever.

Pick the right AI coding tool

# Question: which AI coding tool fits this task?

IF task is "single line / single function":
  USE a completion tool # Copilot, Cursor inline
  # latency < 200ms matters more than autonomy

ELIF task is "multi-file feature, you want to steer":
  USE Claude Code # this module
  # compose CLAUDE.md + hooks + subagents + MCP

ELIF task is "narrow benchmark, no human nearby":
  CONSIDER a full-autonomy agent
  # trades steerability for unattended runs

ELSE:
  START with Claude Code default behavior
  # add layers as you hit pain

Default to Claude Code for anything beyond a one-line edit. Add layers as the pain accumulates — not before.

Misconceptions

CLAUDE.md is the persistent system prompt

Every Claude Code session starts from zero memory of your project. CLAUDE.md is the only file loaded automatically every time, on every session, in every directory it applies to. It is how you give Claude permanent memory.

Treat it like a system prompt, not a README. The model reads it as runtime instructions: code conventions, key files, "always run tests after changing X," things this codebase tends to get wrong. If you would not put a line in a system prompt, do not put it in CLAUDE.md.

CSS cascading for instructions

BEFORE: CSS has three layers — the global stylesheet on <body>, a class for one section, an inline style on one element. The most specific rule wins, and rules merge top-down.

PAIN: Without that cascade, every page would copy-paste the same rules and personal tweaks would conflict with team standards. Updates would mean editing dozens of files.

MAPPING: CLAUDE.md works exactly the same way. User-level is your personal global stylesheet (every project, everywhere). Project-level is the team class rules (committed, shared). Directory-level is the inline override for one specialized area. All levels merge; the most specific wins.

Four locations, one instruction budget

1. User-level — your defaultsPersonal preferences (indentation, commit style) that apply to every project you open. Never gets committed to anyone else's repo.
2. Project root — team standardsTech stack, API conventions, database rules, "things Claude tends to get wrong here." Committed to git so every developer shares the same Claude.
3. Local override — private project tweaksPersonal overrides for THIS project (sticky-notes only you see). Lives next to the project file but is gitignored.
4. Directory-scoped — on-demandLoads only when Claude is working in that subtree. Use for areas with different rules: API layer, payments, database migrations.
5. Respect the instruction budgetPractical limit: ~150–200 instructions. Beyond that, dropout kicks in — Claude silently decides parts "may not be relevant" and ignores them.

The CLAUDE.md test: before adding a line, ask "Would Claude make a mistake without this?" If no, delete it. Document corrections, never confirmations.

How the cascade resolves a rule

# When Claude Code starts a session, it builds an
# effective rule set by walking from general to specific.

FUNCTION resolve_rule(key, working_dir):
  rules = []

  IF EXISTS ~/.claude/CLAUDE.md:
    rules.append(load_user_level())          # global

  IF EXISTS ./CLAUDE.md:
    rules.append(load_project_root())        # team

  IF EXISTS ./CLAUDE.local.md:
    rules.append(load_local_overrides())     # private

  FOR dir IN walk_up(working_dir, until=project_root):
    IF EXISTS dir + "/CLAUDE.md":
      rules.append(load(dir))                # scoped

  # Most specific wins for the same key
  RETURN merge(rules, strategy="specific_wins")

Use @import other-file.md inside CLAUDE.md to compose without bloating one file. Recursive imports up to 5 hops. Run /memory to see what Claude actually loaded.

Misconceptions

Slash commands and skills are repeatable workflows

A slash command is a markdown file in .claude/commands/ that becomes /your-command. You explicitly type it. The body is a prompt with optional argument placeholders and a small frontmatter block (allowed tools, model, description).

A skill is the same idea with two superpowers: it can run in a forked context (so its file-reading noise never pollutes your main session) and it can auto-invoke when its description matches what you asked for. Modern setups treat skills as the upgraded form; commands stay around as the simple, focused option.

Speed-dial vs delegating to another room

BEFORE: A command is like a speed-dial button. You press it, it runs the prompt you wired up. Fast, predictable, exactly what you defined.

PAIN: If that command reads 50 files looking for a pattern, all 730 lines of file content land in your main conversation — cluttering the context you were actually using. Your session gets noisy.

MAPPING: A skill with a forked context is like delegating that exploration to an assistant in another room. They open the files, do the analysis, come back with a one-paragraph result. Your workspace stays clean. The exploration happened — you just didn't have to live in it.

The lifecycle of an invocation

1. DiscoveryClaude Code scans .claude/commands/ and .claude/skills/ at session start; new files appear in the / menu without restart.
2. TriggerYou type /name args, OR (skills only) Claude auto-triggers when your prompt matches the skill's description.
3. RenderFrontmatter is parsed; argument placeholders are substituted; any inline shell commands are executed and their output inlined into the prompt.
4. ExecuteThe rendered body becomes one message in the conversation. Allowed-tools / context: fork settings apply for the rest of that turn.
5. ReturnForked skills return only their final summary to the main session; non-forked commands leave their full conversation in main context.

Skills also support auto-invocation: front-load the use case in the description and Claude can trigger the skill without you typing anything.

Command, skill, or just a prompt?

Misconceptions

Plan first, or pick up the hammer

By default, Claude Code reads your prompt and immediately starts editing files, running commands, iterating. Plan mode changes that: Claude still analyzes the codebase, but stops before any change. Instead it outputs a structured plan — files to modify, intended changes, risks — and waits for your approval.

This is more than "thinking before acting." Plan mode forces the agent to commit to a strategy before editing anything, which catches dependency chains upfront and prevents half-finished states where Claude refactors A, realizes B needed to change first, and undoes its own work.

Architect's blueprints vs builder's hammer

BEFORE: A builder picks up a hammer and starts — fast, efficient, exactly right when the task is clear (hang a picture frame, swap a doorknob).

PAIN: Hand the same builder a house with no blueprints and you get load-bearing walls in the wrong place, plumbing that doesn't connect, expensive rework. Always-skip-planning is disaster on complex jobs.

MAPPING: Plan mode is the architect drawing blueprints first — you review, adjust, approve, then construction starts. Direct execution is the builder with the hammer. The skill isn't picking one and sticking with it: it's matching the mode to the job.

The plan-mode loop

1. TriggerPress Shift+Tab mid-session (cycles Normal → Auto-Accept → Plan), or start with --permission-mode plan.
2. AnalyzeClaude reads files, traces dependencies, looks for gotchas — without modifying anything.
3. Output the planStructured proposal: numbered steps, files to modify, risk level, reversibility note.
4. Human gateYou read it. Approve, edit (open in $EDITOR), or send back with feedback.
5. Execute or reviseOn approval, Claude switches out of plan mode and executes. On feedback, it revises and re-presents.

Always read the "Files modified" and "Risk" lines critically. A plan can still be wrong — plan mode reduces the chance, it doesn't eliminate it.

Plan mode or direct execution?

# Question: should this task go through plan mode?

IF change touches 5+ files
   OR codebase is unfamiliar
   OR change is risky (schema, prod, auth)
   OR hard to reverse (data migration, deletion):
  USE plan mode
  # the overhead pays for itself

ELIF change is simple AND well-understood
     AND reversible (rename, typo fix):
  USE direct execution
  # planning here is wasted overhead

ELSE:
  DEFAULT to plan mode for new sessions
  # you can always switch with Shift+Tab

The cert exam tests this directly — the "always plan" answer is wrong. Pick the right mode for the task.

Misconceptions

Four modes, one safety/speed dial

Claude Code has four permission modes that control which tool calls require user approval before execution: plan, default, acceptEdits, and bypassPermissions. Set them globally, per-project, or per-session.

Most production work happens in default or acceptEdits, but knowing all four is the difference between a paranoid workflow that interrupts you constantly and a reckless one that breaks production. The cert exam tests mode-to-scenario fit directly.

Visitor pass, employee badge, master key

BEFORE: A work badge is a security level. Visitor pass: you can look around but every door asks for an escort. Employee badge: most doors open, sensitive areas still need approval. Master key: every door opens, no questions.

PAIN: Give a contractor on day one a master key and they wreck the wrong floor. Force the building manager to escort them through every door and they accomplish nothing.

MAPPING: Permission modes are exactly that dial. plan is the visitor pass (read-only). default and acceptEdits are the employee badge (most work, sensitive doors prompt). bypassPermissions is the master key — only inside ephemeral sandboxed containers, never on a workstation with prod credentials.

The four modes side by side

Modes combine with allowlists and denylists in settings.json. The mode sets the default policy; the lists are the fine-grained overrides.

Pick the mode for the situation

# Question: which mode for THIS session?

IF reviewing risky migration / unfamiliar repo:
  USE plan
  # read-only safety

ELIF production-touching work on your laptop:
  USE default
  # prompt-on-first-use is the right friction

ELIF greenfield / prototyping / scaffolding:
  USE acceptEdits
  # edits flow, shell still prompts

ELIF unattended CI inside a sandboxed container:
  USE bypassPermissions + strict allowlist
  # OS sandbox is the real boundary

ELSE:
  DEFAULT to default mode
  # the safest interactive starting point

Misconceptions

settings.json is the configuration surface

Where CLAUDE.md is advisory guidance, settings.json is enforced guarantees. It's where permissions, hooks, MCP servers, sandbox rules, model defaults, and the built-in tool allowlist all live. Claude Code merges settings from up to five sources for every session: managed (admin), CLI flags, local, project, user.

Higher-priority levels override lower ones for the same key. A few "managed-only" keys (allowedMcpServers, disableSkillShellExecution) cannot be set at any other level — that's how IT pins down policy.

The corporate laptop's layered controls

BEFORE: A work laptop has layered controls. IT admin policies (can't disable VPN). Your own preferences (dark mode, shortcuts). Project-folder tweaks (this client's VPN config). Local sticky-notes (skip auth on dev).

PAIN: Without that layering, every team member duplicates the same setup, security policies live in untrusted places, and personal preferences leak into shared config. Updating policy means hunting through dozens of files.

MAPPING: settings.json's five-level cascade does exactly the same job. Managed wins outright (admin policy). CLI flags override per-session. Local overrides project. Project overrides user. Same key — higher level wins. Different keys — everything composes.

Eight knob groups, one file

1. PermissionsAllow / ask / deny lists, default mode, additional directories, lock-out flags. The fine-grained partner to permission modes.
2. Model & effortDefault model, available models, effort level, always-thinking toggle. Tunes cost and quality per project.
3. HooksShell scripts wired to lifecycle events (PreToolUse, PostToolUse, Notification, Stop). Where rules become enforcement.
4. MCPWhich MCP servers are enabled, which are explicitly forbidden, which are pre-approved without per-call prompts.
5. Plugins & skillsPlugin marketplaces, skill shell execution policy, channel restrictions.
6. SandboxToggle the OS-enforced jail, allow/deny filesystem paths, network domain rules, command exclusions.
7. Git & attributionCo-author trailer, PR description templates, custom PR-URL pattern, git instructions toggle.
8. UX & accessibilityEditor mode (vim/normal), reduced motion, voice mode, status line script, custom spinner verbs.

How settings resolve at session start

# Five levels, top wins for the same key

FUNCTION resolve_setting(key):
  layers = [
    load_managed(),       # 1. admin policy (MDM/GPO)
    load_cli_flags(),     # 2. --model, --permission-mode
    load_local(),         # 3. .local.json (gitignored)
    load_project(),       # 4. .claude/settings.json
    load_user(),          # 5. ~/.claude/settings.json
  ]

  FOR layer IN layers:
    IF key IN layer:
      # scalar key: top-most wins outright
      IF is_scalar(key): RETURN layer[key]
      # array key (allow/deny lists): UNION across layers
      IF is_array(key): merged.extend(layer[key])

  RETURN merged

Cert exam fact: scalars use precedence (top wins); array fields like permissions.allow are unioned across layers. Memorize which keys behave which way.

Misconceptions

Headless Claude for pipelines and bulk work

Claude Code runs in non-interactive mode with the -p flag: feed it a prompt, it prints the result and exits. Combined with --output-format json and --json-schema, your CI scripts get structured fields instead of regex-ing freeform prose.

The matching pattern for high-volume tasks (10K+ requests, latency-tolerant) is the Message Batches API: package up to 10,000 requests, process them within 24 hours, pay 50% less. Both belong in the same cluster because both replace "human in front of a terminal" with "machine in a pipeline."

The author and the cold reviewer

BEFORE: Good engineering teams never let one person both write the code and be the only reviewer. The author has the rationalization — "this shortcut made sense at the time" — that a fresh reader doesn't.

PAIN: If the same Claude session generates code AND reviews it, the reviewer still holds the generator's reasoning. Confirmation bias kicks in: the reviewer agrees with the code because it remembers why each line was written that way.

MAPPING: CI/CD with session isolation mirrors the human pattern. Session A writes the code (full context). Session B reads only the diff (cold context). B has no rationalization to fall back on. That's why the cert exam treats same-session self-review as the wrong answer.

Headless and batch in one cluster

1. Trigger from CIThe pipeline (GitHub Actions, GitLab CI) installs Claude Code, sets ANTHROPIC_API_KEY, runs claude -p "..." --output-format json against the diff.
2. Session A — summarizeFirst invocation reads the diff, returns a structured summary (what changed, why it might have changed).
3. Session B — cold reviewSeparate invocation, separate process, separate session. Reviews the same diff for bugs, security, missing tests — with zero knowledge of A's reasoning.
4. Schema-validated output--json-schema constrains the output shape (e.g. verdict / blocking_issues[] / confidence). Your script parses fields, not prose.
5. Batch for bulkLatency-tolerant work (10K filings, codebase audit, dataset labeling) goes to the Batch API: submit, wait up to 24h, collect results, pay 50% less.

Common gotcha: shallow git clones. Set fetch-depth: 0 in CI checkout, otherwise git diff origin/main...HEAD finds nothing.

CI review pipeline + batch loop

# --- Headless CI review with session isolation ---
FUNCTION review_pr(diff):
  summary = CALL claude_p(
    prompt="Summarize this diff.",
    diff=diff,
    schema="summary.json"
  )
  # SEPARATE invocation = fresh context
  review = CALL claude_p(
    prompt="Review for bugs, security, test gaps.",
    diff=diff,
    schema="review.json"
  )
  RETURN {summary, review}

# --- Batch API for 10K-request workloads ---
FUNCTION bulk_extract(documents):
  requests = [build_request(d) FOR d IN documents]
  batch = batches.create(requests)

  WHILE batch.status != "ended":
    sleep(60)
    batch = batches.get(batch.id)

  successes, errors = [], []
  FOR result IN batch.results:
    IF result.ok: successes.append(result)
    ELSE: errors.append(result)
  RETURN successes, errors

Always handle partial success in batch — some requests may fail (oversized, malformed). Never assume 100%.

Misconceptions

Stop doing the work in real-time

Single-session Claude Code is already a force multiplier. The top-1% workflow is composition: multiple Claude sessions in parallel via git worktrees, scheduled background agents, cold reviews of your own work, and remote-control sessions you check from your phone.

The pattern is always the same: stop doing the work serially in your main session. Spawn it, parallelize it, schedule it, or hand it to a fresh reviewer. Once the architecture supports autonomous, parallel work, you stop being the bottleneck.

From solo contributor to engineering team

BEFORE: A solo developer does every task serially: think, code, test, review, write the PR, monitor the build. Throughput is bounded by one human's wall clock.

PAIN: Adding more tasks doesn't add hours in the day. Long-running things (build, deploy, scan) block real work. Self-review is unreliable because you remember why you wrote each line.

MAPPING: Composition turns one Claude session into a team. Worktrees are parallel desks. Two-Claude review is a fresh reviewer who reads the diff cold. /loop is the monitoring intern. /schedule is the agent that runs while you sleep. Remote control is checking in from your phone on the way to a meeting.

Five composition primitives

1. Git worktreesCheck out multiple branches into separate directories. Two terminals, two Claude sessions, zero collisions on the working tree.
2. Two-Claude reviewSession A implements with full context; Session B reads the last commit cold and returns a structured MUST FIX / SHOULD FIX / CONSIDER report.
3. /loop <interval>Background monitoring on a cadence: "every 5 minutes, check the CI pipeline; ping me only if it changes." Self-paced if you omit the interval.
4. /schedule <cron>Cron-style remote agent that runs even when your laptop is closed. Monday-morning PR triage, two-week-out feature-flag cleanup.
5. Remote controlRun claude remote-control on your machine, then connect from claude.ai or the iOS app. Your machine does the work; the phone is just a window.

Plugins package skills + commands + hooks + subagents into one installable bundle — how teams standardize agent infrastructure across repos.

The two-Claude review loop

# Worktree-isolated two-session review

FUNCTION ship_with_review(feature):
  worktree_a = create_worktree(branch="feat/" + feature)
  session_a = open_claude(in=worktree_a)

  # Implementer: full conversation context
  session_a.run("implement " + feature + " from SPEC.md")
  session_a.run("run tests; commit when green")

  # Reviewer: empty context, cold read
  session_b = open_claude(in=main_checkout)
  report = session_b.run(
    "review the last commit on " + worktree_a.branch +
    " as a staff engineer. Be harsh. Output:
    MUST FIX / SHOULD FIX / CONSIDER."
  )

  IF report.must_fix:
    session_a.run("apply MUST FIX items: " + report)
    RETURN ship_with_review(feature)  # iterate

  cleanup(worktree_a)
  RETURN open_pr(branch=worktree_a.branch)

Misconceptions

Daily workflow primitives separate "use it" from "use it well"

The Claude Code surface that ships in the docs — keyboard shortcuts, session resume, extended thinking, headless pipes, image input, image-paste, the @-file prefix — is the operational vocabulary the cert exam assumes you know. None of it is hidden; all of it compounds.

This cluster is the consolidated cheat sheet: the small daily primitives that turn a working setup into a fast one. Memorize the high-frequency ones; the rest live in your editor's autocomplete.

The vim user vs the arrow-key user

BEFORE: Two engineers open the same editor. One uses arrow keys, mouse, and pull-down menus. The other knows the keybindings.

PAIN: Both ship features, but the arrow-key user spends 30% of their day on micro-context switches: hand to mouse, find menu, click, hand back to keyboard. The compounding cost is huge over a year.

MAPPING: Same with Claude Code. Knowing Shift+Tab for plan mode, --continue for last session, ultrathink for one-prompt extended thinking, @file for inline content — pulls the friction out of every interaction. Each shortcut saves seconds; the year-long compound is hours.

The high-frequency cheat sheet

Phrases like "think hard" are read as regular prompt text. Only ultrathink is interpreted as a thinking-budget instruction.

Pick the right scheduling tool

Scheduled runs can't ask clarifying questions — be explicit about success criteria and what to do with results in the prompt itself.

Misconceptions

The payoff is composition, and you don't get there in one day

You've now seen every primitive. The end-to-end payoff is a real workflow: ship a new API endpoint with CLAUDE.md loaded, plan via interview, implement TDD-style with PostToolUse linting, cold-review with a subagent, security-audit with another subagent, PR via GitHub MCP. Two to three hours of manual work compresses to roughly 25 minutes.

And you don't add all six layers on day one. The 5-day rollout walks the prioritized order: CLAUDE.md, then your first hook, then two-Claude review, then your first subagent, then your first MCP server. Week 2+ is iteration: refine CLAUDE.md based on what Claude keeps getting wrong; add domain-specific skills; build the full pipeline.

Driver vs road builder

BEFORE: A driver is graded on the lap time on the road they're given. Better technique helps, but they're capped by what the road allows.

PAIN: Most developers stay drivers with Claude Code. They get 20% faster by writing better prompts, then plateau. The bottleneck wasn't their driving; it was the road.

MAPPING: Top-1% developers build the road. They invest a week up front in CLAUDE.md, hooks, subagents, an MCP server. Each session after that compounds: less context to re-establish, more quality gates running automatically, more parallel work happening without supervision. It's not about being a better driver — it's about building a better road.

The end-to-end feature flow

1. CLAUDE.md is already loadedYou set it up once. Every new session knows your stack, test framework, gotchas. Zero per-session setup.
2. Interview pattern via AskUserQuestionAsk Claude to interview you about auth, caching, response shape, edge cases. Don't assume; surface requirements first. Output: SPEC.md.
3. Implement in a fresh session, TDD-style"Implement the spec in SPEC.md." PostToolUse hook auto-lints every write. PreToolUse hook blocks dangerous commands.
4. Cold review by code-reviewer subagent"Use the code-reviewer subagent on the last commit." Returns MUST FIX / SHOULD FIX / CONSIDER. Apply MUST FIX, re-run tests.
5. Security audit by security-auditor subagentScans for injection, exposed secrets, auth gaps, missing rate limits. Returns clean (or more fixes).
6. PR via GitHub MCP"Create a PR with the spec, what changed, test summary, known limitations." Claude calls GitHub MCP, links Jira, requests reviewers.

The 5-day rollout, in order of return

Misconceptions

Seven questions across the module

Tap a card to reveal the answer.