Your first session
Start in a repo, let /init write a first CLAUDE.md, ask for something small you can check, and learn where to read what Claude actually did.
Start where the work is
Open a terminal in the repository and run claude. The directory you launch from matters. Claude walks up from it and loads every CLAUDE.md it finds above, and files in subdirectories below load later, when Claude touches something there.
Launching in the root of the project you actually mean to change is the simplest habit. If you later need another directory, /add-dir <path> adds it, and /cd <path> moves the session while keeping the conversation.
Let /init write the first draft
/init generates a starting CLAUDE.md for the project. That file is plain markdown read at the start of every session, and it is context, not enforced configuration.
Treat the generated file as a draft. The guide gives one test for every line in it: could Claude find this by reading the code, and would it actually go look? If both answers are yes, the line only costs context. Keep what Claude cannot guess, such as how you build and test, or a convention that looks wrong but is intended.
A line in CLAUDE.md describes something Claude would find on its own by reading the code. What should you do?
What to ask first
Your first request should be small, concrete, and checkable. A good opening is a task with a visible result: a failing test to fix, a function to rename, a question about how a module works. Name the file, say what you see, and say what fixed looks like.
Three input tricks help immediately. @path mentions a file so Claude reads it. ! at the start of a line runs a shell command and puts its output into the session. Ctrl+V pastes a screenshot as an [Image #N] chip you can refer to by number.
$ claude> @src/format.ts the date test fails with "1 Nov" instead of "2 Nov". Fix it and run the test file to show it passes.✻ Reads src/format.ts and the test✻ Asks permission to edit src/format.ts# You approve one edit, then watch the test run.
Reading what it does
Do not let the answer be the only thing you read. The actions are the record. Each permission prompt shows exactly what Claude wants to run or change, so read it before pressing yes.
Afterwards, /diff reviews the working-tree changes. Ctrl+O toggles the transcript viewer, which shows timestamps and the model per message. Ctrl+T shows Claude's task checklist for a long job. Esc interrupts and keeps the work done so far, so stopping is cheap.
If something about the installation or settings looks off, /doctor checks installation, settings, extensions and context usage and proposes fixes.
Claude says it fixed the bug. What is the best next step?
Chapter complete
You've finished chapter 2 of 6 in Claude Code foundations.
Six modes decide how much Claude may do without asking. Pick the mode by what a mistake would cost, and put hard rules where the harness enforces them.
Next chapter