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 chat	Claude Code
You paste code in	It reads your files directly
You copy fixes out	It edits files in place
Can't run anything	Runs tests, builds, git
One turn at a time	Pursues 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

Tool	Does	Replaces you typing
Read	Read a file	cat, opening in an editor
Grep / Glob	Search by content / by path	grep -r, find
Edit / Write	Targeted edit / full rewrite	hand-editing
Bash	Run a shell command	running tests, git, builds
Task tools	Track multi-step work	a 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

• Official course: https://anthropic.skilljar.com/claude-code-101
• Vault notes: claude-code-overview, claude-code-md, claude-code-settings, claude-code-plan-mode
• Next course: claude-code-in-action · Domain note: cca-domain-3-claude-code