▲ Claude Academy
Sign in

Vault note

Course: Claude Code 101

Mirrors: Anthropic Academy — Claude Code 101 · https://anthropic.skilljar.com/claude-code-101 Audience: Developers, beginner. Comfortable in a terminal; no agent experience needed. · Time: ~60 min + project Prereqs: A terminal, Node.js, and a Claude account (setup-checklist). · Backing notes: claude-code-overview, claude-code-md Project: p10-claude-code-onboarding

Claude Code is Claude with hands on your codebase. By the end of this course you can install it, run a first session, understand the permission model that keeps it safe, watch it use its built-in tools to explore a repo, ship a small real change, and write a CLAUDE.md so every future session starts oriented.

Learning objectives

After this course you can:

  • Explain what Claude Code is and where it runs (terminal, IDE, web, CI).
  • Install Claude Code and complete a first interactive session.
  • Read and reason about the permission prompt, and grant/deny appropriately.
  • Name the core built-in tools (Read, Edit, Bash, Grep/Glob) and what each does.
  • Watch Claude explore an unfamiliar repo and follow its reasoning.
  • Make one real, reviewed change end-to-end.
  • Write a starter CLAUDE.md to give the project durable memory.

Module 1 — Meet Claude Code

🎞 Frame 1 · An agent in your terminal · ⏱ ~2 min

🎬 Scene — A terminal. The user types claude, then "what does this project do?" Claude reads files, runs a command, and answers — no copy-pasting code into a chat.

🧠 Concept — Claude Code is an agentic coding tool: it runs where your code lives, reads and edits files, runs shell commands, and works toward a goal across many steps — not a chat box you paste snippets into. (Deeper: claude-code-overview.)

🖼 On screen

Claude.ai chatClaude Code
You paste code inIt reads your files directly
You copy fixes outIt edits files in place
Can't run anythingRuns tests, builds, git
One turn at a timePursues a task over many steps

✅ Checkpoint — In one sentence, what makes Claude Code "agentic" rather than a chat?

🎞 Frame 2 · Where it runs · ⏱ ~2 min

🎬 Scene — Pan across a terminal, a VS Code sidebar, a browser tab, and a CI log — same agent, four homes.

🧠 Concept — The same agent runs on several surfaces. Start in the terminal; the rest are the same model with a different frame around it.

🖼 On screen

claude                 → interactive REPL in your terminal
VS Code / JetBrains    → same agent inside your editor
claude.ai/code         → short sessions in the browser
claude -p "…"          → one-shot / scripted / CI (non-interactive)

✅ Checkpoint — Which invocation would you use inside a CI job with no human present?

🎞 Frame 3 · Install & first session · ⏱ ~3 min

🎬 Scene — npm install -g @anthropic-ai/claude-code, then claude inside a repo, then a login prompt, then a blinking cursor ready for a task.

🧠 Concept — Install once, then run claude from inside any project directory. The first run authenticates you; after that, claude drops you into an interactive session scoped to that folder.

🛠 Try it now

npm install -g @anthropic-ai/claude-code
cd your-project
claude            # authenticate, then you're in
> /help           # see commands
> what does this repo do?

✅ Checkpoint — Why does it matter which directory you're in when you launch claude?

Module 2 — The permission model

🎞 Frame 4 · Claude asks before it acts · ⏱ ~3 min

🎬 Scene — Claude wants to run npm test. A prompt appears: Allow once · Allow always · Deny. The user reads the exact command first.

🧠 Concept — Every tool call passes a permission check. By default, anything that changes your system (editing files, running Bash) prompts for approval. You stay in control of what actually happens. (Deeper: claude-code-settings.)

🖼 On screen

Claude wants to run:
  Bash(npm test)
  [ Allow once ]  [ Allow always for "npm test:*" ]  [ Deny ]

⚠️ Gotcha — "Allow always" persists the rule. Read the command before you grant a broad pattern — Bash(rm:*) is not what you want to wave through.

✅ Checkpoint — What's the difference between "Allow once" and "Allow always"?

🎞 Frame 5 · Where permissions are stored · ⏱ ~2 min

🎬 Scene — Two files highlighted: ~/.claude/settings.json (personal) and .claude/settings.json (committed, shared with the team).

🧠 Concept — Granted rules are saved as permission strings in settings.json. Project settings live in the repo and are shared with teammates; user settings are personal and global. The first matching rule wins.

🖼 On screen

// .claude/settings.json  (committed → whole team gets these)
{
  "permissions": {
    "allow": ["Bash(npm test:*)", "Read(./src/**)"],
    "deny":  ["Bash(rm -rf:*)", "Read(./.env)"]
  }
}

✅ Checkpoint — Where would you put a permission so every teammate inherits it? (Hint: which file is committed?)

🎞 Frame 6 · Safer modes & guardrails · ⏱ ~2 min

🎬 Scene — A toggle cycles modes: normal (asks), plan (read-only), and an auto-accept option for trusted, fenced work.

🧠 Concept — When you want Claude to think before touching anything, use plan mode (read-only — proposes a plan, makes no changes). Save auto-accept for sandboxes or tightly-scoped tasks you'll review. (Deeper: claude-code-plan-mode.)

✅ Checkpoint — When would you start a session in read-only plan mode instead of normal mode?

Module 3 — Built-in tools & exploring a repo

🎞 Frame 7 · The core toolbox · ⏱ ~3 min

🎬 Scene — A legend appears as Claude works: it Greps for a symbol, Reads a file, makes an Edit, runs Bash, and ticks a task off.

🧠 Concept — Claude Code ships with built-in tools. You don't invoke them — Claude picks them to accomplish your request. Knowing them helps you read what it's doing.

🖼 On screen

ToolDoesReplaces you typing
ReadRead a filecat, opening in an editor
Grep / GlobSearch by content / by pathgrep -r, find
Edit / WriteTargeted edit / full rewritehand-editing
BashRun a shell commandrunning tests, git, builds
Task toolsTrack multi-step worka TODO list

✅ Checkpoint — Which tool does Claude use to find every place a function is called?

🎞 Frame 8 · How it explores a repo · ⏱ ~3 min

🎬 Scene — Asked "how does auth work here?", Claude greps for login, reads the handler, follows the import to the middleware, then explains — citing real file paths.

🧠 Concept — Claude explores before it answers: search → read the hits → follow the references → synthesize. It grounds answers in your code, which is why its explanations cite real paths instead of guessing.

🖼 On screen

You: How does authentication work in this repo?
  → Grep "login|session|auth"        (find entry points)
  → Read src/auth/handler.ts          (read the hit)
  → Grep "verifyToken"                (follow the reference)
  → Read src/middleware/auth.ts
  ← "Auth is JWT-based: handler.ts issues, auth.ts verifies…"

✅ Checkpoint — Why are Claude Code's explanations more trustworthy than asking a chat to "explain auth" from memory?

🎞 Frame 9 · Your first real task · ⏱ ~3 min

🎬 Scene — "Add input validation to the signup form and a test for it." Claude finds the form, makes the edit, writes a test, runs it green, and shows the diff.

🧠 Concept — A good first task is small, real, and verifiable: one behavior, with a test or command that proves it. You review the diff and approve — you're the reviewer on every change.

🛠 Try it now — In a repo you know, ask: "Add a test for the X function, run it, and show me the diff." Then read the diff before approving.

⚠️ Gotcha — Don't approve a diff you haven't read. The agent is fast; your review is the safety net.

✅ Checkpoint — Name the two properties that make a task a good first job for Claude Code.

Module 4 — Memory with CLAUDE.md

🎞 Frame 10 · The orientation problem · ⏱ ~2 min

🎬 Scene — A fresh session re-discovers the same things: "use pnpm not npm," "tests are in __tests__." Every session relearns it.

🧠 Concept — Each session starts cold. Without a memory file, Claude re-derives your conventions every time — and sometimes guesses wrong. CLAUDE.md fixes this. (Deeper: claude-code-md.)

✅ Checkpoint — What problem does a project memory file solve?

🎞 Frame 11 · Writing a CLAUDE.md · ⏱ ~3 min

🎬 Scene — A short CLAUDE.md at the repo root: what the project is, how to run it, the conventions, and a "do NOT" list. Next session, Claude already knows them.

🧠 Concept — CLAUDE.md is the durable "how to work in this repo" doc Claude reads automatically at session start. Keep it short and command-heavy — orientation, how to run/test, conventions, and pitfalls. It's hierarchical: ~/.claude/CLAUDE.md (personal) merges with the project file.

🖼 On screen

# acme-api

## What this is
Node/TypeScript REST API for the billing service.

## How to run
- `pnpm install` then `pnpm dev`
- Tests: `pnpm test`  (lives in __tests__/)

## Conventions
- TypeScript strict; no `any`
- Use pnpm, never npm

## Do NOT
- Edit files under `generated/`
- Touch `src/legacy/` without asking

⚠️ Gotcha — Keep it tight. A bloated CLAUDE.md dilutes every rule — Claude weights them roughly equally, so a rule buried in prose gets missed.

✅ Checkpoint — Name three things that belong in a CLAUDE.md and one that doesn't.

🎞 Frame 12 · You're up and running · ⏱ ~1 min

🎬 Scene — Recap: installed, ran a session, granted permissions wisely, watched it explore, shipped a reviewed change, wrote CLAUDE.md.

🧠 Concept — You can now do real work with Claude Code safely. Next, level up to plan mode, custom commands, hooks, and subagents in claude-code-in-action.

✅ Checkpoint — Without looking, list the core built-in tools and where project permissions are stored.

🛠 Project

Complete p10-claude-code-onboarding — Onboarding a Repo to Claude Code. You'll install Claude Code, run a session in a real repo, have Claude explore and explain one subsystem, ship one small reviewed change with a test, and commit a starter CLAUDE.md plus a sensible project settings.json.

🧪 Self-check quiz

  1. What makes Claude Code "agentic" versus a chat?
  2. Which non-interactive invocation suits a CI job?
  3. What does every tool call pass through before it runs?
  4. In which file do you put a permission so the whole team inherits it?
  5. Which built-in tool finds every callsite of a function?
  6. Describe the loop Claude uses to explore an unfamiliar repo.
  7. Name two things that belong in CLAUDE.md and one that doesn't.
<details><summary>Answers</summary>
  1. It runs where the code lives and acts on it (reads/edits files, runs commands) toward a goal over many steps. 2. claude -p "…" (non-interactive / --print). 3. A permission check. 4. The committed project .claude/settings.json. 5. Grep. 6. Search → read the hits → follow references → synthesize, citing real paths. 7. Belong: how to run/test, conventions, do-NOT list, project orientation. Doesn't: long architecture prose, anything that changes weekly.
</details>

🎓 Certificate criteria

You've "passed" Claude Code 101 when you can:

  • Install Claude Code and complete an interactive session.
  • Read a permission prompt and grant/deny appropriately.
  • Have Claude explore a repo and explain a subsystem from real files.
  • Ship one small, reviewed change with a passing test.
  • Write and commit a starter CLAUDE.md.
  • Complete p10-claude-code-onboarding and journal one thing the exploration surfaced.

Tick this course off in progress and record the date you earned Anthropic's official Claude Code 101 certificate.

🔗 Sources & deeper notes