Claude Code 101 - Certification Study Guide

Course: Claude Code 101 Modules: 4 + Assessment Target: Developers new to AI-assisted coding workflows Difficulty: Beginner → Intermediate

MODULE 1: Fundamentals

Key Notes

What is Claude Code?

Claude Code is an agentic AI coding tool that runs in the terminal (and IDE plugins). It is not a chat assistant or autocomplete engine — it is a full agent that can read/write files, execute shell commands, and interact with your entire codebase autonomously.

Key distinction from chat-based AI:

• Chat AI: You paste code → AI suggests text → You copy-paste manually
• Claude Code: AI reads your actual files → reasons → edits them directly → runs tests → validates its own work

The Agentic Loop

Claude Code operates on a repeating reasoning loop:

┌─────────────────────────────────────────────────────────┐
│                   THE AGENTIC LOOP                       │
│                                                         │
│   User Prompt                                           │
│       │                                                 │
│       ▼                                                 │
│   LLM Reasoning  ──► "I need to read auth.ts first"    │
│       │                                                 │
│       ▼                                                 │
│   Tool Call      ──► Read("src/auth.ts")               │
│       │                                                 │
│       ▼                                                 │
│   Tool Result    ──► file contents returned             │
│       │                                                 │
│       ▼                                                 │
│   LLM Synthesis  ──► "Found the bug, will edit line 47"│
│       │                                                 │
│       ▼                                                 │
│   Tool Call      ──► Edit("src/auth.ts", ...)          │
│       │                                                 │
│       ▼                                                 │
│   Tool Result    ──► edit applied                       │
│       │                                                 │
│       ▼                                                 │
│   LLM Synthesis  ──► "Should verify — run tests"       │
│       │                                                 │
│       ▼                                                 │
│   Tool Call      ──► Bash("npm test")                  │
│       │                                                 │
│       ▼                                                 │
│   Tool Result    ──► tests pass                         │
│       │                                                 │
│       ▼                                                 │
│   Final Response ──► "Fixed the null check in auth.ts" │
└─────────────────────────────────────────────────────────┘

This loop can iterate many times within a single prompt. Claude decides when it has enough information to respond.

Where Claude Code Runs

Tools Available

Claude Code has access to these built-in tools:

MCP servers can extend this list with custom tools (databases, APIs, browsers, etc.).

Context Window

Claude Code holds a context window — a fixed-size buffer containing:

• Conversation history (user messages + Claude responses)
• File contents that were Read
• Tool call results (bash output, search results)
• CLAUDE.md instructions loaded at session start

When the context fills up, use /compact to summarize and free space, or /clear to start fresh.

Permissions and Approval Modes

Claude Code uses a tiered permission system:

Plan mode: Claude drafts a plan of action before taking any steps. Useful for complex tasks — review the plan, approve, then execution begins.

Best Practices

• Treat Claude Code as a pair programmer with terminal access, not an autocomplete tool
• Understand the agentic loop — Claude may take 5-15 tool calls before responding
• Use suggest mode when learning; auto-edit for trusted day-to-day work
• Never use yolo in production or against databases without safeguards
• Use Plan mode for multi-file refactors or unfamiliar tasks
• Watch for infinite loops: if Claude edits → tests → edits the same thing repeatedly, interrupt it

Example

User: "Why is my login endpoint returning 401?"

Claude's agentic loop:
  1. Bash: git log --oneline -10         (check recent changes)
  2. Read: src/routes/auth.ts            (read the route handler)
  3. Grep: "validateToken" src/          (find token validation logic)
  4. Read: src/middleware/jwt.ts         (read the middleware)
  5. Bash: npm test -- auth              (run auth-specific tests)
  → Synthesizes: "The JWT secret env var changed in .env.example
     but not in your .env — the middleware is using the old key."

MODULE 2: Getting Started

Key Notes

Installation

Three ways to install Claude Code:

# Option 1: npm (Node.js required)
npm install -g @anthropic-ai/claude-code

# Option 2: Homebrew (macOS)
brew install claude-code

# Option 3: Download binary from claude.ai/code

Minimum requirement: Node.js 18+ for the CLI.

Authentication

Two authentication paths:

The API key method gives programmatic control. Subscription auth handles billing through Anthropic’s plans.

IDE Integrations

VS Code:

• Install “Claude Code” from the Extensions marketplace
• Opens in the sidebar panel
• Supports inline diff preview for edits

JetBrains:

• Install “Claude Code” from the JetBrains Plugin marketplace
• Works in IntelliJ IDEA, PyCharm, WebStorm, GoLand, etc.
• Same tool capabilities as CLI

Project Detection

On first run in a directory, Claude Code auto-detects:

• Language and framework (TypeScript/React, Python/FastAPI, Rust/Cargo, etc.)
• Package manager (npm, yarn, pnpm, uv, pip, cargo)
• Build/test commands from package.json, Makefile, pyproject.toml, etc.
• Git repository info and recent history

This context primes Claude without needing explicit instructions every session.

Essential Slash Commands

Your First Prompts

Good starter prompts when onboarding to a new codebase:

"Explain what this codebase does and how it's structured"
"List all the API endpoints in this project"
"What does the authentication flow look like?"
"Find all TODOs and FIXMEs in the codebase"
"Fix the TypeScript error in app.ts"

Avoid vague prompts like “make it better” — Claude needs a specific goal.

Best Practices

• Run /init in every new project before starting work — it generates CLAUDE.md with detected conventions
• Use /compact proactively in long sessions, not just when you hit the limit
• Prefer API key auth in team/CI environments so usage is trackable per key
• For first use in a new repo, start with an exploration prompt before asking for changes
• Use /cost to monitor spend and learn which task types are expensive

Example

# First session in a new project

$ cd my-api
$ claude

> /init
  → Claude scans the project, generates CLAUDE.md with:
    - Project: Node.js + Express + TypeScript
    - Test: npm test (Jest)
    - Build: npm run build (tsc)
    - Conventions: ESLint + Prettier

> "Explain the request lifecycle from HTTP to database"
  → Claude reads route files, middleware, controllers, models
  → Returns a clear explanation with file references

> "Add input validation to the POST /users endpoint"
  → Claude reads the existing handler, adds Zod validation,
     updates tests, confirms they pass

MODULE 3: Daily Workflows

Key Notes

The Explore → Plan → Code → Commit Workflow

This four-step workflow is the recommended pattern for all non-trivial tasks:

┌──────────────────────────────────────────────────────────┐
│          DAILY DEVELOPMENT WORKFLOW                       │
│                                                          │
│  1. EXPLORE                                              │
│     "What does this codebase do?"                        │
│     "How does the auth system work?"                     │
│     "Find all usages of UserService"                     │
│     → Claude reads, greps, maps dependencies             │
│                                                          │
│  2. PLAN                                                 │
│     "Create a plan to add email notifications"           │
│     → Use /plan mode for approval before action          │
│     → Claude outputs phased plan with file targets       │
│                                                          │
│  3. CODE                                                 │
│     "Implement the notification system"                  │
│     → Claude reads affected files, edits, creates,       │
│       runs tests, fixes failures, iterates               │
│                                                          │
│  4. COMMIT                                               │
│     "Create a commit for these changes"                  │
│     "Create a PR with a summary"                         │
│     → Claude runs git diff, writes commit message,       │
│       optionally opens PR via gh CLI                     │
└──────────────────────────────────────────────────────────┘

Step 1 — EXPLORE: Ask broad questions before making any changes. Let Claude map the codebase. This prevents incorrect assumptions and wasted edits.

Step 2 — PLAN: For tasks touching 3+ files or any architectural change, use /plan mode. Claude presents a plan you can modify before it executes. This is the safety valve for complex work.

Step 3 — CODE: Claude takes over — reads files, makes edits, runs build/test commands, and iterates. Your role is to monitor, not intervene unless something is wrong.

Step 4 — COMMIT: Claude can draft commit messages, run pre-commit checks, and create PRs via gh CLI. Always review the diff before committing.

Context Management

CLAUDE.md as persistent context:

• Loaded automatically every session
• Contains project conventions, build commands, gotchas
• No need to re-explain the project each time
• Keep it lean (under 60 lines) — link to docs for detail

Avoiding context bloat:

• Don’t ask Claude to read large files unless necessary
• Use Grep instead of Read when you only need to find patterns
• Use /compact before switching to a very different task in the same session

Code Review Practices

Claude Code can perform code review as part of its workflow:

# Review a PR
"Review the changes in this PR for correctness and security issues"
→ Claude uses gh CLI to fetch diff, analyzes changed files

# Security audit
"Check src/api/ for common security vulnerabilities (SQL injection, XSS, auth bypass)"
→ Claude reads files, applies security reasoning, flags issues

# Type checking
"Run the TypeScript compiler and fix any type errors"
→ Claude: Bash("npx tsc --noEmit") → reads errors → edits files → retypes

# Test coverage
"Which modules have no test coverage? Add tests for the most critical ones."
→ Claude: maps test files vs source files → identifies gaps → writes tests

Review prompts to use regularly:

• “Explain what these changes do in plain English”
• “Does this code handle all error cases?”
• “Is there anything here that could cause a production incident?”
• “Simplify this without changing behavior”

Best Practices

• Always EXPLORE before CODE — never skip to implementation on an unfamiliar codebase
• Use /plan for anything that touches more than 2-3 files
• Let Claude run your test suite as part of CODE — don’t just review diffs
• Keep CLAUDE.md updated when project conventions change
• Use /compact before switching between unrelated features in a long session
• During COMMIT step, always read the final diff yourself — Claude can miss unintended changes
• For code review, give Claude a specific concern (“check for auth bypass”) not just “review this”

Example

# Full workflow: adding a feature

> "How does user data currently get stored? Explore the data layer."
  Claude: Reads models/, service files, migration files, returns summary

> /plan
  "Add soft-delete support to the User model"
  Claude: Drafts plan:
    Phase 1: Add deleted_at column (migration)
    Phase 2: Update User model with soft-delete methods
    Phase 3: Update UserService to filter soft-deleted records
    Phase 4: Update tests
  You: Approve the plan

> "Implement it"
  Claude: Creates migration file
         Edits User model
         Edits UserService queries
         Updates test fixtures
         Runs npm test → 2 failures
         Fixes the test fixtures
         Runs npm test → all pass

> "Create a commit with a conventional commit message"
  Claude: git diff (shows changes), writes:
  "feat(users): add soft-delete support with deleted_at column"

MODULE 4: Advanced Customization

Key Notes

CLAUDE.md — Project Memory

CLAUDE.md is the primary customization file. It is auto-loaded at session start and provides Claude with project-specific context without requiring you to re-explain conventions each time.

# Created via:
/init

# Typical contents:
# Project: E-commerce API (Node + Express + TypeScript)
# Build: npm run build
# Test: npm test
# Lint: npm run lint
# DB: PostgreSQL via Prisma
# Conventions: kebab-case filenames, services in src/services/
# Gotchas: Never commit .env — use .env.example as template

Hierarchical loading:

project-root/
├── CLAUDE.md              ← loaded for all work in project
├── src/
│   └── CLAUDE.md          ← loaded when Claude works in src/
└── backend/
    └── CLAUDE.md          ← loaded when Claude works in backend/

Parent files always load; subdirectory files load lazily when Claude touches that directory. This allows monorepos to have per-module conventions.

Rules:

• Keep root CLAUDE.md under 60 lines
• Link to docs/ for detailed standards — don’t inline everything
• Never duplicate content across levels (parent loads automatically)
• CLAUDE.md is for universal instructions, not task-specific steps

Subagents

Claude Code can spawn child Claude instances (subagents) to handle parallel or isolated work:

┌─────────────────────────────────────────────────────────┐
│                   SUBAGENT ARCHITECTURE                  │
│                                                         │
│   Main Claude (orchestrator)                            │
│       │                                                 │
│       ├──► Subagent A (Explore)   read-only scouting   │
│       │        isolated context                         │
│       │                                                 │
│       ├──► Subagent B (Plan)      architecture design   │
│       │        isolated context                         │
│       │                                                 │
│       └──► Subagent C (Implement) file edits + tests   │
│                isolated context                         │
│                                                         │
│   Main Claude receives results, synthesizes             │
└─────────────────────────────────────────────────────────┘

Why use subagents?

• Parallel work: Research + implementation happening simultaneously
• Context isolation: Subagent context does not pollute the main conversation
• Specialization: Different subagents with different permissions/focus
• Cost efficiency: Subagents can be given narrow scope, keeping their context small

Subagent types:

Subagents are invoked via the Agent tool and can run in foreground (result returned before continuing) or background (fire-and-forget).

Skills

Skills are reusable workflow templates stored in .claude/skills/. They encapsulate multi-step workflows that you use repeatedly.

.claude/
└── skills/
    ├── code-review/
    │   ├── SKILL.md          ← skill definition + frontmatter
    │   └── prompts/
    ├── debug/
    │   └── SKILL.md
    └── deploy/
        └── SKILL.md

SKILL.md frontmatter:

---
name: code-review
version: 1.0
description: Automated code review with security focus
allowed-tools: Read, Grep, Bash
agent: general
---

Invoking a skill:

/code-review              ← runs the skill's defined workflow
/debug --verbose          ← skills can accept arguments

Context isolation: A skill runs in its own scoped context. Its intermediate tool calls, files read, and reasoning do not appear in the main conversation transcript. Only the final result surfaces.

When to create a skill:

• You find yourself repeating the same multi-step workflow
• You want a standard process enforced across a team
• You want to limit which tools a certain workflow can use

MCP Servers (Model Context Protocol)

MCP servers are external tool integrations that extend Claude’s built-in tools with domain-specific capabilities.

┌──────────────────────────────────────────────────────────┐
│                    MCP ARCHITECTURE                       │
│                                                          │
│   Claude Code                                            │
│       │                                                  │
│       │ tool calls                                       │
│       ▼                                                  │
│   ┌─────────────────────────────────────────────────┐   │
│   │              MCP Client (built-in)               │   │
│   └─────────┬──────────────┬──────────────┬─────────┘   │
│             │              │              │              │
│             ▼              ▼              ▼              │
│        postgres        browser        github            │
│        MCP server      MCP server    MCP server         │
│        (stdio)         (stdio)       (HTTP)             │
│             │              │              │              │
│             ▼              ▼              ▼              │
│          database       Playwright     GitHub API        │
└──────────────────────────────────────────────────────────┘

Transport types:

• stdio — Local process, Claude spawns and communicates via stdin/stdout. Used for databases, file systems, local tools.
• HTTP — Remote server Claude connects to via HTTP. Used for SaaS APIs, shared team servers.

What each MCP server exposes:

Configuration in settings.json:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "${DATABASE_URL}" }
    },
    "github": {
      "url": "https://mcp.github.com",
      "headers": { "Authorization": "Bearer ${GITHUB_TOKEN}" }
    }
  }
}

Common MCP servers:

• @modelcontextprotocol/server-postgres — Query PostgreSQL
• @modelcontextprotocol/server-filesystem — Extended file access
• @modelcontextprotocol/server-github — GitHub API
• @modelcontextprotocol/server-puppeteer — Browser automation
• Atlassian, Linear, Notion, Slack — Team tool integrations

Hooks

Hooks are automated behaviors triggered by Claude Code events. They allow you to enforce policies, inject context, or block dangerous operations — without Claude’s cooperation being required.

Hook events:

How hooks work:

Claude wants to run: Bash("rm -rf /production-db")
                          │
                          ▼
              PreToolUse hook fires
              hook script receives: { tool: "Bash", input: "rm -rf..." }
                          │
                          ├── exit 0  → allow the operation
                          ├── exit 2  → BLOCK the operation
                          └── stdout  → inject context into Claude's view

Exit code 2 is the block signal — Claude sees the block and cannot proceed. This is how hooks enforce hard safety constraints.

Hook configuration in settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "node .claude/hooks/bash-guard.cjs"
          }
        ]
      }
    ],
    "SessionStart": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "node .claude/hooks/session-init.cjs"
          }
        ]
      }
    ]
  }
}

Real-world hook examples:

Best Practices

• CLAUDE.md: Use /init on every project, keep it under 60 lines, update it when conventions change
• CLAUDE.md: Link to docs/ for standards — don’t make CLAUDE.md a manual
• Subagents: Use for parallel research tasks; always isolate contexts
• Subagents: Pass explicit file/path scopes when delegating to prevent scope creep
• Skills: Create skills for workflows you repeat more than 3 times
• Skills: Keep skill’s allowed-tools as narrow as possible
• MCP: Use stdio for local dev tools, HTTP for shared team servers
• MCP: Never hardcode credentials — always use environment variable references
• Hooks: Implement PreToolUse hooks for any operation that is irreversible (deploys, deletes)
• Hooks: Use SessionStart to inject environment-specific context automatically
• Hooks: Test hooks with exit 2 first to confirm blocking works before adding real logic

Example

# CLAUDE.md example (lean, under 60 lines)
# Project: Payments API — Stripe + Node + TypeScript
# Build: npm run build
# Test: npm test
# Lint: npm run lint --fix
# Deploy: never — handled by CI/CD only
# Conventions: services in src/services/, handlers in src/handlers/
# Gotchas: STRIPE_SECRET_KEY must be set or all tests fail
# See docs/ for full architecture and coding standards

---

# Skill: /security-review
# Runs: Read all files in src/handlers/ → Grep for unsafe patterns
#        → Bash("npm audit") → Synthesize report
# Allowed tools: Read, Grep, Bash (read-only bash only)

---

# Hook: PreToolUse on Bash
# Blocks any command containing "stripe" + "prod" to prevent
# accidental production Stripe API calls during development

---

# MCP: postgres server connected to local dev DB
# Claude can run: query_database("SELECT * FROM payments LIMIT 5")
# without raw psql access or manual connection setup

Assessment: Course Quiz

The final assessment tests comprehension of all four modules. Key topics to review:

Checklist — What You Must Know

Module 1: Fundamentals

• What is the agentic loop and how many times can it iterate?
• What is the difference between Claude Code and a chat-based AI?
• Name 5 built-in tools Claude Code has access to
• What are the three approval modes and when to use each?
• What does Plan mode do and when should you use it?

Module 2: Getting Started

• How do you install Claude Code via npm?
• What are the two authentication methods?
• What does /init generate?
• What does /compact do and when should you use it?
• Name 3 slash commands and their purpose

Module 3: Daily Workflows

• Name the four steps of the recommended daily workflow
• What is the purpose of EXPLORE before CODE?
• When should you use /plan mode?
• How does /compact differ from /clear?
• Give two examples of code review prompts that give Claude a specific concern

Module 4: Advanced Customization

• Where does CLAUDE.md live and when is it loaded?
• What is the recommended line limit for CLAUDE.md?
• How does hierarchical CLAUDE.md loading work in monorepos?
• What is a subagent and what problem does context isolation solve?
• What are the three primitives an MCP server exposes?
• What is the difference between stdio and HTTP MCP transport?
• What hook event fires before every tool call?
• What exit code blocks a tool call from a hook?
• What does a Skill’s allowed-tools frontmatter control?

Quick Reference Card

APPROVAL MODES          SLASH COMMANDS          HOOK EVENTS
suggest   → ask all     /init    → CLAUDE.md    SessionStart
auto-edit → file auto   /compact → summarize    PreToolUse
yolo      → approve all /clear   → fresh start  PostToolUse
                        /plan    → plan first   UserPromptSubmit
                        /model   → switch model Stop
                        /cost    → show usage

MCP TRANSPORTS          HOOK EXIT CODES         WORKFLOW STEPS
stdio → local process   0 → allow               1. Explore
HTTP  → remote server   2 → block               2. Plan
                                                3. Code
SUBAGENT TYPES                                  4. Commit
Explore → read-only
Plan    → design only
General → full access

Claude Code 101 | Anthropic Certification | Study Guide