|

Claude Code for Beginners: A Complete Getting Started Guide

I’m a software developer, and even I put off setting up Claude Code for longer than I should have. It lived in that mental category of “looks useful, seems like work to figure out.” It was not work to figure out. Installation takes about five minutes, and the first time it actually did something useful I kicked myself for waiting.

This is the guide I wish I had when I started. No fluff, no skipping steps, real examples you can copy and run.

What Claude Code Actually Is

Claude Code is Anthropic’s terminal-based AI coding tool. The key word is terminal. It’s not a plugin that sits in your editor making autocomplete suggestions. It runs in your terminal, reads your actual files, and can make real changes to your codebase with your approval. You describe what you want in plain English, it figures out which files to touch, shows you exactly what it’s going to do, and waits for you to approve before changing anything.

That last part matters. Claude Code asks before it acts. You’re never in a situation where it silently rewrote half your project while you weren’t looking. Every file edit, every command it wants to run, comes with a confirmation prompt. You stay in control throughout.

It also works across VS Code, JetBrains, and a desktop app if you’d rather not live in the terminal. But the terminal is where it’s most powerful, and that’s what this guide covers.

What You Need Before You Start

Two things: a paid Claude account and a terminal. The free Claude.ai plan doesn’t include Claude Code access. You need at least a Pro plan ($20/month), which is enough for learning and regular use. If you’re already paying for Claude, you already have access. Just open your terminal and follow the steps below.

On the terminal front: Mac and Linux users already have one. On Windows, you’ll want to install Git for Windows first, which gives you Git Bash, or use PowerShell. Claude Code runs on all three.

Step 1: Install Claude Code

The recommended installation method is the native installer. Run the command for your operating system.

macOS or Linux:

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

Windows (PowerShell):

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

Once that finishes, verify the installation worked:

claude --version

If it returns a version number, you’re installed. If the command isn’t found, close your terminal completely and open a new one. That usually fixes it — your PATH needs to refresh after installation.

You can also install via Homebrew on Mac if you prefer:

brew install --cask claude-code

Note that Homebrew installations don’t auto-update, so you’d need to run brew upgrade claude-code manually to stay current. The native installer handles updates automatically.

Step 2: Authenticate

Navigate to a project folder in your terminal, then run:

claude

The first time you run this, it opens your browser and sends you to claude.ai to log in. Do that, come back to the terminal, and you’re authenticated. Your credentials are stored locally so you won’t have to log in every session.

After authentication, you’ll see the Claude Code welcome screen with your working directory and the model in use. That’s it. You’re in.

Step 3: Your First Session

Always launch Claude Code from the root of whatever project you want to work on. It reads your files from the directory you start it in.

cd /your/project/folder<br>claude

Once you’re in, start with this prompt to let Claude orient itself to your codebase before you ask it to do anything:

What does this project do? Give me a summary of the tech stack, the main entry points, and how the code is organized.

Claude will scan your files and come back with a structured breakdown. This takes thirty seconds and saves you a lot of back-and-forth later because it means Claude actually knows your project before you start asking it to modify things.

How to Write Good Prompts

The quality of what Claude Code produces is directly proportional to how clearly you describe what you want. Vague prompts get vague results. Specific prompts with context get working code.

Here’s the difference in practice. A vague prompt:

Add input validation to the signup form.

A specific prompt that will get you a better result:

Add input validation to the signup form in src/components/SignupForm.tsx. Email should be validated with a regex check. Password needs at least 8 characters, one uppercase letter, and one number. Show inline error messages below each field when validation fails. Don't change the existing styling.

Same request. Completely different output. The second one tells Claude exactly which file, exactly what the rules are, exactly how errors should appear, and explicitly what not to change. That’s the pattern that works.

When you hit an error, paste the actual error output into your prompt. Don’t describe the error. Show it:

I'm getting this error when I run npm run build:

TypeError: Cannot read properties of undefined (reading 'map') at UserList (src/components/UserList.tsx:24:18)

The component is trying to map over users but something is undefined. Fix it.

Claude will find the file, read the component, understand why the error is happening, and propose a fix. Much faster than staring at the error yourself.

Real Examples to Try

Here are prompts that work well for common tasks. Copy them, adapt them to your project, and see what comes back.

Understand unfamiliar code:

Explain what the function in src/utils/dataTransform.js does, what arguments it expects, what it returns, and when I would use it. Include an example.

Write tests for existing code:

Write Jest tests for the calculateShipping function in src/utils/shipping.js. Cover the happy path, edge cases (zero weight, maximum weight), and what happens when an invalid region is passed. Place the test file at src/utils/shipping.test.js.

Build a small utility script:

Write a Node.js script that reads all .csv files in a given directory, combines them into a single file, removes duplicate rows based on the first column, and saves the output as combined.csv in the same directory. Include error handling for missing directories and malformed files.

Do a code review:

Review the code in src/api/userController.js. Look for bugs, security issues, edge cases that aren't handled, and anything that doesn't follow REST best practices. Be specific about what's wrong and suggest fixes for each issue you find.

Refactor something specific:

The fetchUserData function in src/hooks/useUser.ts is doing too many things. Refactor it to separate the API call, the data transformation, and the error handling into distinct functions. Keep the public interface the same so nothing that calls it breaks.

Generate documentation:

Write a README.md for this project. Include what it does, how to install it, how to run it locally, how to run the tests, and the environment variables it needs. Look at the existing code to find accurate values rather than making anything up.

Plan Mode: For Bigger Tasks

For anything that involves multiple files or a non-trivial amount of changes, use Plan Mode before letting Claude start editing. It makes Claude reason through the approach first, show you its plan, and wait for your approval before touching a single file.

Trigger it by adding “think through this” or “plan this out first” to your prompt:

I want to add role-based access control to this app. There should be three roles: admin, editor, and viewer, each with different permissions for the dashboard routes. Think through what needs to change across the codebase before making any edits and show me the plan first.

Claude will come back with a structured plan showing which files it intends to touch and what it’s going to do to each one. You review it, push back on anything that looks wrong, and only then tell it to proceed. For anything consequential, this step is worth doing. It catches misunderstandings before they become actual changes you have to undo.

The CLAUDE.md File: Make Claude Remember Your Project

Every session with Claude Code starts fresh. It doesn’t remember what you told it last time. The CLAUDE.md file fixes that. It’s a text file that lives in your project root and gets loaded into every Claude Code session automatically. Whatever you put in it, Claude knows from the moment you start.

Generate a starter one by running this inside Claude Code:

/init

Claude will scan your project and write a CLAUDE.md based on what it finds. Then edit it to add anything it missed. Here’s an example of what a useful CLAUDE.md looks like:

# Project Context

React frontend, Node/Express backend, PostgreSQL with Prisma.

## Commands
- `npm run dev` — start dev server
- `npm run test` — run tests
- `npm run build` — production build

## Coding Standards
- TypeScript for all new code, no `any` types
- Functional components only, no class components
- Write tests before implementing new functions
- Use the logger at `src/utils/logger.ts`, never console.log

## File Structure
- Components: `src/components/`
- Hooks: `src/hooks/`
- Tests: alongside source files with `.test.ts` extension

## What Not to Touch
- Do not modify anything in `src/legacy/` without asking first
- Do not install new packages without confirming

Commit this file to your repo. Everyone on the team gets the same Claude behavior, the same conventions enforced, the same context loaded from session one.

Useful Commands to Know

You don’t need to memorize these. But knowing they exist saves you time when you need them.

/clear        # Reset the conversation history without leaving the session

/help         # Show available slash commands

/status       # See your current usage and session info

/init         # Generate a CLAUDE.md for your project

/add-dir path # Add another directory to Claude's working context

You can also reference files directly in your prompts using @ mentions:

Look at @src/components/Header.tsx and @src/styles/header.css and clean up the CSS so unused styles are removed.

This tells Claude exactly which files you’re talking about instead of making it guess.

Common Beginner Mistakes

Starting without context. Jumping straight into “fix this bug” without letting Claude orient itself first. Run the project summary prompt at the start of every session, especially in a new codebase.

Prompts that are too vague. “Make this better” is not a prompt. Better at what? Performance? Readability? Error handling? Be specific about what problem you’re actually solving.

Not using Plan Mode for big changes. If a task touches more than a couple of files, always ask Claude to plan first. The thirty seconds it takes to review the plan is worth it compared to the ten minutes it takes to undo a misunderstood change.

Skipping the CLAUDE.md. If you find yourself re-explaining your stack, your conventions, or your file structure at the start of every session, that information belongs in CLAUDE.md. You should only have to say it once.

Where to Go From Here

The best way to get comfortable with Claude Code is to pick one small task in a project you know well and run it through. Not a proof of concept, something real. A bug that’s been sitting on your backlog, a test file that needs to be written, a function that’s overdue for a refactor. Something with a clear definition of done.

Run the project summary prompt first. Write a specific prompt with context. Review what Claude proposes. Approve it or push back. That loop is the whole thing. Everything else, the CLAUDE.md, the Plan Mode, the custom commands, builds from there once you know what you’re doing and what you want more of.

It’s not a complicated tool. It just takes one real session to click.

Take what’s useful. Leave the rest.