Agentic AI & Claude Code

From chatbot to autonomous agent — tools, loops, and the future of AI-assisted work.

What Is Agentic AI?

An agent is an AI that doesn’t just answer questions — it takes actions to achieve goals.

🤖
Autonomous Action
“Add input validation to the signup form” → it reads the component, adds a Zod schema, updates the tests, runs them, commits. A chatbot tells you what to do; an agent does it.
🔄
The Loop
Gather read files and run commands → Act edit code → Verify run the tests → Repeat if verification failed. Runs unattended until done or stuck.
🔧
Tool Access
Four families: Bash (any shell command), file I/O (read, edit, glob, grep), web (search and fetch), MCP servers (Slack, GitHub, databases, browsers).
🧑‍💻
Human in the Loop
Deletes and force-pushes need your explicit approval; you can review any tool call before it runs, and redirect mid-task. Augmentation, not replacement.
In Plain English

Simple: A recipe tells you how to make dinner. A cook makes dinner. Both know the same things — only one of them comes back with a plate.

Technical: The model is unchanged. What changes is the harness around it: its output is routed to tools, and the tools’ results are fed back in, so it can observe the consequences of an action and act again.

Chatbot vs. Agent

Same AI model, completely different capabilities.

Feature
Chatbot
Agent
Input
Text only
Text + tool results
Actions
Generates text
Runs commands, edits files
Knowledge
Training data
Live search + file access
Verification
You check output
Runs tests itself
Iteration
Manual rounds
Autonomous loop
Scope
One question
Multi-step tasks
Same task, two shapes
“Make the failing check pass.” One is done in one step; the other keeps going.

Chatbot — a line

Agent — a cycle

  • read the failing check and the code it covers
  • make an edit, run the check again — still failing
  • fix the real cause, run the check again — passing
laps: 0 · the loop exits when the check passes, not after a fixed number of laps
The three checklist lines are an illustrative script — nothing here runs a test or calls a model. What is not illustrative is the shape: an agent alternates acting with checking its own work and repeats until the check passes or it gets stuck, while a chat turn ends after one reply. Three laps is this script’s number; a real task takes as many as it takes.
In Plain English

Simple: Text a friend about your broken bike and you get instructions. Hand them the bike and you get back a working bike.

Technical: Same weights, different loop. A chatbot’s context holds only your turns; an agent’s also holds tool output, so its next prediction is conditioned on the real state of your files rather than on what it remembers about projects in general.

The Loop in Action

Watch how an agent handles a real task: “Fix the failing auth test.”

01
🔍
Gather
Read & understand
02
⚡
Act
Edit & execute
03
✅
Verify
Test & validate
04
🔄
Repeat
Loop if needed
Gather: The agent runs npm test to see the failure, then uses grep to find the relevant source file. It reads the test expectations and the actual implementation to understand the gap.
In Plain English

Simple: It is how you find a leak under a sink: look, tighten something, run the tap, look again. Nobody fixes it in one move, and the tap is what tells you whether you are done.

Technical: The loop closes on an external signal — the test’s exit code — not on the model’s own confidence. That is the whole difference between iterating and repeating: the environment, not the model, decides whether Verify passed.

See It Happen

A simulated agentic workflow — watch the agent gather, act, and verify.

claude — agentic session
In Plain English

Simple: Like watching over someone’s shoulder while they work. You see every step they take, not just the finished result they hand you.

Technical: Every line is a tool call and the output it returned, appended to the conversation. There is no hidden scratchpad here — this transcript is what the model is reasoning over on the next turn.

Built-in Tools

Every Claude Code session comes with powerful tools out of the box. Each is named the way the agent names it in its own output.

💻
Bash
Any shell command, in your project directory with your shell environment — npm test, git diff, lsof -i :3000. The agent sees the full output.
📖
Read
A file with line numbers — and images, PDFs by page range, notebooks with their cell outputs. It reads before it edits.
✏️
Edit
Replaces one unique string. It fails if that string is missing or appears twice — which is the safety property.
📝
Write
Creates a new file, or overwrites one whole. For anything that already exists, Edit keeps the change reviewable.
🔎
Glob / Grep
Glob finds files by name pattern (**/*.test.js); Grep searches contents by regex (TODO|FIXME). This is how it navigates an unfamiliar codebase.
🌐
Web Search & Fetch
WebSearch queries the internet; WebFetch retrieves one named URL. The training data has a cutoff; your dependency versions do not.
In Plain English

Simple: A kitchen already has a knife, a hob and a tap before you buy a single gadget. These six are that kitchen — nothing to install, nothing to configure.

Technical: Each is a function the model may call, with a declared schema for its arguments. Read, Edit, Write, Glob and Grep are deliberately narrower than Bash: a narrow tool fails loudly on the wrong input instead of doing something plausible and unintended.

One Plug, Every Tool

A standard socket, so a tool written once works with every AI that speaks it — the way any USB device works in any USB port. Each server below is one such tool. Click one to explore it.Model Context Protocol

📚
Context7
Query docs for any library
Connected
🎭
Playwright
Control a real browser
Connected
💬
Slack
Read/send messages
Available
🐙
GitHub
Issues, PRs, reviews
Available
🗄️
PostgreSQL
Query databases directly
Available
📁
Filesystem
Advanced file operations
Available
Context7 provides up-to-date documentation for any library. Instead of relying on training data, the agent queries live docs — no more hallucinated APIs.
query-docs("Next.js 15 app router") → Returns relevant sections with code examples.
In Plain English

Simple: A kettle plugs into any wall socket because everyone agreed on the shape of the socket. Nobody manufactures a kettle-shaped hole in the wall.

Technical: MCP standardises the interface — how a server lists its tools, how a tool is invoked, how a result comes back. A server author targets the protocol once instead of writing an integration per AI product (Anthropic, 2024).

How MCP Works

MCP is a standard protocol that connects AI models to external services.

Claude
↔
MCP Client
↔
MCP Server
↔
Service
🔌
Standard Protocol
JSON-RPC over stdio or HTTP. The server declares its tools; any MCP client discovers them. One server, every compatible AI.
🔒
Permission Model
Each tool call can require approval, destructive ones always do, permissions are set per project, and every call is logged.
🧩
Composable
Slack + GitHub: read the bug report, open the issue, fix it, submit the PR, post the link back. Playwright + Filesystem: navigate, screenshot, save.
🏗️
Build Your Own
Wrap internal APIs, give read-only access to production data, trigger deploys, query Grafana or PagerDuty. Any language that can speak JSON-RPC.
In Plain English

Simple: Ordering in a restaurant. You talk to the waiter, the waiter talks to the kitchen, and you never walk in and shout at the chef.

Technical: JSON-RPC over stdio or HTTP with a client in the middle. The client owns discovery, the permission prompt and the log, which is why no server ever gets to talk to the model directly — and why a compromised server is contained rather than catastrophic.

Bash — The Universal Tool

The Bash tool can run any shell command. This is what makes agents truly powerful.

🧪
Run Tests
Whatever command your project already uses to run its tests — npm test, pytest -x, cargo test. This is the Verify step; without tests the agent is flying blind.
📦
Git Operations
git log --oneline -10 for recent context, git diff for what changed, git blame for why. Committing is fine; rewriting history is not, without permission.
📥
Install Packages
npm install zod, pip install requests, cargo add serde. It checks what is already installed first, so you do not end up with two libraries doing one job.
🔍
Inspect Systems
“Which version of Node is this?” → node --version. “What is holding port 3000?” → lsof -i :3000. Most useful when a deploy or a config is misbehaving.
Safety first: Claude Code asks for permission before running destructive commands like rm -rf or git push --force. You stay in control.
In Plain English

Simple: The other tools are specialised kitchen gadgets; the shell is the whole workshop. It is powerful for exactly the reason it needs supervision.

Technical: Bash makes the tool surface unbounded — any binary on your PATH becomes callable, and the agent cannot know in advance what each one does. That is why the permission gate sits on this tool rather than on a list of forbidden commands.

Read, Edit, Write

Dedicated file tools are safer and more precise than shell commands for code changes.

Tool
What It Does
When to Use
Read
View file contents with line numbers
Understanding code before editing
Edit
Exact string replacement in files
Surgical changes to existing files
Write
Create or overwrite entire files
Creating new files only
Glob
Find files by name pattern
Locating files in a project
Grep
Search file contents with regex
Finding code patterns
In Plain English

Simple: You can open a jar with a hammer. A jar opener is less exciting and breaks less glass.

Technical: Edit requires a unique match and errors when it finds none or two, so an ambiguous change fails instead of silently hitting the wrong line. A sed one-liner would have edited both and reported success.

Skills — Reusable AI Workflows

A skill is a pre-built prompt package that handles a specific task. Think of them as AI plugins.

📦
/commit
Auto-generate commit messages from diffs
👀
/review-pr
Review pull requests with detailed feedback
✨
/simplify
Review code for quality, reuse, and efficiency
🏗️
Custom Skills
Build your own slash commands for any workflow
🔁
/loop
Run tasks on recurring intervals
🔗
/claude-api
Build apps with the Claude API
In Plain English

Simple: A recipe card you wrote once because you make the same dish every Sunday. You are not inventing it again each week.

Technical: A skill is a stored prompt template invoked by name. The value is not that the model could not do it unprompted — it is that the instructions are identical every time, so the output is reproducible instead of re-improvised.

CLAUDE.md — The Project Brain

A CLAUDE.md file at your project root gives the agent persistent instructions across every session.

# CLAUDE.md — Project Instructions ## Tech Stack - React 19 + TypeScript 5.7 - Tailwind CSS 4.0 - PostgreSQL via Prisma ORM ## Rules - Always run tests before committing - Use conventional commits - Never modify migration files ## Architecture - API routes in /app/api/ - Shared components in /components/ui/ - Database models in /prisma/schema.prisma
Why it matters: Without CLAUDE.md, the agent starts fresh every session. With it, the agent already knows your stack, conventions, and rules — like an onboarded team member.
In Plain English

Simple: The note taped inside a shared kitchen cupboard: bins go out Tuesday, the oven runs hot. Nobody has to be told twice.

Technical: The file is read into context at the start of every session, so project conventions arrive as instructions rather than as something the model has to infer from the code — and inference is where a plausible-but-wrong convention gets invented.

Managing Context

Everything the agent has read this session sits in one space that does not grow. The commands that reclaim it are Lab 1’s material — what matters here is watching it fill, and choosing when to act.context window

One session, turn by turn
Let it fill and you stall. Compact and you keep going — having thrown something away.
system + instructions your requests & the decisions made tool output (file reads, greps, test logs)
turn 0 · about 10% of the window used
The per-turn amounts are hand-authored and the axis is a percentage of whatever window you have — no session was recorded and nothing here calls an API. Two things are not invented: the window is finite and shared by input and output, and compaction is lossy — it keeps decisions and drops long tool output, exactly as the table above says. The dashed line after a compaction marks roughly where this same session would have stalled without it; it is an extrapolation of this script, not a prediction.
In Plain English

Simple: A desk you cannot make bigger. Every new document you spread out means an older one has to be filed or binned.

Technical: The context window is a fixed token budget shared by instructions, files and tool output. These four commands are the only levers over what occupies it: add deliberately (@path), summarise (/compact), seed (/init), or persist outside it (Memory).

Which Model, When

Three separate dials that beginners turn as if they were one: which model, how hard it thinks, and the keys that stop it.

Look something upfastest model · low effort
An edit you can describe exactlyeveryday model · medium
Find the root causestrongest model · high
Work handed to a subagentfastest model · low
Design or architecture callstrongest model · high
Correctness matters more than coststrongest model · xhigh
lowMechanical, well-specified work
mediumEveryday default
highDiagnosis and judgement
xhighHard problems, cost second
maxDeepest; can overthink
--effort / --list-modelsSet it; check what you have
EscInterrupt generation
Shift+TabCycle permission mode
TabAccept autocomplete
↑Previous message
Opt+EnterMulti-line input
Ctrl+CCancel & new prompt
Run claude --list-models — that is the truth, not this table. Model names change; the roles do not. And the most common, most expensive beginner habit is reaching for the strongest model by default: on a question that was never hard, it is mostly just slower.
In Plain English

Simple: Picking a courier. Same city, same parcel — a bicycle, a van and a lorry are not ranked best to worst, they fit different jobs. Sending everything by lorry is not care, it is waste.

Technical: Model and effort are orthogonal, and coupling them is the error — high effort does not rescue a poorly-scoped task, and the strongest model does not compensate for a context you filled with noise. Effort buys reasoning depth before acting; the model sets the ceiling on what that reasoning can reach.

Plan Mode & Thinking Mode

For complex tasks, slow down and think before acting.

Feature
Plan Mode
Thinking Mode
Trigger
Shift+Tab
“think hard” in prompt
What it does
Reads & plans, no edits
It reasons at length before answeringchain-of-thought
Best for
Architecture decisions
Complex debugging
Output
Step-by-step plan
Deeper analysis
Cost
Lower (read-only)
Higher (more tokens)
Pro tip: Use Plan Mode first to get a plan, review it, then switch back to normal mode and say “execute the plan” to let the agent work.
In Plain English

Simple: Two different ways to slow a decision down. One is asking a builder for drawings before they knock a wall through; the other is asking them to take a proper look first.

Technical: They act on different layers. Plan Mode is a permission constraint — the write tools are simply unavailable. Thinking Mode spends more output tokens on reasoning before the answer. You can run either alone, and they cost differently for that reason.

Hooks — Lifecycle Events

Hooks run your code before or after Claude Code takes an action.

⚠️
PreToolUse
Runs before a tool. Block rm -rf and DROP TABLE, validate paths, or rewrite the inputs. Exit non-zero and the call never happens.
✅
PostToolUse
Runs after a tool returns. Transform the output before the agent sees it, log the result for compliance, or trigger a rebuild.
🔔
Notification
Fires when the agent’s status changes. Ping Slack when a long task finishes, or raise a desktop notification via osascript / notify-send.
🛑
Stop
Fires when the agent decides it is finished. Run a last validation pass, commit anything left uncommitted, write a session summary, clean up temp files.
In Plain English

Simple: The interlock on a microwave door. It is not asking the microwave to behave — it physically cannot run with the door open.

Technical: A hook is deterministic code on a lifecycle event, outside the model’s control. A PreToolUse hook that exits non-zero cancels the call, which is a guarantee; an instruction in CLAUDE.md saying “never do this” is only a strong preference.

Your First Hook

Real-world hooks you can add to .claude/settings.json.

// .claude/settings.json — hooks section { "hooks": { "PreToolUse": [{ "matcher": "Bash", "hooks": [{ "type": "command", "command": "security-check.sh" }] }], "Notification": [{ "matcher": "", "hooks": [{ "type": "command", "command": "notify-slack.sh" }] }] } }
Notice the matcher. It is the only field that decides when your script runs. "Bash" means “only before Bash calls”; the empty string means “every time this event fires”. Everything else here is boilerplate.
In Plain English

Simple: A note on the fridge saying check this before you cook chicken is useless unless it says chicken. Otherwise you either check everything or check nothing.

Technical: matcher is the event filter. It is matched against the tool name, so "Bash" scopes the hook to shell calls and "" fires on every occurrence of that event — including the ones your script was not written to handle.

GitHub Integration

Automate your entire GitHub workflow with Claude Code.

📝
PR Reviews
/review-pr 123 checks four things at once: security (injection, vulnerabilities), logic (edge cases, races), style against your conventions, and performance (N+1 queries, leaks).
🐛
Issue to Fix
claude "fix issue #42" → reads the issue and its comments, searches the codebase, writes the fix plus tests, opens a PR with a summary.
⚙️
CI/CD in Headless
-p means print mode — no interactive prompt. claude -p "fix lint errors", -p "update snapshots". Pair it with --allowedTools to bound what it may do.
🤖
GitHub Actions
on: pull_request auto-reviews, on: issues auto-triages and labels, on: push runs quality checks. Official action: anthropics/claude-code-action.
In Plain English

Simple: The difference between a colleague who reads your work and one who also files the paperwork, chases the reviewer and closes the ticket.

Technical: None of this is a new capability — it is the same Bash and MCP tools pointed at a version-control host. What makes it automatable is -p (print mode): no interactive prompt, so it runs where there is no terminal to answer one.

Pick a Scenario

Select a use case below and watch the agent work through it.

claude — bug fix
In Plain English

Simple: Watching six different repairs before you attempt one yourself. The tasks differ; the rhythm of the work does not.

Technical: These transcripts are hardcoded, not live. What is worth reading across all six is what each loop converges on: a bug fix ends when a test passes, a refactor ends when behaviour is unchanged, a review ends when there is nothing left to say.

Build Your Own Workflows

Combine everything you’ve learned to create custom agentic workflows.

🚀
Deploy Pipeline
Run tests → build → deploy → smoke test → notify Slack. One command.
👋
New Dev Onboarding
CLAUDE.md + /init + MCP setup. Get a new teammate productive in minutes.
🔄
Migration Assistant
Upgrade framework versions, fix breaking changes, run tests, commit per-file.
🔒
Security Audit
Scan deps → check OWASP top 10 → review auth flows → generate report.
In Plain English

Simple: A “leaving the house” routine instead of separately remembering keys, lights and the back door. The steps were never hard; the order and the not-forgetting were.

Technical: A workflow encodes sequencing and failure handling that a single prompt does not: deploy only if tests pass, notify only if deploy succeeded. That ordering constraint is the artefact, not the individual commands.

claude — The Full CLI

Claude Code is a powerful CLI with 50+ options. Here are the essential categories.

-p, --printNon-interactive mode — print response and exit. Perfect for piping and CI.
-c, --continueResume the most recent conversation in the current directory.
-r, --resumeResume a specific session by ID, or open an interactive picker.
--model <model>Choose model: opus, sonnet, haiku, or full ID.
-h, --helpDisplay full help with all options and commands.
-v, --versionShow Claude Code version number.
--system-promptOverride the default system prompt entirely.
--append-system-promptAdd instructions to the default system prompt.
--allowedToolsWhitelist specific tools: "Bash(git:*) Edit Read"
--disallowedToolsBlacklist specific tools to prevent their use.
--permission-modeSet mode: manual, plan, auto, bypassPermissions
--add-dirGrant tool access to additional directories beyond the working dir.
--output-formattext (default), json, or stream-json for real-time streaming.
--json-schemaForce structured output matching a JSON Schema.
--input-formattext or stream-json for programmatic input.
--verboseShow detailed output including tool calls and reasoning.
--max-budget-usdCap spending: --max-budget-usd 5.00
--effortControl effort: low, medium, high, xhigh, max
--mcp-configLoad MCP servers from a JSON config file.
-w, --worktreeCreate an isolated git worktree for the session.
--bareMinimal mode: skip hooks, LSP, plugins, auto-memory.
--agentsDefine custom agents inline as JSON.
-d, --debugEnable debug logging with optional category filter.
--dangerously-skip-permissionsYOLO mode — bypass all permission checks.
claude mcpAdd, remove, list, and manage MCP servers.
claude authLogin, logout, and check authentication status.
claude doctorHealth check — diagnose auto-updater and config issues.
claude updateCheck for updates and install the latest version.
claude agentsManage background agents started with --bg.
claude installInstall a specific version: stable, latest, or version number.
In Plain English

Simple: Every appliance has more buttons than anyone presses. These five tabs are the ones worth finding.

Technical: The flags sort into three jobs: what the model is told (--system-prompt, --append-system-prompt), what it is permitted to do (--allowedTools, --permission-mode), and what shape comes back (--output-format, --json-schema). Learn the three jobs, not the fifty flags.

CLI Recipes

Copy-paste these real-world patterns into your terminal.

Piping
Pipe output to Claude
CI/CD
Fix lint in CI
JSON
Structured output
Review
Auto-review PRs
Multi-dir
Cross-repo work
Cost
Budget-capped runs
Pipe output to Claude
# Pipe error logs to Claude for diagnosis cat error.log | claude -p "What caused this error?" # Pipe git diff for a commit message git diff --staged | claude -p "Write a commit message" # Pipe test output for analysis npm test 2>&1 | claude -p "Explain the failures"
In Plain English

Simple: A bucket brigade: each person does one thing and hands the bucket on. None of them needs to know where the fire is.

Technical: -p turns claude into an ordinary Unix filter — reads stdin, writes stdout, exits with a status code. That is why it composes with cat, git diff and a CI runner without any of them knowing an AI is in the pipe.

claude mcp — Server Management

Manage MCP servers directly from the command line.

# A remote server, reached over HTTP claude mcp add --transport http sentry https://mcp.sentry.dev/mcp # A local server, launched as a child process (stdio) claude mcp add -e API_KEY=xxx my-server -- npx my-mcp-server # Then: list, remove claude mcp list claude mcp remove my-server
One thing to notice: --transport. Every MCP server is either remote (an HTTP URL you point at) or local (a command after -- that Claude Code starts for you). Every other flag follows from that one choice — --header only applies to the first, -e only to the second.
In Plain English

Simple: Adding a channel to a TV. Either you tune to a broadcast someone else runs, or you plug a box in beside your own sofa.

Technical: --transport decides which, and the difference is lifetime, not just address: an HTTP server is already running and you authenticate to it with --header; a stdio server is a child process Claude Code starts and stops for you, configured with -e.

Permission Modes

Control how much autonomy Claude has with --permission-mode.

Mode
Behavior
Best For
manual
Ask for each tool call
Learning & sensitive work
plan
Read-only, no edits
Architecture review
acceptEdits
Auto-approve file edits
Trusted coding tasks
auto
Auto-approve most tools
Well-defined workflows
bypassPermissions
No prompts at all
Sandboxed CI only
Combine with --allowedTools for fine-grained control: claude --permission-mode auto --allowedTools "Bash(git:*) Read Glob Grep"
In Plain English

Simple: A dial that runs from “ask me before every turn” to “just drive.” Where you set it should depend on how far the car can travel before you notice.

Technical: The gate sits at the tool-call boundary, evaluated after the model has decided on a call and before it executes — so a mode narrows what happens, never what the model may propose. bypassPermissions removes the gate, which is only defensible when the blast radius is already bounded by a sandbox.

Claude Code — Evolving Fast

Claude Code ships updates weekly. Here’s what’s changed recently and what to watch for.

New
Agent Skills & On-Demand Disclosure
Skills are loaded lazily via ToolSearch — only discovered when needed. Reduces context overhead and enables infinite extensibility.
New
Custom Agents via --agents
Define specialized agents with custom prompts and tool restrictions. Run them with --agent reviewer.
New
Worktrees & Isolation
claude -w creates git worktrees for isolated experiments. Combine with --tmux for parallel sessions.
Stay current: this list goes stale by design. Run claude update regularly and read claude --help — that output, not this slide, is the authority on what flags exist today.
In Plain English

Simple: A printed timetable at a bus stop. Accurate the week it went up, and worth checking against the live board.

Technical: Read these three as one direction rather than three features: each buys back a scarce resource. ToolSearch defers tool descriptions to save context; --agents narrows the tool set to reduce ambiguity; -w isolates the filesystem to contain mistakes. Time-sensitive: verify against claude --help.

The Agent Only Picks Up the Tools It Needs

Give the agent a hundred tools and it does not read a hundred manuals first. It looks up the one it needs, when it needs it — like a mechanic walking to the toolbox instead of carrying it.on-demand disclosureToolSearch

💡
The Problem
Each tool description costs 50–200 tokens. Fifty MCP tools is 2,500–10,000 tokens spent before any work starts — out of a 200K window that never grows.
🔍
The Solution
ToolSearch is a tool for finding tools. Servers register theirs as deferred; the agent sees only names, then loads the full descriptions it asks for. A library catalogue, not the whole shelf.
⚙️
How It Works
Keyword: ToolSearch("slack message"). Exact: ToolSearch("select:mcp__slack__send"). Scoped: ToolSearch("+slack send"). A deferred tool must be loaded before it can be called.
🚀
Benefits
Add a hundred servers without context bloat. Fewer input tokens means faster and cheaper. And if one server is down, the rest still work.
Agent needs Slack
→
ToolSearch("slack")
→
Tools loaded
→
send_message()
In Plain English

Simple: A library does not post every book to you on the off chance. It sends you the catalogue, and you request the one you want.

Technical: Deferred registration: the server advertises tool names and withholds the full schemas until ToolSearch asks. The saving is in input tokens on every single turn, not once at startup — which is why it compounds over a long session.

Lab 0: Install Claude Code and Prove It Is Connected

Start here. This lab installs Claude Code with npm, which needs Node 18 or newer — though Claude Code also ships as a standalone binary (via Homebrew, for one) that needs no Node, so a machine without Node is not a blocker. You also need a terminal, an account, and — this is the part people skip — a git repository you know cold. Every later lab in this track assumes Lab 0 is done.
Beginner ~10 min Step 1 of 7
Get Claude Code installed, signed in, and answering a question about a repository you already know.
1
Check what you already have
node --version && git --version
Expected

Two version lines. Node must be 18 or newer for the npm install in the next step. If node is not found, either install Node, or install Claude Code with a standalone installer (such as Homebrew’s claude-code) and skip the npm step.

2
Install it, then prove the install
npm install -g @anthropic-ai/claude-code && claude --version
Expected

npm prints an added N packages line, then a version number. If npm fails with a permissions error, use a Node version manager rather than sudo — a global install run as root is the most common way to break a Node setup.

3
Launch it inside a repo you know
cd my-project && claude
Expected

A welcome banner, a one-time sign-in on first run, then a prompt waiting for input. You are now inside a session, not at your shell — the commands in Lab 1 only work here.

4
Confirm the connection, do not assume it
/status
Expected

A summary of the session: how you are signed in, which model is active, and which directory it is working in. This is the connection proof. If it shows you as not signed in, sign in before going further — an unauthenticated session fails on the first real request, and the error rarely says “you are not logged in”.

5
Ask something you can already grade
“What does this project do? Answer in three sentences.”
Expected

A short answer, preceded by lines showing which files it opened. Read it as an exam you already know the answers to. If it is wrong about a project you know well, that is the single most useful thing you will learn today — and far better learned now than on work that matters.

6
Leave, and come back to the same session
/exit then claude --continue
Expected

/exit returns you to your shell; claude --continue reopens the same conversation with its history intact. A session is a resumable thing on disk, not a window you lose by closing it.

7
Choose an older session, or branch one
claude --resume (and: claude --fork-session)
Expected

A list of earlier conversations to pick from. --continue reopens the most recent one; --resume lets you choose; --fork-session opens a copy, so you can try something risky without spoiling a thread you depend on. Reach for the fork when you want a second attempt at the same problem while keeping the first — without it you overwrite whichever answer turns out to be the good one.

Lab 1: The Slash Commands That Matter

Beginner ~10 min Step 2 of 7
Learn the handful of commands that cover most daily use — and the one screen that explains why a long session slows down.
1
See what this session actually offers
/help
Expected

A list of the commands available in this session, including any your project or its plugins added. The list is not fixed — it depends on where you launched from, which is why it is worth reading once per new project.

2
Give the project a memory
/init
Expected

It reads the repository and proposes a CLAUDE.md at the root for you to approve. Read it before accepting. It inferred your conventions from your code, and a plausible-but-wrong convention here is re-read by every future session.

3
Read the context meter
/context
Expected

A breakdown of what is occupying the context window. The lesson is what sits there before you type anything: the system prompt, the tool definitions, any connected servers, and your CLAUDE.md. That is the real reason a session with many tools connected feels slower and more expensive than a bare one.

4
Two different kinds of reset
/clear versus /compact
Expected

/clear discards the conversation and starts empty. /compact replaces it with a summary and carries on. Run /context after each to see the difference in the meter. These are not two strengths of one thing: one throws away a decision you may still need, the other keeps a lossy trace of it.

5
Undo more than the last edit
/rewind
Expected

A list of earlier points in the session you can return to. This is the escape hatch for “I approved that too quickly” — and knowing it exists is what makes it safe to work quickly in the first place.

Lab 2: Permission Modes and Hooks — Two Guards, Opposite Directions

Intermediate ~15 min Step 3 of 7
Decide what happens without being asked twice — first interactively with permission modes, then permanently with a hook.
1
See the modes that exist
claude --permission-mode plan
Expected

The session starts in plan mode. The real set is acceptEdits, auto, bypassPermissions, manual, dontAsk and plan — check with claude --help rather than trusting any list, including this one, since the set changes between versions.

2
Read a permission prompt properly
“Add a one-line comment at the top of README.md”
Expected

It asks before writing. Read every option before choosing: one of them approves this single action, and another approves every action of that kind from now on. Beginners pick the second by reflex and then wonder why they stopped being asked.

3
Use plan mode on purpose
“Plan how you would add input validation here. Do not edit anything.”
Expected

A written plan and no edits. Plan mode is read-only by construction, so it is the one mode where an expensive, wide-ranging question costs you nothing but time. A plan you did not read, though, is just latency.

4
Add a guard that outlives the session
Use /hooks to add a PreToolUse hook that matches Bash and refuses any command containing rm -rf. Let the tool write the file; do not hand-edit JSON for your first hook.
Expected

A hook is written into your project settings: an event, a matcher that scopes it to a tool, and a command to run. The real events are PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, Stop, SubagentStop, PreCompact and Notification. Because it is a file in the repo, a teammate gets the guard from a git pull.

5
Attack your own guard
“Run this: rm -rf /tmp/does-not-exist”
Expected

The hook fires and the command is refused. An untested guard is not a guard. This failure is silent in one direction only: a matcher that does not scope to the tool you assumed never runs, and never tells you it did not.

Lab 3: Choosing a Model, and How Hard It Thinks

Beginner ~10 min Step 4 of 7
Pick the model and the effort level deliberately, and see for yourself that stronger is not automatically better.
1
See what is actually available to you
claude --list-models
Expected

The models your account can use. Treat this as the source of truth, not a table in a course — model names change, and a deck that hardcodes one is out of date within a quarter. /model switches between them inside a session.

2
Same question, two models
Ask one identical mid-sized question on a fast model, then switch with /model to the strongest one available and ask it again.
Expected

Two answers. Compare latency and depth, not correctness — on a question that was never hard, the strong model is mostly just slower. Reaching for the strongest model by default is the most common and most expensive beginner habit.

3
Turn the effort dial
claude --effort low (also: medium, high, xhigh, max)
Expected

Effort controls how much the model reasons before acting, independently of which model you chose. Low suits mechanical edits; high earns its keep on “find the root cause”. Use /effort to change it inside a session.

4
Check how much room you have
/context
Expected

Different models give you different amounts of context. A larger window changes what you can fit, not how well it reasons — and you pay for the context you actually occupy, so a big window filled with noise is worse than a small one filled with the right two files.

Lab 4: Interrupting and Steering

Intermediate ~10 min Step 5 of 7
Stop a run that is heading the wrong way, redirect it in one sentence, and know exactly what you cannot take back.
1
Start something long, then stop it
Ask for a broad task that touches several files, and press Esc while it is working.
Expected

It halts and returns you to the prompt. Work already written to disk stays; the step in flight does not finish. Interrupting is normal operation, not an error — and the sooner you are comfortable doing it, the less you pay for runs you already knew were wrong.

2
Redirect instead of restarting
“Stop looking in tests/. The bug is in the request parser — read that first.”
Expected

It resumes from where it was, with your correction in context. A correction is strictly cheaper than a restart, because starting again throws away the reading you already paid for.

3
Take back a change you accepted
/rewind
Expected

Pick an earlier point and the session returns to it. This is the counterweight to the persistent-approval option in Lab 2: the faster you let it work, the more you need a way back.

4
Learn the edge of reversibility
Nothing to run. /rewind covers what the session itself did. It does not cover a git push, a file deleted outside the project, an email sent, or anything a command sent over the network.
Expected

The boundary is the lesson: reversibility is a property of the tool’s own edits, not of the world. That boundary is also what decides which permission grants are safe to make permanent.

Lab 5: Getting Documents In

Beginner ~10 min Step 6 of 7
Put a file, a picture and a stream of text in front of Claude by the three routes that exist.
1
Cite a file instead of describing it
“Summarise @README.md in five bullets.”
Expected

Typing @ opens a path completer, and the file is loaded directly. Compare this with asking it to “find the readme”: that pays for a search, and leaves the search output sitting in your context for the rest of the session.

2
Two files, one question
“Compare @package.json and @README.md — does the README describe scripts that exist?”
Expected

Both files load and one answer covers them. This is the shape of most real document work: a question that only makes sense across two sources, where the answer is the discrepancy.

3
Paste a picture
Copy a screenshot to the clipboard — an error dialog, a chart, a layout that is wrong — then paste it into the prompt and ask what it shows.
Expected

The prompt shows an attachment and the answer describes what is in the image. Worth reaching for whenever screenshotting is faster than describing, which for a visual bug is almost always.

4
Pipe something in
git log --oneline -30 | claude -p "Group these commits by theme."
Expected

Standard input becomes the content, and -p prints one answer and exits. Any command that produces text is now a document source — logs, a CSV, the output of a build. This is also the door that composes with the rest of your shell, and therefore the door automation uses.

5
Make the answer machine-readable
claude -p "List the three largest files as JSON" --output-format json ; echo $?
Expected

A JSON object instead of prose, then a 0. --output-format takes text (the default), json for a single result, or stream-json for output as it arrives. Reach for this the moment another program has to read the answer — a CI step, a script, a dashboard. Prose is for you; JSON is for the next command. And check the exit code: a script that ignores it will treat a failed run as an empty result.

Lab 6: Make Something, Then Fix It When It Breaks

Beginner ~15 min Step 7 of 7
Create real files including a Markdown document, review the diff before you keep it, and work through the four things that go wrong first.
1
Write a Markdown document
“Create NOTES.md summarising this project, one section per top-level directory.”
Expected

The proposed file is shown for approval, then written. Open it and read it. You are the reviewer — and this is the first artefact in this track that you own and will keep.

2
Create a small file that runs
“Add scripts/hello.sh that prints the current git branch, and make it executable.”
Expected

Two operations — writing the file and changing its mode — each asking separately if you are in a mode that asks. Then run it: it should print your branch name. A file it claims to have made executable, but did not, only shows up when you run it.

3
Review before you keep it
git status && git diff --stat
Expected

Exactly the files you asked for, and nothing else. If there is a third file you did not ask for, that is the finding — and /rewind from Lab 4 is how you take it back.

4
Troubleshooting: the first four failures
Nothing to run. command not found → the global npm bin is not on your PATH (Lab 0). Nothing happens after a prompt → check the mode; you may be in plan mode (Lab 2). It ignores your conventions → there is no CLAUDE.md; run /init (Lab 1). Slow and forgetful → run /context, then /compact (Lab 1).
Expected

Every one of these is an environment or mode fault, not a model fault — and each maps back to one earlier lab in this track, which is the real test of whether the track worked.

Quick Start Guide

Step 1
Install Claude Code
npm install -g @anthropic-ai/claude-code
Step 2
Navigate to Your Project
cd my-project && claude
Step 3
Create CLAUDE.md
Add project context, tech stack, and rules. The agent reads this every session.
Step 4
Give It a Real Task
“Fix the failing test in auth.test.js” — and watch the agentic loop in action.
In Plain English

Simple: Assembling flat-pack furniture: three unglamorous steps, then the part you actually wanted.

Technical: Steps 1, 2 and 4 are per-session. Step 3 is the only one that persists — skip it and you re-explain the project on every future run, which is both slower and the main source of conventions being guessed at.

Knowledge Check

Eight questions on this module. Answer to see why — the explanation appears whether you were right or wrong.

Question 1 of 0
Score 0/0

Key Takeaways

🤖
Agents Act
Unlike chatbots, agents can read files, run code, search the web, and verify their own work.
🔄
The Loop Is Everything
Gather → Act → Verify → Repeat. This pattern drives all agentic workflows.
🔌
MCP Extends Reach
MCP servers connect agents to any service — browsers, databases, Slack, GitHub.
📋
CLAUDE.md = Memory
Persistent project instructions ensure the agent knows your codebase every session.
Agentic LoopTool UseMCPBashFile I/OSkillsCLAUDE.mdPermissions