# 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.

> **Edits to CLAUDE.md wait**
Changing CLAUDE.md mid-session does not change the running session. The new text loads after `/clear`, `/compact` or a restart.


**Question:** A line in CLAUDE.md describes something Claude would find on its own by reading the code. What should you do?

- Keep it, more detail is always better
- Leave it out, it only costs context
- Move it to the end of the file
- Turn it into a deny rule

**Answer:** Leave it out, it only costs context. The guide's test is whether Claude could find it by reading, and would go look. If so, it does not belong in the file.


## 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.

```terminal
$ 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.

> **Check the footprint, not the summary**
Claude's final message says what it believes it did. `/diff` shows what changed. When the two disagree, the diff is right.


If something about the installation or settings looks off, `/doctor` checks installation, settings, extensions and context usage and proposes fixes.

**Question:** Claude says it fixed the bug. What is the best next step?

- Trust the summary and commit
- Run /diff and the check you asked for
- Run /clear to start over
- Ask the same question again

**Answer:** Run /diff and the check you asked for. The summary is Claude's belief. The diff and a passing check are evidence.


> **Your first loop**
In a repo you know, ask for one small change plus its check. Approve the edit prompt, then open `/diff` and read it line by line before you accept anything.