Claude Code, broken into 23 mini lessons you can actually use

Why it matters: Claude Code isn’t on the free plan. This is the only money you need to spend.

Why it matters: the terminal is where Claude Code unlocks its full power — parallel sessions, status lines, fast mode.

Why it matters: every number on this screen affects your cost and your output quality.

Claude Code auto-compresses your conversation history as it grows — it rewrites older messages into higher information density so you stay within the window.

Why it matters: an IDE gives you a friendlier face on top of the terminal — file explorer + text editor + AI chat in one window.

An IDE (Integrated Development Environment) = three things glued together: a file/folder explorer, a text editor (like Notepad), and an AI chat panel (like the claude.ai website). That’s it.

Option A — VS Code (the OG)

Option B — Antigravity (VS Code 2.0)

Interface goodies in the GUI: past conversations tab, a pause/stop button to interrupt Claude mid-task, a thinking tab to peek into its reasoning, a file-context “eye” (whatever file is open is what Claude sees), and an attach button for files/folders/browser.

Why it matters: this one file is invisibly injected at the top of every conversation. It steers everything.

Every chat follows a pattern: you → model → you → model. What you don’t see: before your first message, Claude Code injects a hidden prompt — the contents of any CLAUDE.md file in your workspace. It’s the very first thing the model reads and internalizes.

The ship analogy: imagine sailing from North America to Africa with a steering wheel that barely turns. Over 10,000 km, a 1° error at the port means missing the destination by hundreds of km. You can’t correct much mid-journey — so your launch angle has to be near-perfect. CLAUDE.md is your launch angle. It compresses the huge space of “ways the AI could go” into a narrow band pointed at your goal.

• You could paste the same instructions manually every session — CLAUDE.md just saves you doing that.
• Write it concise. Define what the workspace is for and its boundaries.
• Nick’s website-building CLAUDE.md wasn’t hand-written — he had Claude compile best practices from Twitter posts into it.

Why it matters: pick your method before you prompt. Nick has a clear favorite.

The core philosophy: Task → Do → Verify

Most people loop task → do → task → do and wonder why results suck. The missing piece is verification — screenshots for design, automated tests for software. AI’s value isn’t one-shotting to 100%; it’s iterating 80% → 90% → 95% → 100% in five minutes, where a human’s more precise first draft would take five hours.

Why it matters: this is the actual workflow — feed inspiration, let the loop run, give feedback like an art director.

Running multiple builds at once

• Open a second (third, fourth…) IDE window with its own Claude instance — each builds a different site simultaneously.
• The #1 rule: never let Claude sit idle waiting for you. If any instance waits on you more than 10–20% of the time, you have too many tabs. Nick caps at 3–4.
• He sets a different chime hook per window (Lesson on hooks) so he knows which one finished.
• Power move: have CLAUDE.md generate 3 design variants from 3 different inspiration sites, then pick the winner.

Why it matters: this hidden folder is the control panel for permissions, agents, skills, rules and MCP.

Folders starting with a period (.claude) are hidden by convention — your file explorer won’t show them, so they don’t clutter your workspace.

What lives inside a fully-loaded .claude/

The 3 layers that merge together

Why it matters: one monolithic 10,000-word CLAUDE.md is unmanageable. Rules give you granular control.

The rules/ folder lets you break one big CLAUDE.md into focused files: workflow.md, tech-defaults.md, design-rules.md, security.md, code-style.md…

Split CLAUDE.md into its component rules. Use the Claude Code rule
specification if you don't know what that means.

• Evolve the workflow rules without touching design rules (and vice versa).
• Working with others? Give people access to just the styles rules while you own the top-down workflow.
• A short modular file is auditable; a 10K-word monolith hides dead weight.

Why it matters: /init is the 90%-of-the-battle command, and these rules keep your brain file sharp instead of bloated.

In any folder without a CLAUDE.md, type /init. Claude reads the whole codebase, finds patterns, and writes a CLAUDE.md summarizing what everything does — so future sessions don’t have to re-read every file. Result: fewer tokens per prompt (cheaper) AND higher quality (shorter prompts = better outputs — there’s a negative relationship between prompt length and quality).

DO

• Run /init first in every new folder.
• Bullet points, short headings, maximum information density.
• Most important things at the top — hard guardrails (“NEVER delete X”) go first. Models remember the beginning (primacy bias) and end (recency bias) of a prompt best; the middle is a dead zone.
• Periodically review and prune — treat it like technical debt. If Claude keeps auto-adding to it, it accumulates junk.
• When Claude makes the same mistake 2–3 times, tell it: “Add this to your CLAUDE.md so it works next time on a fresh instance.” (One of Nick’s favorite commands.)
• Keep it 200–500 lines max.

DON’T

• Don’t dump entire style guides or full API docs in (10K tokens loaded every single session). Instead: give Claude the whole API once and have it prune down to just the endpoints you need.
• Don’t write vague aspirational rules — “be smart”, “make no mistakes” do nothing. Treat Claude like a savant: brilliant in a specific slice, hangs itself with too much rope.
• Don’t voice-dump raw transcripts into it — voice-dump to Claude, then have it compress into high-density rules.
• @include exists (e.g. @git.md pulls another file in) but don’t overuse it — rules cover most of this.

Compile the last month of high-ROI CLAUDE.md writings on X.
What are the best things to include?

Why it matters: a small global file lets Claude remember things across sessions — separate from CLAUDE.md.

• Say “Remember that my brother’s name is George” → Claude writes it to a global memory.md.
• That file is injected at the top of every new session (alongside enterprise/global/local CLAUDE.mds and tool definitions).
• Open a fresh instance, ask “what’s my brother’s name?” → it answers instantly.

Nick’s take: in practice memory isn’t hugely valuable (CLAUDE.md does the heavy lifting) — treat it as Claude’s own scratchpad notes, not your instruction set. It’s tiny (~88 tokens in his case).

Why it matters: the wrong mode either interrupts you every 5 seconds or gives Claude the keys to your hard drive. Know the tradeoffs.

Unlock bypass permissions (it’s off by default)

Fine-grained control: /permissions

Type /permissions (continues in a terminal) to set allow / ask / deny per tool — e.g. always allow web fetch but always ask before bash. There’s also a delegate mode used by agent-team leads (they can only manage the team, not touch files).

Why it matters: this is the highest-leverage habit in the course. Nick uses it for every non-trivial build.

Plan mode = read-only exploration. Claude researches the web, reads your files, reasons from first principles, and produces a plan document — before a single line of code exists.

The math (two scenarios)

It’s the Lego principle: change the blueprint, not the built pyramid. Or construction: you plan so you don’t discover mid-pour that materials are missing. Work in cheap plan-space, not expensive build-space.

Why it matters: the complete anatomy of a real build — proposal generator with login, AI generation, e-signature and Stripe payments. Zero code written by hand.

The security sermon (don’t skip)

• Bots constantly scan all DNS ranges and URLs — ~30–40 strangers hit Nick’s app minutes after deploy. Use a non-obvious custom URL, never a short guessable one.
• Don’t charge money or collect user data (emails, passwords, payments) on a fully vibe-coded app without paying a developer a few hundred dollars to review the auth at least once. Software isn’t the moat anyway — the liability is yours.
• Nick only runs these apps internally for his team and clients — he doesn’t sell vibe-coded apps to the open internet. “With great power comes great responsibility.”

Why it matters: you’re billed for ~25–45K tokens before you type a single word. Knowing where they go is how you cut costs and boost quality.

Run /context — what’s eating your window

Context windows run ~200K tokens (Opus) up to 1M+ (some Sonnet models). Window size ≠ model quality. Thinking/reasoning tokens are billed but not kept in context — extended thinking is a scratchpad that collapses after use.

The commands

• /context — see the full breakdown above. Do this once, it’s eye-opening.
• /compact — squash history into a dense summary (add custom instructions: “/compact prioritize X”). Auto-compaction also runs continuously in the background.
• /clear — wipe context entirely when switching to an unrelated task.
• /cost — check current usage. /statusline — add a permanent token bar (terminal only): “Update my status line to include a loading bar of tokens used out of total context.”
• /model — switch models + adjust thinking effort (off → 8K → 32K+ reasoning tokens).

The 10 token-diet tips (Anthropic’s + Nick’s)

• Write specific prompts — “fix this feature in this file” not “improve this codebase.” Highest ROI tip.
• Plan complex tasks first — research during planning is far cheaper than exploratory building.
• Compress your CLAUDE.md continuously; move task-like instructions into skills (they load on demand).
• Use cheap models (Sonnet/Haiku) in subagents for heavy reading; reserve the expensive parent for synthesis.
• Reduce MCP overhead — Claude now auto-searches tools instead of loading them all when MCP descriptions exceed 10% of the window, but you should still uninstall bloated servers.
• Tell Claude in CLAUDE.md: “Reason all you want, but answer with bare-bones info; I’ll ask if I need more.”
• Pipe voice dumps through a cheap model first to tighten them, then send the tight version to your expensive agent.
• Agent teams cost ~7× normal sessions — avoid them if token economy matters.
• For up-to-date tactics: ask Grok to “summarize the best token-reduction strategies users discussed in the last month.”

Why it matters: Nick calls skills “the most economically valuable way to use Claude Code.” He stopped hiring for entire task categories because of them.

Anatomy of a skill

The magic: when a script fails, Claude uses its intelligence to fix it live — and then updates the skill so no future instance hits the same problem. It’s a junior employee that permanently learns from every mistake.

Real skills from the course

• scrape-leads: test-scrape 25 dentists via Apify → Claude sanity-checks them → full parallel scrape of 1,000 (4 scrapers × 250, done in 87 seconds) → LLM classification → upload to Google Sheet → enrich missing emails → ready for a cold-email tool like Instantly. Previously 30–60 min of manual work.
• shop-amazon: browses Amazon via Chrome DevTools MCP, compares products, hard rule: “STOP — get purchase approval, do not skip.” Amazon has no public API; a skill effectively builds one.
• literature-research: queries PubMed with parallel searches, runs a deep-review script, self-corrects failed queries.
• Others: Upwork scrape-and-apply, client welcome emails, deliverable builders, YouTube editing, community post monitoring.

How to create a skill (the improvement loop)

Why it matters: MCP gives Claude instant access to real software (Gmail, ClickUp, Chrome) — but bloated servers wreck your context. Nick’s workflow: prototype with MCP, then convert to a skill.

Where to find MCPs

• Directories: mcpservers.org, the official modelcontextprotocol/servers repo on GitHub, MCP Market. Or just Google “[tool name] MCP server” — most tools publish setup pages now.
• Not all are vetted — third-party libraries carry risk. Prefer official ones.
• The GOAT: Chrome DevTools MCP — lets Claude control and inspect a live Chrome browser. Nick uses it daily; ~100× faster than generic browser extensions, and it powers skills like shop-amazon.

Install any MCP in 30 seconds

The MCP → Skill conversion play

Nick’s Gmail experiment: MCP labeled 100 emails fine, but slowly and with heavy token overhead. So he said:

This worked really well. Turn it into a skill called gmail_label.
Call the Gmail API directly instead of the MCP — skills are far more
token-efficient. Check my other skills for formatting, and write
scripts that do the work.

Result: fetch 100 emails in 1 second, full fetch-classify-label in 36 seconds (0.36s/email) — 5–10× faster than the MCP, and the loaded context dropped from thousands of tokens to a ~60-token front matter.

Why it matters: worth knowing they exist; Nick barely uses them and predicts they’ll get absorbed into skills.

• Access via customize and manage plugins in Claude Code.
• claude-mem: logs every message to a searchable memory file — “what did I ask you two weeks ago?” Marginally useful.
• frontend-design (Anthropic’s own): claims better aesthetics. Nick’s honest take: the before/after is “50-50” — his screenshot-loop workflow beats it.
• Context7: the good one — compresses API documentation from any source into token-efficient form Claude can read. Great when juggling 3–4 tools’ APIs.
• Marketplaces: the official Claude Code plugins directory (claude-plugins-official repo) + open third-party marketplaces of varying quality.

Bottom line: vanilla Claude Code does really well with zero plugins. Nothing here is required.

Why it matters: subagents aren’t magic, but two superpowers are real — clean context and parallel speed.

How they work

• Defined as .md files in .claude/agents/ — you set tools, model, max turns, memory scope, description, instructions.
• The parent spawns them via the task tool. Each subagent gets its own blank context window; only its summary returns to the parent.
• Restart the session after creating agents — they only register in fresh instances.

The 3 subagents worth building

Wire them into CLAUDE.md as a standard flow: write code (parent) → code review (subagent) → QA tests (subagent) → fix → ship.

Parallelization at scale (the email demo)

• Converted the gmail_label skill into 10 parallel subagents × 100 emails each: 1,000 emails classified in ~1 minute (vs 36s for just 100 serially).
• Gotcha he hit: subagents returned full email text to the parent → “prompt too long” crash. Fix: subagents must return summaries/results, never raw payloads.

The probability math (why simple task definitions win)

If each subagent succeeds 95% of the time, all-succeed probability = 0.95ⁿ: 3 agents → 85.7% · 10 → 59% · 50 → 7%. Subagent runs are ephemeral — a malformed batch is wasted tokens. So: keep each task dead simple, reserve the smart parent for synthesis, and don’t spawn 500 agents to look cool.

Why it matters: the most hyped feature. Real, powerful, and “a nuclear weapon aimed at your wallet” — 7× token cost.

Teams vs subagents

Enable it (off by default — experimental)

{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }

Or paste the docs page in and say “enable agent teams.” Two viewing modes: in-process (tab through agents — Nick’s choice) or split-pane (all visible, but rendering eats compute).

Demo 1 — design exploration as a search problem

• “Spin up 3 agents, create 3 fundamentally different personal-site designs” → minimalist / dark / warm, built in parallel in ~2 min. Team lead researched him first, unprompted.
• Picked the winner → spun up 3 research agents (design principles, copywriting formulas, examples from Justin Welsh, Dan Koe, Sahil Bloom, Hormozi, Ali Abdaal) → their dense reports fed 4 iteration agents → picked again → iterated again.
• The point: instead of settling on the first passable option, you explore the whole space of possible designs — tree-search your way to something 5× better.

Demo 2 — security-audit an open-source repo

• Cloned a repo, then: 10 Sonnet scanner agents split the codebase by size → 4 agents document security issues → 2 devil’s-advocate agents debate each other (one argues findings are real, one argues they’re not — adversarial setups produce higher-quality conclusions, same principle as GANs) → 15 fixer agents, one per confirmed issue.
• Cost: 1.3M+ tokens, ~$80 in ~15 minutes — vs weeks of human review. Kill switch: “SHUT everything down ASAP” (takes a moment; in-flight queries finish).

Official recommendations

• Sonnet for teammates, keep teams small, spawn prompts tight and focused.
• Clean up / wind down teams when done — idle agents still consume resources.
• It’s off by default so nobody blows $10K in a day. That’s a real possibility. Set limits.

Why it matters: multiple agents editing one folder eventually step on each other’s toes. Worktrees make collisions impossible.

A git branch is basically a copy of your folder. A worktree checks each branch out as an actual separate folder on disk — so agent A works in project-about/, agent B in project-contact/, agent C in project-services/, all sharing the same git history. When done, a merge tabulates the differences and folds each branch’s changes back into main. Merges can be messy — having agents mediate them helps.

Nick’s demo

Files are never perfect separations of functionality — that’s why conflicts happen. Worktrees eliminate the possibility structurally instead of hoping agents coordinate.

Why it matters: a tool only you can run on your laptop isn’t a product. Production means it runs without you.

What the course covers here

The pattern to internalize: local build → prove it works → move the trigger to the cloud. Everything you automated in Parts 6–7 (lead scrapers, email labelers, proposal generators) becomes a production system the moment it runs on a webhook or a schedule instead of your keyboard.