The first run in a real repository sets the tone for all the work, and it is wisest to begin it not with a task but with state. Before typing claude, it is worth looking at git status and the current branch yourself - to know the starting point exactly and later tell your changes from others'. This is cheap insurance: the agent will change files, and a clean, clear start turns any subsequent diff into a meaningful picture rather than a riddle.
On the first run Claude Code asks to confirm trust in the working directory, and this is not a formality. Project settings, project MCP, agent hooks and other executable customizations can come from a cloned repository - that is, be written by someone else. Until the workspace is trusted, Claude Code deliberately ignores some project approvals and hooks. Trust here is a conscious decision to admit the repository's executable configuration, not an "ok" button on the way to work.
Right after login it helps to run a diagnostic minimum and read what actually loaded. The /status, /context and /permissions commands show the current directory and the repository root, the model and provider, the loaded user, project and local settings sources, memory files, the active permission mode and any already existing MCP servers and plugins. This is a snapshot of the environment: until you have seen it, you do not know under what conditions the agent works, and any surprise later will cost more.
A starting CLAUDE.md is conveniently created with the /init command, but it must be treated as a draft, not a source of truth. /init explores the project and proposes a first CLAUDE.md, and if the file already exists it proposes improvements rather than silently overwriting. From the draft you remove the obvious that Claude already sees in package.json, and add what cannot be reliably guessed from the code: verification commands, boundaries ("do not change migrations without approval") and a definition of done.
It helps to see once what a meaningful CLAUDE.md should be - a project contract, not a retelling of the structure. Below is a compact example with commands, boundaries and a definition of done. You return to this form when filling the project's memory: it keeps instructions short and checkable, names what the agent will not infer itself, and sets the criterion by which a task counts as done.
The first request decides almost everything, and a good request is not "figure out the project" but a final result with boundaries. It is sensible to start with exploration without changes: ask to find the entry points, verification commands, module boundaries and the configuration mechanism, and at the end give a map of the files actually read and a list of questions that cannot be reliably resolved from the code. An explicit ban on edits at this step keeps the agent from prematurely editing poorly understood code.
A change is framed as a separate, equally concrete request. Instead of "fix bug X" you ask to first reproduce it with an existing test or a minimal deterministic scenario, show the root cause, make the minimal change, run the check and report the exact commands, exit codes and remaining risks - with an explicit ban on touching the public API and files outside the needed module. Such a request itself structures the work better than any mode switch.
The engineering conclusion from the first run is simple: the first turn is better spent on a map of the project and a verification criterion than on edits. An agent that immediately edits poorly understood code quickly creates a lot of context and false confidence that it "got it all". Plan mode from the next chapters helps, but a concrete verifiable request matters more than the switch itself. The typical first-run failure is a broad task with no boundaries on an untrusted workspace; the right start is a clean git, a read /status and a request with a goal, boundaries and verification.
# Project contract
## Commands
- Test: `pnpm test`
- Typecheck: `pnpm typecheck`
- Lint: `pnpm lint`
## Boundaries
- Do not change database migrations without explicit approval.
- Do not edit generated files under `src/generated/`.
## Definition of done
- Typecheck and focused tests pass.
- Report changed files, commands run, exit codes and remaining risks.# First - state yourself, then launch
git status --short
git branch --show-current
claude
# After login - what actually loaded
/status # directory, model, provider, settings sources
/context # memory files, context usage
/permissions # active mode and rules