How to Use Claude Code: The Setup Under Every Session

To use Claude Code, install it, open it inside a project folder, and describe the outcome you want in plain English. It reads the files itself, proposes the edits, and applies them once you approve. That is the first ten minutes.

The part that decides whether you are still using it in a month is what you configure afterwards. A project instructions file, a few skills, an output style, a hook or two, a model choice. Those live with your setup rather than in a conversation, so the next session starts where the last one finished instead of starting from nothing. This post covers both: the first session, then the setup layer underneath it.

Key Takeaways

• Claude Code works on outcomes, not files. Describe what should be true when it finishes and let it find the files.
• The first session needs four decisions: where you open it, what you ask it for, how much it can do without asking, and when you clear it.
• The configuration you write once is what makes the sessions after it good, and future sessions pick it up on their own.
• The pieces are one system, not a checklist. Project instructions say what is true here, skills say how work gets done, an output style sets how answers come back, hooks enforce what must not slip, and the model sets what it draws from your allowance.
• Model and effort choice is the biggest lever on how long your usage allowance lasts, and it takes about a minute to change.

Claude Code changes quickly. Treat the exact command names below as current at the time of writing, and the behavior behind them as the durable part.

In a hurry? Jump to your first session for the four decisions that matter on day one.

What Is Claude Code, and How Is It Different From a Chat Window?

Claude Code is Anthropic's coding tool. It reads the real files in a project, edits them, runs commands, and works through a task over many steps rather than answering one question at a time. It runs in the terminal, in editor extensions, in a desktop app and on the web, and the terminal is where most people meet it.

How is Claude Code different from a chat window?

A chat window hands you an answer. Claude Code changes the project.

That third row is the one that changes how you work. You stop being the courier between the model and your files.

What do you need before you start?

Three things. A place to run it, most often the terminal, a Claude account on a plan that includes Claude Code, and a project folder with something in it. You do not need a new project. Pointing it at work that already exists is the better first test, because it has to read before it can write.

How to Use Claude Code in Your First Session

Four decisions carry the first session. None of them takes longer than a minute, and getting them right is most of the difference between a tool you keep and one you close after an afternoon.

Step 1: Open it inside the project folder, not above it

Move into the folder you actually want to work on (cd path/to/project) and start it there with claude. Claude Code takes its bearings from where it starts: that folder is what it reads, and that is where its configuration will live. Started one level up, it sees a directory of directories and spends its first turns working out which one you meant. If it is not installed yet, start with the official quickstart.

Step 2: Ask for an outcome, not a file

Naming a file and asking for an edit is the habit that carries over from chat. Claude Code works a level above that: say what should be true when it is finished.

The signup form accepts an email with no @ in it. Find where that check
should live, fix it, and add a test that fails without the fix.

That prompt names no file. It gives a symptom, a boundary, and a definition of done, which is enough for it to go and find the rest. I write prompts for it the same way I would write a brief for a person, which is the same habit behind better AI prompts anywhere else.

Step 3: Know which permission mode you are in

Permission mode sets what Claude Code can do without stopping to ask you. This is the setting most worth understanding on day one.

Your very first session after installing starts in Manual mode, where it asks before most actions that edit files, run commands, or reach the network. In the terminal and the VS Code extension, sessions after that start in auto mode on the Pro, Max and Team plans, where a second model reviews the actions rather than you. The desktop app and the web carry their own starting mode, shown in their mode selector. Shift+Tab cycles through the modes at any point, including mid task, and plan mode is one of the stops: it reads and proposes without changing anything, which makes it the one to reach for on work you are not ready to hand over. Defaults shift between versions, so trust what your own session reports over any written snapshot.

The useful habit is to choose deliberately rather than inherit. Switching to Manual for the first few real tasks is how you learn what it reaches for, and that is the judgment you need later to review work you did not watch it do. Permission mode is also one of the three Claude Code settings I change on a fresh install.

Step 4: Clear the session when the task changes

A session accumulates everything it has read. That history is what makes it good at a long task and what makes it worse at the next, unrelated one, because it is still carrying the last problem while you describe a new one.

Clearing between tasks is the cheapest habit in this post. /clear empties the context, and the next task starts clean.

The Setup Layer: What You Configure Once

Everything above is how a session runs. This is the part that decides how good the next hundred sessions are, and it is where the time goes furthest.

Five pieces sit underneath every session you open in a project: project instructions, skills, an output style, hooks, and the model you point it at. Each one is small on its own, which is why they read as five optional extras. Taken together they answer what is true here, how work gets done here, how the answers come back, what must never slip, and what all of it draws from your allowance.

None of this belongs on day one. Each piece is worth adding at the moment you feel the problem it solves, and the last of the five, model and effort, gets its own section below because it is where the allowance actually goes. If you would rather see a setup like this assembled and running before building your own, that is the ground the AI workshop covers live.

Sessions are the temporary part. The slab underneath is what you write once.

What goes in a project instructions file?

A project instructions file, named CLAUDE.md, is a markdown file in the project that Claude Code reads at the start of every session. It carries the things the code cannot tell it: the conventions you hold to, the commands that have to run before a change is finished, the parts of the system that are more fragile than they look.

Keep it to what is genuinely not derivable. Restating the folder structure wastes the space, because it can read the folder structure. Naming the one directory that looks disposable and is not, that earns its lines.

What is a skill, and when does Claude use one?

A skill is a written procedure for a kind of work, saved as a SKILL.md file that Claude Code loads when the work matches. A deployment checklist, a review standard, the steps for adding a new page. Each one gets its own folder: .claude/skills/<name>/SKILL.md in the project when it belongs to that codebase, or ~/.claude/skills/<name>/SKILL.md when it should follow you everywhere.

You write it once, in prose, and it is the same procedure every time it loads, instead of being re explained in every session. Loading is the part to watch: a skill fires when the work looks like a match, so the description at the top of the file is doing more work than the procedure underneath it.

Across four months of daily use, the skills that ran most were not the ones that write code. The skills that decide what to build, or work out what broke, ran roughly three times as often as the building ones combined. I installed the superpowers plugin for its building skills and got most of the value from its thinking ones.

That has a practical consequence. The first skill worth writing is not a code generator. It is the one that captures how you want a problem approached before any code gets written.

How does an output style change how it talks to you?

An output style sets the register of the replies: length, format, how much explanation comes with an answer. It is a small file, and it changes every message you read after you write it.

Mine strips the preamble and puts any question I need to answer on its own line. That sounds cosmetic. It is the difference between reading a session and skimming one, and writing your own output style takes about ten minutes.

What does a hook do?

A hook runs automatically at a fixed point in a session, for instance before a file is written, and it can block what was about to happen. Where an instruction asks Claude Code to remember a rule, a hook enforces it whether or not anything remembered.

The one I run checks writing against a list of phrases I do not want in anything published, and blocks the write when it finds one. The rule sat in my instructions file long before it was in a hook, and there it was read every session and followed in most of them.

Use them for the rules where being followed most of the time is not good enough.

Do you need MCP servers?

MCP servers connect Claude Code to systems outside your project: a drive, a mail account, a design tool. This is the sixth piece rather than one of the five, and it is the one I reached for earliest and needed least.

From auditing my own setup: the two tools I reach for most in a session were never MCP servers at all. They are ordinary command line programs that Claude Code can already run, because anything with a command line is already reachable. The first question to ask before connecting anything is whether it does something the command line cannot, which ruled out most of the MCP servers I had running. The fair counterweight is that a server can still earn its place on a hosted service behind a login, or where a command line tool is reachable but fiddly enough that a session keeps rediscovering how to drive it.

Which Model and Effort Level to Run

Model choice is where your usage allowance actually goes. Two dials, and they interact.

Which Claude model should you run?

The larger model is not automatically the right default. Most day to day work runs fine on the mid tier model, and the difference shows up on genuinely hard problems rather than on ordinary ones, so it pays to know in advance when Sonnet wins.

What does reasoning effort change?

Reasoning effort sets how much thinking the model does before it answers, and /effort is where you change it, or you can set it inside /model. High effort earns its cost on hard multi file work. On mechanical work it buys very little and spends a lot.

I run low or medium most of the time, and my usage limits move meaningfully slower for it than they did when everything ran high. The measured figures are in the Opus prompting post, along with the instructions worth deleting now that current models check their own work unprompted. Delete the ones asking for a second look at reasoning. Keep the ones that name a real check, like running the tests or opening the page, because those rest on something outside the model.

How do you make a usage limit last longer?

Effort is the first dial to try, because it is free and reversible. After that, the pattern that helps most is running the cheaper model as your default and calling the expensive one only at the decisions that need it, which is the advisor pattern.

What Daily Use Actually Looks Like

The setup above is what makes the sessions good. These are the habits that let it keep paying off.

How do you keep a long session from drifting?

Watch the context, not the clock. As a session fills up, its answers get shakier in a way that looks like the model getting worse and is really the session getting crowded. /context shows what is taking up the room, and the status line can show it continuously. Start fresh with /clear, or a new session, before it fills rather than after. When two sessions need to work on the same thing, cross session messaging lets them hand context over without going through you.

If you would rather see your own habits than guess at them, Claude Code insights reports them back to you.

What should you not hand it yet?

Work where you cannot tell whether the output is right. Claude Code is at its strongest where a result can be checked, by a test, by a run, by looking at the thing it produced. Where checking is expensive or impossible, you are trusting an answer rather than verifying one, and that is where the time goes back in.

Start it on work you could have done yourself but would rather not. That is where it is easiest to see whether it did the job.