Working with Claude

Every Claude Code session is a blank slate plus whatever you tell it to read. The first 60 seconds decide whether the next two hours go well or turn into a slow slide into confusion. Get the opening ritual right and everything downstream is easier.

When you run claw in a terminal, Claude launches with the model you configured (Opus 4.7 for this course) and immediately scans the current directory. It reads any CLAUDE.md files in scope — managed policy, project root, user home, and optional local overrides — plus your auto-memory index at ~/.claude/projects/<project>/memory/MEMORY.md. That bundle is your standing instructions. Everything Claude does for the rest of the session is filtered through that context.

The first prompt matters more than any other

You can always steer Claude mid-session, but you cannot un-teach something it already assumed. If your first prompt is “build the dashboard,”Claude will pick a stack, scaffold a folder, and start writing code before you have a chance to say “no, not React, we use Next.js 16.” Now you're unwinding assumptions instead of building the thing.

The opening prompt below is the one you'll reuse across every real project. It gives Claude the goal, the guardrails, the verification criteria, and — critically — explicit permission to stop and ask before writing code. That last part is non-negotiable on any project worth shipping.

Goal: Build [one sentence on what ships].

Constraints:
- Stack: [exact stack list, e.g. Next.js 16 + Tailwind 4 + TypeScript].
- No Firebase. Vercel-native only.
- Every external doc URL verified live before writing from it.
- Preserve image aspect ratios; measure with `sips -g pixelWidth -g pixelHeight` before placing.

Before touching code:
1. Read the full brief in [path/to/brief.md].
2. Summarize what you understood in 5 bullets.
3. Ask me up to 5 clarifying questions.
4. Wait for my go-ahead.

Verification: `npm run build` must pass; final deploy must return HTTP/2 200 on the target path.

What “claw” actually is

claw is a shell alias we install in the setup chapter. It launches claude with the exact flags this course assumes — Opus 4.7 as model, adaptive thinking on max effort, permission prompts disabled for trusted operations. You will see us type claw from here on. If claw: command not found is all you get, jump back to Tab 2 and finish the install.

Everything Claude has “seen” in a session — your prompts, its replies, every file it read, every tool call it made — lives in a single buffer called the context window. On Opus 4.7 that buffer holds roughly one million tokens, where a token averages about four characters or three-quarters of a word. One million tokens is a lot. It is not infinite.

Why the buffer fills up faster than you expect

Reading a 2,000-line file costs thousands of tokens. A multi-step agent run that explores a codebase, reads five files, and runs three builds can burn 60,000+ tokens before a single line of code is written. By the time you're in the third iteration of a dashboard feature, you're often at 400k–600k tokens without noticing. Type /context to see the exact number.

Compaction — the safety net, not the plan

When your input approaches the limit, Claude's API triggers compaction. Per the official docs, compaction “extends the effective context length for long-running conversations and tasks by automatically summarizing older context when approaching the context window limit. This isn't just about staying under a token cap. As conversations get longer, models struggle to maintain focus across the full history. Compaction keeps the active context focused and performant by replacing stale content with concise summaries.” The default trigger is 150,000 input tokens, configurable down to 50,000.

In practice: older turns get replaced by a lossy summary; recent turns are preserved verbatim. The next request sent after a compactionblock ignores everything before that block. That is a feature when you're 15 hours into a coding run and a failure when compaction eats the specific nuance you needed Claude to keep in mind.

The single most valuable habit in this entire course: when you hit 80% of your context window, stop adding new work and write a handoff. One sentence, one habit, saved us from dozens of sessions that would otherwise have ended in quiet confusion.

Why 80% and not 95%

Automatic compaction will save you from an outright crash, but it will cost you the nuance you didn't know you needed. At 80% you still have headroom to write a deliberate, complete handoff: what was decided, what was tried, what didn't work and why, the exact next task with file paths and line numbers. At 95% you're racing the summarizer and the handoff itself gets truncated.

What a handoff file looks like

Save handoffs into ~/.claude/projects/<project>/memory/ as topic-named markdown files, then point to them from MEMORY.md. A good handoff has five sections: status (last commit, what's deployed, working-tree state), done this session (shipped bullets), verified facts with source URLs, not-done with file paths, and the resume line — the exact prompt you'll paste into the next session.

Context is approaching 80%. Write a full handoff file so a fresh Claude session can pick up exactly where we are.

Save it to: memory/handoff_[project-slug].md

The file must contain:
- Status: last commit SHA, what's deployed, working-tree state
- Done this session: bullet list of shipped work
- Not done: bullet list of remaining tasks with file paths
- Verified facts (with source URLs) I should not re-fetch
- The exact next task to pick up, including file paths and code snippets where relevant
- A resume line I can paste into a fresh `claw` session

After writing the file, print JUST the resume line in a code block. Do not continue any other work.

The resume line pattern

Every handoff ends with a resume line. It is not decoration — it is the only thing that stitches two sessions together into a continuous project. The format:

claude "Resume [project]. Read memory/handoff_[slug].md in full. All research verified inline — do NOT re-fetch. Start at Task #[N]. Summarize plan in 3 bullets, then go."

In a fresh terminal you type /clear(if you're still in a session), then paste that line, and the new session picks up with Claude's equivalent of your memory. The discipline of writing handoffs that actually let the next session ship is the single most leveraged skill in this course.

A good prompt for a real agency task is indistinguishable from a good Jira ticket. It has a goal, constraints, examples, a specification of the output, and explicit verification criteria. Take any of those five pieces away and you're gambling.

The five required pieces

• Goal— one sentence. What does “done” look like to the user or stakeholder?
• Constraints — stack, no-go zones, things that must be preserved, budget, deadline.
• Examples — at least one of the right thing. Optionally one of the wrong thing too.
• Output format — what exactly do you want back: code, a plan, a file path, a JSON object?
• Verification— how will you know it's right? Build passes, curl returns 200, screenshot matches, unit test green.

Fuzzy vs tight — the same task

Claude will produce something. It will pick a stack, invent a structure, hallucinate copy, and hand it back. You will spend the next two hours undoing each of those choices. Compare:

Even a tight prompt has gaps. The goal is not to write a perfect prompt on the first try — it is to give Claude permission to surface the gaps before it ships the wrong thing.

The clarifying-question pattern

Tell Claude, up front, to ask you up to N questions before touching code. The limit matters: unbounded, you'll get a 12-question interview. Bounded at 5, Claude picks the ambiguities that matter most. If the brief is actually unambiguous, Claude will say so and proceed — much better than inventing hypothetical gotchas to look diligent.

Before writing any code for this task, ask me up to 5 clarifying questions that, if answered, would let you ship without further questions.

Rules:
- Questions must reveal actual ambiguity in the brief, not test me.
- If the brief is unambiguous, say "no questions, ready to proceed" instead of inventing any.
- After I answer, re-summarize the scope in 3 bullets and wait for one final "go" before editing files.

When to use this pattern

Use it on every task that takes more than ~30 minutes of real work. For one-off edits (“rename this variable”, “format this file”), skip it — the overhead isn't worth it. For any project-shaped task — a new page, a new integration, a migration, a refactor — turning it on saves an hour of undoing work for every five minutes it costs you.

Reading Claude's questions carefully

The questions Claude asks are a direct readout of where your brief is weakest. If Claude asks which CRM you want to wire into, your brief didn't specify a CRM. If Claude asks about auth, you forgot to say whether the page is public or gated. Don't just answer — update the brief so the next task on this project inherits the tightened scope.

A 200-hour build cannot fit in one Claude session. You don't need one — you need a phase plan that slices the work into pieces a single session can finish with verification left over.

How to ask Claude for a phase plan

Before any large project, ask Claude to produce the phase plan itself. You'll get a better plan than you'd write yourself because Claude has seen more projects than any one person has, and because the act of asking forces you to say what “done” means.

This project is too big for one session. Break it into phases.

Deliver:
1. A phase list with a one-sentence goal per phase
2. Exit criteria per phase (concrete, verifiable, e.g. "curl returns HTTP/2 200")
3. Dependencies between phases (what must ship before what)
4. An estimate of how many Claude sessions each phase will take (1 or 2)

Do NOT start implementation yet. After the phase plan, wait for me to approve before touching the first phase.

Exit criteria are the contract

Every phase must have a test you can run that returns a binary pass/fail. “Looks good” is not an exit criterion. “npm run build exits 0 with zero warnings, and curl -sI https://domain.com/path | head -1returns HTTP/2 200” is.

This course is itself a phased build

For proof of concept: the 10 phases below ship this playbook from empty repo to finished 9-tab course. Each phase is one or two sessions. Each has verifiable exit criteria (a live URL returning 200, a chapter word count, a passing build).

Claude is very good at shipping code that looks right. It is less reliably good at shipping code that is right. The gap between those two is closed by a review loop — one or two explicit verification passes where you ask Claude to audit its own work against a checklist.

Why two rounds, not one

In the first pass, Claude finds the obvious problems — unused imports, missing error cases, dead code. In the second pass, with round-one issues fixed, it finds the subtler ones — silent brief deviations, hallucinated API paths, unverified external links. Three rounds is usually overkill; one round is usually not enough.

Subagents — independent second opinions

Claude Code ships with a sub-agent system: small, prompt-scoped Claude instances that spawn for a specific review task and return their findings without polluting your main context. Use one when you want an unbiased read — the subagent didn't see your reasoning, so it can't be anchored by it.

The implementation is complete on paper. Do a verification pass now.

Checklist:
1. Does every exit criterion from the phase plan pass? (Cite the evidence: command output, file content, curl result.)
2. Does the build pass with zero warnings?
3. Have you verified every external link / API path against live docs, not memory?
4. Are there silent deviations from the brief? List any — a deviation is still a deviation even if the result looks fine.
5. Is there dead code, unused imports, or half-finished scaffolding to remove?

Report findings as a numbered list. Fix anything that fails before saying "done."

Memory is how Claude remembers things across sessions. There are two systems, they do different jobs, and knowing when to use which is one of the biggest productivity unlocks in the product.

The two systems

CLAUDE.md scopes — in load order

Claude Code reads up to four CLAUDE.md files per session. They stack; later ones add to and can override earlier ones.

• Managed policy — /Library/Application Support/ClaudeCode/CLAUDE.md on macOS, /etc/claude-code/CLAUDE.md on Linux/WSL, C:\Program Files\ClaudeCode\CLAUDE.md on Windows. Org-wide policy. Most agencies never touch this.
• Project — ./CLAUDE.md or ./.claude/CLAUDE.mdin the repo root. Committed. This is the file you'll edit 90% of the time.
• User — ~/.claude/CLAUDE.md. Your personal preferences across every project.
• Local — ./CLAUDE.local.md. Gitignored, for notes you don't want committed.

Auto-memory — where and how

Auto-memory lives at ~/.claude/projects/<project>/memory/. The project identifier is derived from the git repository, so every worktree of the same repo shares memory. Outside git, the project root is used. The directory holds individual topic files plus one index: MEMORY.md. The first 200 lines or 25KB of MEMORY.md, whichever is smaller, is auto-loaded into every session. Topic files are loaded on-demand when Claude decides they're relevant.

Keep MEMORY.md as an index. One line per entry, topic-sorted. The actual content lives in the referenced files. If you dump raw content into MEMORY.md, you'll blow past the 200-line load limit and Claude will silently stop seeing your most recent entries.

Our taxonomy for auto-memory

Anthropic's auto-memory doesn't prescribe how to organize files. We layer our own convention on top: four types, picked for the distinct job each does.

• user— who the user is, what they're working on, what they know. Keeps Claude's framing aligned.
• feedback— corrections and confirmations. When you say “don't do X” or “yes, that was the right call,” that becomes a feedback memory.
• project — session state, work in progress, handoffs. These rot fastest; clean them when the project ends.
• reference — pointers to external systems. Slack channels, Linear projects, Grafana dashboards. Durable.

Before you start this task, read:
- memory/MEMORY.md (full — this is the index)
- Every file MEMORY.md points to that is relevant to: [describe the topic, e.g. "the ZNF storefront project" / "image aspect ratio rules"]

Summarize what you learned in 5 bullets, then ask up to 3 clarifying questions if needed. Do not edit code until I confirm.

Save the following to memory so future sessions remember it:

Type: [user | feedback | project | reference]
Name: [short-kebab-title]
Description: [one-line, used for future relevance matching]
Body: [the actual rule / fact / pointer]

After writing the new memory file, add a one-line pointer to memory/MEMORY.md under the correct section. Confirm both writes completed.

Slash commands are the shortcuts that make daily work fast. Skills are custom workflows you author once and invoke anywhere. Subagents are ephemeral Claude instances that run isolated work. All three are invoked with the same / prefix, but they play different roles.

The slash commands you'll actually use

• /clear — reset session buffer. Use after every handoff.
• /compact — trigger summarization on demand before a risky new task.
• /memory — open and edit the auto-memory system.
• /init — generate a starting CLAUDE.md for a new repo. Set CLAUDE_CODE_NEW_INIT=1 for the interactive flow.
• /model — switch the active model.
• /effort — set adaptive-thinking effort (min / max / auto).
• /fast — toggle Opus 4.6 fast mode for rapid iteration.
• /help, /cost, /context — utility diagnostics. /context shows current token usage; stop at 80%.
• /resume, /rewind — session continuation and timeline controls.
• /plan — switch to plan mode. Claude writes a plan before touching code.
• /agents, /skills — list registered subagents and skills.

Skills vs subagents

Custom skills — your team's playbook as a command

Every repeatable workflow your agency has — “deploy the client dashboard,” “generate a weekly report,” “audit this copy for tone” — is a candidate for a skill. The skill file is markdown with YAML frontmatter defining when to trigger and what tools to expose. Anyone in your team with claw installed gets the skill automatically if it lives in the shared project repo.

---
name: deploy-check
description: Verify a Vercel deploy went live and returns 200 on the primary path.
---

Run the following:
1. `vercel ls` and confirm the latest deploy is READY.
2. `curl -sI https://DOMAIN/PATH | head -1` and confirm HTTP/2 200.
3. Post the URL + status into the current conversation.

If any step fails, print the failure and stop.

Two failure modes account for almost every bad Claude session on real client work. Both are silent. Both are expensive. Both go away with the same discipline: verify before you trust.

The smoke-test-every-claim rule

When Claude says “done,” run the verification yourself. Three commands, every time: npm run build exits 0, curl -sI <url> returns 200, and a human load of the page shows the expected content. If any of those three fail, the task is not done, regardless of what Claude claimed.

Anthropic ships three active production models. Each has a different price, context, and intended job. For agency work of the kind this course is about — real deliverables that clients pay for — Opus 4.7 on highest reasoning is the default, every time.

The three models you'll see

Why no downgrade on real work

When a session for real client work looks off, the fix is never “drop to Haiku to save tokens.” The fix is to slow down, tighten the prompt, and confirm the model. On anything shipping to a customer, the quality floor — correctness, nuance, taste — matters more than the token cost. A regenerated deliverable that client-reviews poorly costs more than 10x the Opus-vs-Haiku savings on the original run.

Adaptive vs extended thinking

Opus 4.7 is adaptive-only. You set an effort parameter — min, max, or auto — and Claude chooses how much to think per turn. For clawwe lock to max effort. Sonnet 4.6 supports both modes with extended thinking deprecated; Haiku 4.5 supports both. You won't touch those distinctions most days — /effort max is the knob that matters.

Deprecations to keep an eye on

• Claude Sonnet 4 (claude-sonnet-4-20250514) and Claude Opus 4 (claude-opus-4-20250514) retire June 15, 2026. Move off them now.
• Claude Haiku 3 retires April 19, 2026.