You ran npm install -g @anthropic-ai/claude-code, typed claude, and an interactive shell appeared. Now you're staring at a blinking prompt with no idea what to ask. This guide is for that exact moment: the developer who has Claude Code installed but hasn't done anything productive yet, and wants a safe, repeatable first-session routine instead of guessing.
The short answer: your first job is not to ask a question. It's to make sure Claude Code actually understands the project you're sitting in. Get the working directory right, give it a context file, confirm its understanding with a small read-only question, and check the permission model before you let it write anything. Do those four things in order and the blank-prompt paralysis disappears.
Everything below maps to the official Claude Code common workflows guide. I'll flag where the docs and a lot of beginner advice diverge, because one common claim — "sessions are lost forever" — is wrong, and believing it changes how you work.
The 60-second routine, before you ask anything
Here is the order I run every time I open Claude Code in a project I haven't used it on before. It's deliberately boring.
cd my-project # 1. land in the project root
claude # 2. start the interactive session
# 3. /init (run inside the session) — create or refresh CLAUDE.md
# 4. ask a small read-only question to confirm understanding
The reason this works is that Claude Code is directory-scoped. When you launch it, the current working directory becomes the root it reads, edits, and runs commands against. The docs spell this out in their "codebase overview" recipe: step one is literally cd /path/to/project, step two is claude. If you start it from your home folder or a parent directory, it will happily reach for the wrong files. The first failure mode for new users isn't a bad prompt — it's running from the wrong cwd.
Why CLAUDE.md is the highest-leverage file
If a file named CLAUDE.md sits in your project root, Claude Code loads it into context at the start of the session. This is where you put the things you'd tell a new teammate on day one: how the project is laid out, the commands that build and test it, naming conventions, and anything non-obvious.
Without it, Claude has to discover all of that by reading files on demand — slower, and more likely to guess wrong about your stack. With it, the session starts already oriented.
You don't have to write it by hand. From inside a session, run:
/init
Claude scans the current folder and generates a starter CLAUDE.md. If one already exists, treat /init as a refresh and then edit the result — it's a normal markdown file, so prune anything inaccurate and add the parts only you know.
One detail worth remembering from the docs: when you reference a file with @, Claude also pulls in the CLAUDE.md from that file's directory and its parents. So in a monorepo you can place a small CLAUDE.md next to a subpackage and it layers on top of the root one. That nesting is why keeping each CLAUDE.md short and accurate matters more than making one giant file.
Your first prompt should be a probe, not a project
The temptation on a fresh install is to type "refactor this whole codebase." Don't. You have no evidence yet that Claude has the right mental model, and a large write request on a wrong model is how you get a messy diff.
Start with a read-only probe instead. The docs' own first example is exactly this:
give me an overview of this codebase
Then narrow:
explain the main architecture patterns used here
what are the key data models?
how is authentication handled?
Read the answer as a diagnostic. Did it name the right framework? Did it find the real entry point, or hallucinate one? If something is off, correct it in the same turn — and then fold the correction back into CLAUDE.md so you don't repeat it next session. Once Claude's overview matches reality, every later request lands more accurately because it's reasoning from the right foundation.
This is the trial-and-error part nobody mentions: I've had sessions where the overview confidently described a src/api layer that had been deleted months ago, because a stale comment pointed there. Catching that in a free read-only question costs nothing. Catching it after a 12-file refactor costs an afternoon.
Permissions: understand the model before you loosen it
Claude Code can read files, write files, and run shell commands — and by default it asks before each sensitive action. As a beginner you'll see these approval prompts often, and the instinct is to make them stop. Resist that instinct on day one.
The right sequence is: keep the defaults, watch what it asks to do, and only then decide what's safe to pre-approve. When a tool is clearly harmless and you use it constantly, add it to your allowlist; the docs note you can simply ask Claude "how does Claude Code handle permissions?" and it will explain the current model for your version. There's also a stricter direction worth knowing about — plan mode — where Claude reads and proposes a plan but writes nothing until you approve:
claude --permission-mode plan
You can also toggle into it mid-session with Shift+Tab. I reach for plan mode whenever the request touches more than a couple of files, because reviewing a plan is cheaper than reviewing a diff.
| Setting | What it does | When a beginner should use it |
|---|---|---|
| Default (ask each time) | Prompts before sensitive writes/commands | Your first sessions — learn what Claude wants to do |
| Allowlist a tool | Stops prompting for one specific, safe action | After you've seen it ask repeatedly and trust it |
--permission-mode plan |
Reads and plans only; no edits until approved | Multi-file changes you want to review first |
| Broad auto-approve | Skips most prompts | Not yet — easy way to get an unintended edit |
The trade-off in that last row is the one to internalize: auto-approving widely removes the friction and the safety net at the same time. The friction is annoying precisely because it's the thing standing between you and an accidental write to the wrong file.
The myth that sessions are lost (they aren't)
A lot of beginner guidance — including the note this article expands on — claims Claude Code forgets everything when a session ends, so you can never continue tomorrow. That's not how the current tool behaves, and it's worth correcting because it changes your habits.
Per the official docs, conversations are saved locally and you can resume them:
claude --continue # resume the most recent session in this directory
claude --resume # pick from a list of past sessions
You can also run /resume from inside a live session. If there's nothing to continue, --continue prints No conversation found to continue and exits — so it fails safe. There's even claude --from-pr <number> to jump back into the session linked to a PR you created with gh pr create.
So the accurate guidance is: you can pick up where you left off. But you still shouldn't rely on chat history as your source of truth. Durable decisions — architecture choices, conventions, "we do X not Y because Z" — belong in CLAUDE.md or code comments, because those survive across any session, machine, or teammate, while a local chat log doesn't travel. Manage context explicitly; treat resume as a convenience, not a memory system.
This checklist turns Claude Code into visible pass/fail points, but the evidence in the article remains the source of truth.
Worked example: reproduce it on a small input
Here's the whole routine on a throwaay project so you can run it end to end.
Scenario: a small Node project you just cloned and want Claude oriented on.
Input — the commands:
cd ~/code/widget-api
claude
Then, inside the session:
/init
give me an overview of this codebase
Command/config produced: /init writes a CLAUDE.md at the repo root. A minimal one looks like:
# widget-api
Express REST API for widget inventory.
## Commands
- `npm run dev` — start local server on :3000
- `npm test` — run Jest suite
## Conventions
- Routes in `src/routes/`, one file per resource
- All DB access goes through `src/db/index.js`
Expected output: Claude's overview should name Express, point to src/routes/, and reference the commands from CLAUDE.md rather than guessing them.
Common failure: you launched from ~/code instead of ~/code/widget-api, so Claude describes the parent folder's many projects and the overview is vague. Fix: /exit, cd into the actual project root, relaunch.
How to verify: ask one targeted follow-up whose answer you already know — e.g. what command starts the dev server? If it answers npm run dev (from your CLAUDE.md) rather than inventing node index.js, your context is wired correctly. This is verification by reproduction, not a benchmark — no timing claims here, just a checkable fact.
Knowing how to leave
A small thing that trips up first-timers: getting out. Exit the interactive shell with /exit, or press Ctrl+C twice. Trivial once you know it, genuinely confusing when you don't and the prompt won't take a normal command.
FAQ
When should I use Claude Code?
Use it inside a real project directory when you want help understanding, editing, or running that codebase — code exploration, bug fixes, refactors, tests, PRs, and even non-code markdown folders all work. It's directory-scoped, so the value comes from launching it in the project, not from a generic chat window.
What should I check before applying Claude Code in production?
Confirm three things: you're in the correct working directory, CLAUDE.md reflects reality, and the permission posture matches the risk. For anything touching multiple files or shared branches, start in --permission-mode plan so you approve a plan before any edit hits disk, and prefer worktrees (claude --worktree <name>) when running parallel sessions so edits don't collide.
What is the easiest way to verify the result?
Ask a small read-only question whose answer you can independently confirm (a known command, a known file path). If Claude's answer matches your ground truth, its context is correct. Treat that probe as the gate before you let it write anything.
Sources and checks
Verified on: 2026-06-18
| Claim | Evidence | How to verify | Limit |
|---|---|---|---|
| Claude Code should be checked against the original source before reuse. | code.claude.com | Check the source page, version, date, and setup notes. | Source content can change after this article is published. |
| Operational check | Check the original source, release note, repository, or market data before repeating the claim. | Reproduce on a small input and record input, output, and environment. | A local test does not prove every production path. |
| Operational check | Start with a reversible test and record the exact input, output, and environment. | Reproduce on a small input and record input, output, and environment. | A local test does not prove every production path. |
| Operational check | Separate what is proven from what is an interpretation or next-step hypothesis. | Reproduce on a small input and record input, output, and environment. | A local test does not prove every production path. |
🐦 Faster updates on X: @baegseungh7061
📚 More in this series: Code Intro
💌 Subscribe: Follow on X or grab the RSS
댓글
댓글 쓰기