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

How to run this session

This guide is built to be handed to an AI assistant, which then walks you through it one step at a time. Claude Code in a terminal, Claude Desktop, and Codex all work. Save this page to your machine, open a fresh assistant session, give it this file, and paste this:

Walk me through Session 2.1 one step at a time.
Give me only the current step. Stop after each step and wait for me to say it's done.
Before each step, check whether it's already done on this machine, and skip it if it is.
Tell me what each command does before I run it.
Start at the beginning.

Then work through it together. Tell the assistant when a step is finished, or paste the error when one isn’t.

If you don’t have an assistant on this machine yet. This session installs one. Do Step 1 and Step 2 below by hand, then come back and hand this file to what you just installed. If you already have Claude or Codex available anywhere else, on a work laptop or the web app, hand it this file now and let it drive the installs too.

Assistant: the rules below govern this whole session. They override any default habit of reading a document and summarizing it.

  1. One step per message. Give the learner the current step and nothing else. Do not list the steps that follow, do not preview what is coming, and do not merge two steps because they look short. An outline of the session counts as revealing the steps, so do not produce one. If the learner asks how long this will take, give a count and a time estimate rather than a list.
  2. Stop and wait. End each step by asking the learner to do it and report back. Do not continue until they answer.
  3. Check before you instruct. Most steps name a way to tell whether the work is already done on this machine. Ask for that check first. When it passes, say the step is already satisfied and move on.
  4. Explain before you instruct. For every command, say in one or two sentences what it actually does and why this step exists, before the learner runs it.
  5. Debug in place. When something fails, fix it with the learner here. Do not send them to a documentation page, and do not skip ahead.
  6. Resume cleanly. If the learner comes back later and says where they stopped, confirm that position and give the next step only. Do not recap what they already did.
  7. Posture. Every example uses public sources, invented scenarios, or the learner’s own personal material. Never ask for anything belonging to their employer or a client. If they offer some, redirect to a public equivalent.
  8. Audience. A capable professional on macOS who has not lived in a terminal day to day. Write peer to peer. Do not explain the learner’s own field back to them.
  9. The Reference Sections below are addressed to you, not to the learner. They are stage directions. Turn them into steps and deliver them one at a time. Never paste them at the learner.
  10. Which tool the learner uses. This curriculum works with Claude Code or Codex. The learner’s CLAUDE.md or AGENTS.md records which one; if it does not, ask once and do not ask again. Where a step below has a ### Claude Code version and a ### Codex version, deliver only theirs and do not mention the other exists. Everywhere else the work is identical, so say “your assistant” rather than assuming Claude. This is about the tool the learner installs and works in, not about which assistant is reading this guide.

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

Already done? If you already have a GitHub account, skip the numbered steps below.

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 stall on account-creation friction.

Practice task

By the end of this session you will have:

  1. A working CLI on your laptop, either claude or codex.
  2. A working directory ~/ai-training/ (or whatever name you pick) with an instructions file inside it: CLAUDE.md for Claude Code, AGENTS.md for Codex.
  3. Two real files in that directory, produced by your assistant in the same session:

Two outputs is the bar. They prove the loop works: you ask, your assistant pulls real data, 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, the 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)

Already done? Open Spotlight and type Wispr. If it launches, skip to Step 2.

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.

Step 2: Install the CLI (2 minutes)

This curriculum runs on either Claude Code or Codex. Pick one now. The examples are written against Claude Code, and everything in them transfers; where the two genuinely differ, the guide gives you both versions and your assistant hands you only the one you picked.

Already done? Run claude --version, then codex --version. If either prints a version number, you already have that one. Tell your assistant which, and skip to Step 2.5.

Claude Code

In your terminal:

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

What this does. curl downloads the installer script from Anthropic. The | pipe hands that script straight to bash, which runs it without ever saving it to disk. The script puts the claude binary in ~/.local/bin and adds that folder to your PATH, the list of places your shell looks when you type a command.

Close and reopen the terminal, then:

claude

It opens a browser to authenticate. Sign in with your personal Claude account. Pro and Max both work; Max is worth it once you’re using this daily.

Codex

In your terminal:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

What this does. Same shape as the Claude installer. curl downloads the script from OpenAI, the | pipe hands it to sh, which runs it without ever saving it to disk, and the script puts the codex binary on your PATH, the list of places your shell looks when you type a command.

Close and reopen the terminal, then:

codex

It prompts you to sign in with ChatGPT the first time.

Worth knowing. Both installers pipe a script straight from the internet into a shell, which runs whatever that URL serves at the moment you run it. Do it only for vendors you trust. Anthropic and OpenAI qualify; the install one-liner in a random blog post does not.

Whichever you installed, the reopened terminal is the part that matters. Your open terminal read its PATH when it started, so it will not find the new command until you close it and open a fresh one.

Quick smoke test inside the session:

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

That one is a prompt, not a shell command. You’re checking that your assistant can actually see your filesystem, which is the whole reason this curriculum uses a CLI.

/exit when done.

Step 2.5: Set up your working directory

Already done? Run ls ~/ai-training. If it exists, skip to Step 3.

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

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

What this does. mkdir -p creates the folder and doesn’t complain if it already exists. cd moves your shell into it, so everything you run next happens there.

The directory name is up to you — ai-training matches the rest of this curriculum, but if you prefer something else (briefings, workbench, anything), use it. Whatever you pick, be consistent: cd into it before every 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

What this does. ~/.zshrc is your shell’s startup file. It runs every time you open a new terminal, which is why it’s the right place for aliases and PATH changes. echo "..." >> ~/.zshrc appends that one line to the end of the file without touching what’s already there. source ~/.zshrc re-reads the file into your current terminal, so the alias works now instead of waiting for the next window.

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 follow “How to run this session” at the top of this guide if you haven’t already.

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:

Already done? Open Spotlight and type iTerm. If it launches, skip the install and go straight to setting it as default.

brew install --cask iterm2

What this does. Homebrew is the package manager for macOS. It installs command-line tools and casks (full apps like iTerm2) into a spot the system doesn’t manage, so you’re not fighting macOS permissions. brew install --cask iterm2 downloads and installs the iTerm2 app the same way the App Store installed Wispr Flow in Step 1.

(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, from ~/ai-training:

Claude Code

Inside claude:

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.

WebFetch goes out to the live web, returns the article body, Claude summarizes, and the Write tool drops the file into ~/ai-training/.

Codex

Codex’s built-in search returns snippets rather than whole pages, so fetch the page to disk first and have Codex read it from there. In your terminal:

curl -L -o article.html "<the Wikipedia URL for the topic the user picked>"

What this does. Same curl from Step 2, in a different role. -L follows redirects, which Wikipedia uses. -o article.html writes the page to that file instead of printing it to the screen.

Then, inside codex:

Read article.html. 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.

This is the better version of the beat, so don’t apologize for it. The user watches a file arrive from the internet, then watches their assistant read that file and write another one. The loop is visible in two discrete moves instead of one opaque one.

Either way: 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. This one works the same on both tools. Inside your assistant:

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.

If the user is on Codex and the result looks stale, its search defaults to a cached snapshot. --search on the command line, or web_search = "live" in ~/.codex/config.toml, switches it to live results.

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

Tell the user: “Half the workflows in this curriculum are some shape of that loop — your assistant 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 an assistant beyond search, file, and shell access) come in Session 2.5. For now the built-ins are enough for several real workflows.

Write the instructions file

The working directory was already created in Step 2.5. Now write the instructions file inside it — the file the assistant reads automatically every time the user starts a session in this folder. Claude Code reads CLAUDE.md; Codex reads AGENTS.md. Same job, same content, different filename.

Already done? Run ls ~/ai-training/CLAUDE.md ~/ai-training/AGENTS.md. If either exists, read it back to the user and ask if they want to revise it instead of starting over.

Write the file for the user, then have them review and adjust. Use the filename matching their tool.

# Working Directory

## Tooling
- CLI: [Claude Code | Codex], installed Session 2.1.
- Use the matching path in every session guide from here on.

## 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, this CLI, 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
- CLI built-ins: web search, file and 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.

The ## Tooling line matters more than it looks. Every later session’s guide has a Claude path and a Codex path; the assistant reads this file at session start, so it already knows which one to hand the user instead of asking again every week.

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

One difference worth flagging if the user is on Codex: Codex also reads a global ~/.codex/AGENTS.md and concatenates it with every AGENTS.md between the git root and the current directory, closest one winning. Claude Code reads the one in the directory the session started from. Same idea, wider net.

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

Downloading this guide. If you’re viewing this guide as a hosted HTML page and want a local copy: open Terminal and run curl -L -o guide.html "URL" (replacing URL with the page address). That saves it to your current directory.

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.