Claude Code — study note

Domain 3 of the Claude Certified Developer – Foundations exam covers one skill, Claude Code Operation. It is a small share of the exam, and it rewards knowing when each mechanism applies, not memorizing flags. This note summarizes the topic deck and the Claude Code pages behind it.

The loop and the harness

Every task runs through gather context → take action → verify results. The phases blend, and you can interrupt at any point to steer. Claude Code is the layer around the model that provides the tools and manages the context the model sees; the documentation calls this layer the agentic harness.

Context and sessions

When the window fills, Claude Code clears older tool outputs first, then summarizes. To steer every compaction in a repository, add a Compact Instructions section to CLAUDE.md. Checkpoints cover file changes only; actions on remote systems such as databases, APIs or deployments can't be checkpointed. Your requests and key snippets are kept, but early detailed instructions may be lost. Each new session starts with a fresh context window. Resume appends to the same session. Fork copies the history into a new session and leaves the original unchanged.

Memory, skills and subagents

Where they live:

• Skill: .claude/skills/<name>/ SKILL.md

• Subagent: .claude/agents/

• Both memory systems are context, not enforced configuration. Keep them short, because longer files reduce adherence.

• Create a skill when you keep pasting the same procedure into chat.

• Skill descriptions load by default, with two exceptions. With many skills, some descriptions are dropped to fit the listing's budget, least used first. And disable-model-invocation: true keeps a description out of context, so the skill runs only when you invoke it.

• Auto-memory topic files are not loaded at startup; Claude reads them on demand.

• Delegate exploration to a subagent to keep file reads out of your window. Its requests still count toward the same usage limits.

• Restrict a subagent with the tools allowlist or the disallowedTools denylist.

Running without a person

• claude -p runs a prompt non-interactively. It exits 0 on success and non-zero on failure, so scripts can branch on the exit status.
• --output-format takes one of three values:
  • text, the default;
  • json, which gives the result, session ID and metadata, including an estimated cost (client-side, and it can differ from your bill);
  • stream-json, which gives newline-delimited events.
• --allowedTools pre-approves the listed tools. Set a mode with --permission-mode, for example --permission-mode dontAsk.
• Piped stdin has a size cap. Past it, the run exits with an error, so write large input to a file and reference its path.

Non-interactive runs start in the default (Manual) mode unless you pass a mode. Under dontAsk, actions that need no approval, such as file reads in the working directories, still run, and so do tools you pre-approved. Deny rules block in every mode. Allow rules have no effect in bypassPermissions, and a short list of actions is never auto-approved in any mode.

Settings and everyday workflows

The files, in that order:

• User: ~/.claude/settings.json

• Project: .claude/settings.json

• Local: .claude/settings.local.json

• Worktrees give parallel sessions on separate branches (claude --worktree <name>). The repository needs at least one commit.

• Plan mode proposes a plan and makes no edits until you approve.

• Claude reads files fresh on each tool call, so it sees your manual edits.

• Scheduled tasks run autonomously, so their prompts must say what success looks like and what to do with the results.