Session 2.1: Get Claude on your laptop, plan for the office

Welcome. This is a 10-week curriculum to get you working with Claude Code at a level where “synthesize this, draft that, automate the other” stops being a multi-day chore and becomes a one-session task. You’re not learning to code — you’re learning a workflow.

This session takes about 45 minutes. Setup is the first 20; the rest is posture, organization, and a short conversation so the next nine sessions can be tailored to what you actually need.

You’re running this on your own personal laptop — the machine where you have admin privileges and can install software freely. Step 0 covers what should and shouldn’t land here.

Before you start

Create a GitHub account if you don’t have one. We’ll lean on it starting Session 2.6 (when you build a corpus pipeline) and again in the bonus website-build session.

  1. Go to https://github.com/signup.
  2. Use any email you’ll remember the password for.
  3. Pick a username — your real name or initials is fine; it doesn’t have to be clever.
  4. Verify the email (GitHub sends a code).

Two minutes. You won’t need it today, but having it ready means Session 2.6 doesn’t blocker on account-creation friction.

Practice task

By the end of this session you will have:

  1. A working claude CLI on your laptop.
  2. A working directory ~/ai-training/ (or whatever name you pick) with a CLAUDE.md inside it.
  3. Two real files in that directory, produced by Claude in the same session:

Two outputs is the bar. They prove the loop works: you ask, Claude pulls real data from the live web, writes it to disk, you read it back. Everything in this curriculum is some elaboration of that loop.

A production version of this setup looks similar — Homebrew, Node, Claude CLI, plus Gmail and Calendar MCP servers running as launchd jobs that auto-restart on crash. You’re not doing the MCPs today (Session 2.5 covers that), but the destination is the same: a laptop that’s a real workstation for AI-assisted work, not a chat window.

Why the terminal

Most of the work in this curriculum happens in a terminal, not in Claude’s web UI or desktop app. Three reasons it’s worth the upfront friction:

  1. In-place file edits. Claude Code reads and modifies the actual files on your machine — drafts, spreadsheets, scripts. The web app can’t.
  2. Hand-this-guide-to-Claude pattern. Every session works by you opening a terminal and saying “read the file at [path] and walk me through it.” That only works when Claude has filesystem access.
  3. Two-terminal workflow. Starting Session 2.3, you’ll run two claude sessions side-by-side in split panes — one drafting, one running headless jobs. The web UI doesn’t do split panes.

That’s the why. The rest is mechanics.

Step 0: Read the personal-laptop policy

Before you install anything, read POLICY-personal-laptop.md in the v2 folder (one level up from this guide, at ../POLICY-personal-laptop.md). It’s one page. The single rule: public, synthetic, or personal data only on this machine. Nothing belonging to your employer or a client should land here.

This is the load-bearing rule of the whole curriculum. It’s how you learn the shape of the work without dragging sensitive material onto a personal machine. The workflow you build here transfers cleanly to wherever your work material is authorized to live.

When you’ve read it, come back.

Step 1: Install Wispr Flow (2 minutes)

Voice input. Faster than typing, especially when you’re describing what you want while your hands are on the keyboard.

  1. Open the App Store on your Mac (Cmd+Space → “App Store”).
  2. Search Wispr Flow and install.
  3. Open it; grant Accessibility permissions when prompted.
  4. Default hotkey: hold Fn. Hold, talk, release — your words appear at the cursor.

Skip if already installed.

Step 2: Install Claude Code CLI (2 minutes)

In your terminal:

curl -fsSL https://claude.ai/install.sh | bash

Close and reopen the terminal, then:

claude

It’ll open a browser to authenticate. Sign in with your personal Claude account (Pro or Max — both work; Max is worth it once you’re using this daily). Quick smoke test inside the session:

What files are in my home directory? Just a quick summary.

/exit when done.

Skip if claude --version already returns a version.

Step 2.5: Set up your working directory

Make a single home for your Claude Code work now, before you hand Claude this guide. Doing this up front means every future session opens in the right folder, and the CLAUDE.md you’ll write later gets picked up automatically.

mkdir -p ~/ai-training
cd ~/ai-training

The directory name is up to you — ai-training matches the rest of this curriculum, but if you prefer something else (claude-master, briefings, anything), use it. Whatever you pick, be consistent: cd into it before every claude session.

Optional alias. If you’d rather skip the cd step every time, add a one-word shortcut to your shell. Name it whatever you want — goclaude, briefings, work, anything you’ll remember:

echo "alias goclaude='cd ~/ai-training && claude'" >> ~/.zshrc
source ~/.zshrc

Now goclaude from any new terminal jumps you into the working directory and starts Claude in one step.

Step 3: Hand Claude this guide

The rest of this session runs through Claude. From inside ~/ai-training, start claude and paste:

Read the file at /Users/<you>/ai-training/week-1-guide.md (or wherever you saved it) and walk me through the Reference Sections.
I've read POLICY-personal-laptop.md and acknowledge the public/synthetic/personal-only rule.
I've installed Wispr Flow and Claude Code CLI, and I'm running this from my working directory.

Claude takes over from here.

Reference Sections

Claude: the sections below are for you. Walk the user through them in order. The user is a curious professional setting up Claude Code for their own work — could be a researcher, lawyer, manager, founder, analyst, anyone whose job involves synthesizing sources and producing written deliverables. Write peer-to-peer, terse, no over-explanation. They have not lived in a terminal day-to-day, so concepts that touch shell, file paths, or version control may be new; the workflow framing is not.

Hard rule throughout this entire 10-week curriculum: every example uses public sources, synthetic / hypothetical scenarios, or the user’s own personal material. Never ask the user to paste internal work-product. If the user volunteers something internal, redirect: “let’s abstract that one level — what’s a public-data analogue we can work with?” Reinforce whenever relevant.

Interaction rules: - Don’t over-explain the user’s domain. They know their work. You’re teaching the workflow. - The user is likely on Terminal.app and has not customized their shell. Walk them through any terminal upgrade. - If something fails, debug with the user directly — don’t hand off to a documentation page.

The structure below: confirm posture → upgrade terminal → produce the two practice-task outputs → write CLAUDE.md → conversation → wrap-up. The two outputs are the spine of the session — everything else supports landing them.

Confirm the posture

Before any setup work, confirm out loud that the user has read POLICY-personal-laptop.md and understands the public/synthetic/personal-only rule. If they haven’t, pause and read it together now (one page, at ../POLICY-personal-laptop.md relative to this guide). Don’t skip past it.

Then ask one question to make sure it landed: “Quick check — if a colleague forwards you a confidential work document this afternoon and you want me to summarize it, what’s the right move?” Correct answer: don’t paste it on this machine. Use the right channel for that material. The wrong answer doesn’t disqualify the user — but it tells you to spend an extra minute on the rule before moving on.

Upgrade your terminal

Ask the user what terminal they use.

The terminal you use is your call. The one feature this curriculum relies on is split panes — starting Session 2.3 the user runs two claude sessions side-by-side. Any modern terminal handles that. iTerm2, Ghostty, and stock Terminal.app all work; Anup uses iTerm2 and recommends it for first-time users because the splits are dead-simple. Ghostty (newer, GPU-accelerated, ghostty.org) is a fine alternative for users who already prefer it.

If the user is on Terminal.app and wants to upgrade, walk them through iTerm2:

brew install --cask iterm2

(If Homebrew isn’t installed: /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" first.)

Open iTerm2, set as default terminal (iTerm2 menu → Make iTerm2 Default Term). Key shortcuts: Cmd+D vertical split, Cmd+Shift+D horizontal, Cmd+T new tab.

If the user wants to stay on Terminal.app or move to Ghostty, don’t push iTerm2; just confirm their choice supports split panes and move on.

Practice task — produce the two outputs

This is the core beat of the session. The point is to give the user a tangible “the loop works” moment by leaving real files on disk. Built-in tools only — no MCP servers (those come in 2.5).

Output 1 — Wikipedia summary. Pick a topic the user actually cares about (a public-policy issue they follow, a sport, a research area, an industry). Don’t pick a generic example; ask them. Then run, inside claude from ~/ai-training:

Use WebFetch to pull the Wikipedia article on <topic the user picked>. Write
a one-paragraph summary plus three open questions a careful reader would
still have, and save the result to wikipedia-summary.md in this directory.

Watch what happens together. WebFetch goes out to the live web, returns the article body, Claude summarizes, and the Write tool drops the file into ~/ai-training/. After it lands, cat wikipedia-summary.md so the user sees the file is real and on disk. That’s the moment.

Output 2 — recent event. Now WebSearch:

Use WebSearch to find one significant public event from the last 30 days in
<topic area or related space>. Save to recent-event.md: the date, the
one-line headline, the source URL, and a single sentence on why it matters.

Same beat: file lands on disk, user reads it. They now have two real files produced by Claude pulling live data.

Tell the user: “Half the workflows in this curriculum are some shape of that loop — Claude pulls real data, writes it down, you read it back. Nothing on your machine that wasn’t already public; everything from public sources.”

Optional, defer if the user wants: MCP servers (third-party tool plugins that extend Claude beyond WebSearch / WebFetch / file / shell) come in Session 2.5. For now the built-ins are enough for several real workflows.

Write CLAUDE.md

The working directory was already created in Step 2.5. Now write the CLAUDE.md inside it — that’s the file Claude reads automatically every time the user starts a session in this folder.

Create CLAUDE.md at ~/ai-training/CLAUDE.md with this content (Claude: write this file for the user, then have them review and adjust):

# Claude Code Working Directory

## Posture
- Personal laptop. Public, synthetic, or personal data ONLY.
- Never paste internal work-product, real client/colleague names, or
  confidential material into this directory.
- See POLICY-personal-laptop.md.

## Background
- Role: [the user fills in: actual job title / domain].
- Comfortable with: [the user fills in].
- New to: terminal-driven workflows, Claude Code, MCP servers.

## Goals for this curriculum
- Build a recurring custom briefing tool by Week 10 — topic of the user's choice.
- Synthesize a long source document into a one-page brief in a single session.
- Automate a weekly scan that lands a fresh briefing in the user's inbox or a
  Drive folder.

## Tools available on this machine
- Claude Code built-ins: WebSearch, WebFetch, file/shell access
- pandoc, markitdown, marker-pdf (document round-trip — installed Session 2.3)
- Standard Python, Git
- MCP servers: added incrementally starting Session 2.5

## Working style
- Peer-level technical explanation. No over-scaffolding.
- Surface the why, not just the how.
- When I propose something internal-sounding, redirect to a public/synthetic analogue.

Tell the user: every time they open a claude session in ~/ai-training, Claude reads this file first. It’s how the assistant remembers who they are and what the rules are.

Brief conversation

Run this as a real conversation, not a form. The point is to learn enough about the user to tailor Sessions 2.2 through 2.10. Keep it under 10 minutes.

Ask:

  1. What’s their work — what domain, what role, what does a typical week look like?
  2. What does a “good week” look like for them on the production side? What’s the deliverable they wish was easier — a memo, a brief, a report, a deck, an email digest, anything?
  3. How comfortable are they in a terminal? Have they used Git? Have they written Python or another scripting language, even casually?
  4. What kinds of public sources do they most want to be able to track and synthesize? News, regulatory filings, scientific literature, market data, court filings, public datasets, RSS feeds? Pick one — that becomes the running example for the rest of the curriculum.
  5. What’s the one personal-life or side-project workflow they’d like Claude Code to take off their plate? (Useful as a low-stakes warm-up exercise outside the day job.)

Based on their answers, build a 3-bullet “Suggested Session 2.2 Focus” — note it for the wrap-up. The curriculum is the same shape for everyone, but the public examples should hit closest to what the user will actually want to do.

Micro-skills introduced

Mention these explicitly so the user has names for what they just did. They’ll come back in later sessions:

Wrapping up Session 2.1

Three concrete things for the user to try this week. Tailor to their answers above. Defaults if needed:

  1. Run one live-data query a day for five days, on five different public topics. Build the muscle memory of “ask Claude, get sources back, read.”
  2. Update CLAUDE.md as the user learns about themselves — what works, what doesn’t, what tone they want. Five minutes maintenance now saves an hour of re-explaining later.
  3. Read POLICY-personal-laptop.md once more before next session. Bring anything unclear or pushback-worthy to Session 2.2.

Feedback.

The user submits feedback at https://docs.google.com/forms/d/e/1FAIpQLSfQAOdEBjUnfkTGjbQ4uf-6vyKd74_gUyLQ6R5F2t4qYKKKDA/viewform.

Claude: paste the URL into chat. The form mirrors the questions below. Collect answers conversationally first, then have the user click through and submit.

  1. On a 1–5 scale, how useful did this session feel?
  2. Did the personal-laptop posture rule land cleanly, or does any part feel impractical for their work?
  3. The two practice-task outputs — did landing real files on disk make the loop feel concrete, or did it feel underwhelming?
  4. How comfortable are they in iTerm2 right now? 1 (foreign) to 5 (second nature).
  5. Of the public-source domains they mentioned, which one do they most want to be able to synthesize fluidly by Week 10?
  6. What confused them most this session?
  7. Anything they want covered in Session 2.2 that they didn’t see here?

Tell the user: “Your instructor uses these to tailor next week’s session.”

Good to know

Personal Claude account. This curriculum runs entirely on your personal Claude subscription. No employer auth, no commercial agreement.

Pro vs Max. Pro ($20/mo) is fine for the early sessions. By Session 2.6 (corpus pipelines with parallel sub-agents), Max ($100/mo) starts to pay for itself — agent fan-outs eat tokens.

/fast. Type /fast in any session for faster Opus 4.6 output when full 4.7 is overkill.

When Claude is wrong about a fact. Claude trained on a snapshot. Live web tools (WebSearch, WebFetch) are real-time. When they disagree, trust the live tools.

When in doubt about content posture, ask before pasting. A 30-second sanity check costs nothing. A piece of work-internal material landing on a personal machine — even briefly — costs a lot.