Claude Code: The Complete Setup Guide Nobody Wrote

This is the hands-on companion to my previous article. If you want the backstory on why coding agents matter and how I got over my fear of using them, start there. If you're already sold and just want to get Claude Code running, you're in the right place. Here's everything you need from installation to the habits that keep you sharp.

Getting Claude Code on Your Machine

There are four things you need: a Claude account, the right plan, the tool installed, and your account authenticated. Here's how to get through all of it.

Step 1 — Create a Claude account

Go to claude.ai and sign up. The free plan gets you Claude in the browser, which is useful on its own, but Claude Code runs in your terminal and needs a paid plan.

Step 2 — Get the Pro plan

Claude Code is available on the Pro plan at $20/month (check https://claude.com/pricing for the latest pricing). For most developers, Pro is enough to work with daily. But if you're hitting rate limits often, there are higher plans available. My suggestion: start with Pro and see how far it gets you.

If you're setting this up for a team, Team and Enterprise plans include Claude Code with shared billing and admin controls.

Step 3 — Install Claude Code

The recommended way to install is the native installer — it requires no extra dependencies, auto-updates itself in the background, and is what Anthropic officially recommends. Skip the npm method if you've seen it in older articles; it has been deprecated.

macOS / Linux - open your terminal and run:

curl -fsSL https://claude.ai/install.sh | bash

Windows - open PowerShell and run:

irm https://claude.ai/install.ps1 | iex

Windows needs Git for Windows installed. Once that's done, you can run Claude from PowerShell, CMD, or Git Bash, whichever you prefer.

If anything goes sideways during install, the official docs have an advanced setup section. Check it out here.

Step 4 — Log in and authenticate

Once installation is done, just run claude in your terminal:

claude

The first time you run it, a browser window opens and asks you to log in to your Anthropic account. Do that, come back to the terminal, and you're connected. That's the one-time setup done.

If you use VS Code, you don't need a separate terminal window. Open the integrated terminal, navigate to your project folder, and run claude from right there. Everything works the same way.

Getting Claude into Your Project

Now that Claude Code is installed, navigate to whatever project you want to work in and start a session:

cd my-project
claude

You'll see a prompt waiting for input. Before you type anything else, do this one thing first.

Run /init - this matters more than it sounds

Type /init and hit enter:

/init

This tells Claude to walk through your entire codebase and build a picture of it - your folder structure, the frameworks you're using, naming conventions, and where the important files live. How long it takes depends on your project size. A small repo might take under a minute, a large one could take a few. Either way, it means Claude isn't going in blind when you start asking it things.

Think of it like a new hire spending their first hour reading all the internal docs before touching any code, except it actually remembers everything.

After /init finishes, it creates a file called CLAUDE.md at your project root. This file is Claude's persistent memory for your project, and it's something we're going to come back to.

Note that you only need to run this once per project, the first time you introduce Claude to it.

Teaching Claude Your Rules

Here's something most people don't figure out until later: Claude Code doesn't just respond to what you type in the moment. It also reads a set of memory files that carry your instructions across every session. These are called CLAUDE.md files.

There are three of them, each with a different scope:

You don't need to open and edit these files manually. Inside a Claude Code session, just start a message with # , and Claude writes it to your CLAUDE.md automatically:

# Always use async/await — never .then() chains
# Use comments only on complex or non-obvious code
# When writing tests, use Vitest with React Testing Library

Think of CLAUDE.md as the onboarding doc you'd hand to a new developer joining your team. The things you'd want them to know before writing their first line of code - put those here. Claude reads it at the start of every session.

Pointing Claude at Specific Files

When you want Claude to look at something in particular, use @ followed by the file path. This pulls the file's full contents into your request without you having to copy-paste anything:

There's a bug in @lib/auth/token.ts — the JWT isn't expiring right. Can you find it?

Add a paginated list endpoint to @src/routes/users.ts

You can also put @ file references inside your CLAUDE.md so certain files are always in context without you needing to mention them:

# In CLAUDE.md
The database schema lives in @prisma/schema.prisma - reference it
whenever you need to understand the data structure.

One more thing: for UI bugs, you can paste a screenshot directly into Claude Code. On most systems, this is Ctrl+V - though on Mac, depending on your terminal, you may need Cmd+V instead. Try both and see which one your setup responds to. Either way, it's much faster than trying to describe a layout issue in words.

Planning and Thinking - For When Things Get Complicated

Planning Mode

When a task is going to touch multiple files - a refactor, a new feature, something where a mistake halfway through causes real pain - you want Claude to plan before it acts. Enable Planning Mode by pressing Shift + Tab twice.

In Planning Mode, Claude reads broadly across your codebase, draws up a step-by-step plan, shows you exactly what it intends to change, and waits for you to say go. Nothing moves until you approve it.

I use this for anything that touches more than two or three files. It takes an extra minute, but you avoid the situation where Claude is halfway through a change, and you realize it completely misunderstood what you wanted.

Thinking Mode

For problems where the logic itself is the hard part, a bug you can't trace, an algorithm that doesn't work, a piece of architecture that needs real thought, ask Claude to think harder by prefacing your message:

Ultrathink: why is this recursive function hitting a stack overflow for inputs over 10,000?

Use Planning Mode when the task spans many files. Use Thinking Mode when the logic is what's hard. You can combine them, just know they both cost more tokens.

Steering the Conversation

Half of using Claude Code well is knowing how to steer it, not just what to ask, but when to interrupt, when to rewind, and when to start fresh.

Press Escape to stop Claude mid-task. If it heads in the wrong direction or starts doing way more than you asked, just hit Escape and redirect. Combine this with # to fix recurring mistakes, stop it, add a rule to CLAUDE.md, and it won't repeat the same error in future sessions.

Press Escape twice to rewind. This shows your full message history and lets you jump back to an earlier point in the conversation. Useful when a long debugging session has cluttered things up, but you want to keep the context Claude has built.

/compact and /clear for long sessions:

/compact   # Summarise the conversation but keep the important context
/clear     # Wipe everything — fresh start for a new unrelated task

/compact is like writing a meeting summary before the next meeting. /clear is like opening a new notebook.

Custom Commands - Automate What You Do Every Session

This is where things get genuinely fun. You can create your own slash commands for tasks you run repeatedly.

Inside your project, find the .claude folder. Create a commands/ directory inside it. Then create a markdown file. The filename becomes the command name. audit.md becomes /audit.

Example - /audit command:

Create .claude/commands/audit.md:

Run a dependency audit on the project:
1. Run npm audit to identify vulnerable packages
2. Run npm audit fix to apply safe updates
3. Run the test suite to confirm nothing broke
Report what was fixed and flag anything that needs manual review.

Now /audit runs that whole workflow with one command.

Commands that take input:

Use $ARGUMENTS to make commands flexible. Create .claude/commands/write_tests.md:

Write comprehensive tests for: $ARGUMENTS

Conventions:
- Use Vitest with React Testing Library
- Place tests in a __tests__ folder next to the source file
- Cover happy paths, edge cases, and error states
- Explain why you're testing each scenario

Then use it like this:

/write_tests the useAuth hook in src/hooks

Restart Claude Code after creating a new command. It needs a fresh session to pick it up.

Claude as a Git and GitHub Assistant

On the git side, you can ask Claude to stage files, write commit messages based on what actually changed, and draft PR descriptions, all from the terminal. Very handy after a long session when you don't want to think about commit hygiene:

Stage the changes in src/api and write a conventional commit message.

For teams, the GitHub integration lets you mention @claude in any issue or PR comment. Claude reads the code, plans the task, implements it, and posts back the result, without you leaving GitHub.

There's also a Pull Request Action you can set up that automatically reviews every new PR and posts an analysis before a human looks at it.

Hooks let you run commands before or after Claude takes action. For example, you can set a hook to auto-format a file after it's edited, run your test suite whenever something changes, or block Claude from touching certain directories entirely. It's the thing that turns Claude Code from a smart assistant into an actual workflow you can trust.

Tips That Keep You Sharp While Using Claude Code

OK, this is the section I actually wanted to read when I was getting started. The commands are one thing, but nobody talks about how to stay a good developer while using one of these tools. Here's what I've learned.

Treat it as a peer coder, not your brain

The biggest mistake I made early on was letting Claude make decisions without critically engaging. Fast output is not the same as good output. I now treat it like a talented colleague I trust, but also fact-check. I discuss before I implement. I try to read the code it produces. If I couldn't explain the code to someone else, I would ask Claude to explain it to me before we proceed:

Before you write anything, walk me through the approach you'd take
and why. I want to understand the tradeoffs first.

This catches bad plans early. More importantly, it keeps your brain in the loop.

Use planning and thinking modes for real

I mentioned these in the features section, but I'm repeating it here as a habit because it changes how you work. Don't let Claude immediately start editing files on complex tasks. Make it plan first. Make it think harder when the problem is hard. These aren't optional bells and whistles; they're how you stay in control.

Build in small chunks

Describing your whole project and asking Claude to build it is the fast track to a codebase you don't understand and can't maintain. I work per feature, per module, per endpoint. I describe the full picture for context, then say "let's start with just the data model." Review. Move to the service layer. Review. Route. Tests. Each step is something I can actually read and understand.

Ask it to write tests - especially the edge cases

Claude is genuinely good at tests, and it thinks of edge cases you would miss until they hit production. After building anything, I ask for a full test suite:

Write tests for this including edge cases, invalid inputs,
and failure states. Explain why you're testing each one.

Read every test it writes. Each one is a specification for how your code is supposed to behave. If one surprises you, that's useful information.

Build security in from the start

Developers push security to "later" constantly. Don't do that here. As you build each feature, ask Claude to flag issues before you move on:

Before we finish this endpoint, are there any security
vulnerabilities or missing protections I should know about?

Input validation, auth gaps, data exposure, injection vectors, these are all much cheaper to fix during development than after something goes wrong.

Always verify the tools and libraries it introduces

Claude will sometimes suggest packages, SDKs, or functions you haven't seen before. Sometimes these are great. Occasionally, it recommends something outdated or hallucinates a library that sounds real but doesn't exist. Any time it introduces something unfamiliar:

You mentioned [library/function]. Can you explain what it does,
why you picked it over alternatives, and where the docs are?

Then go look it up yourself. Check npm. Read the README. Make sure it's actively maintained and actually does what Claude says.

Audit your integrations periodically

Third-party integrations like payment processors, auth providers, webhooks, and external APIs are where most real-world security problems live. Don't implement them and never look at them again. Every few months, ask Claude to audit your integrations: are API keys scoped correctly, are webhooks validated, is anything sensitive being logged somewhere it shouldn't be? An integration that was fine at launch can quietly become a liability as your app grows around it.

The Full Command Cheat Sheet

Here's everything in one place. Bookmark it.

Save this for later. Right-click the image above to download the full-size version.

Final Thoughts

Getting Claude Code running is the easy part. What actually determines whether it makes you better or just faster is everything that comes after the setup.

The commands in this guide give you the mechanics. But the habit that ties them together is simpler than any command: stay in the conversation. Read the code it produces. Question the approach before it starts writing. Ask it to explain things that surprise you. Redirect it when the plan isn't right.

Claude Code works best when you treat it like a brilliant collaborator who has read every file in your project but still needs you to make the calls that matter. The architectural decisions, the judgment calls, the moments where you catch something that feels off, those still belong to you. That's not a limitation of the tool. That's the job.

The developers who get the most out of this aren't the fastest ones. They're the ones who stayed curious enough to ask why, not just accept what was compiled.

Start with /init. Add one rule with #. Try @ on your next bug. The rest follows from there.

Happy building.