Getting Started with Claude Code: Setup, Slash Commands, Making Changes, and Image Context

A practical walkthrough of the four things you need to know before writing your first real line of AI-assisted code.

Most tutorials about Claude Code start with “install it and run it.” That’s fine for a five-minute demo. But if you actually want to use it on real work the kind that ships, you need to understand four things before you write a single prompt.

This article walks through each one: setting up correctly, using slash commands to stop repeating yourself, making code changes with intention, and adding image context to give Claude the full picture of what you’re building.

Part 1: Setup

Installing Claude Code

Claude Code runs as a command-line tool. You install it globally via npm:

npm install -g @anthropic-ai/claude-code

Once installed, navigate to your project directory and start a session:

cd your-project
claude

That’s the technical part. The more important part is what you do before you start prompting.

Set up your project context before anything else

The single most valuable thing you can do at setup time is create a CLAUDE.md file in your project root. This file gets read by Claude at the start of every session. It's your project's persistent memory — the place where you document what Claude needs to know about your codebase, your conventions, and your preferences.

A minimal CLAUDE.md might look like this:

## Project overview
E-commerce backend API built with Node.js and PostgreSQL.
Auth handled via JWT tokens. All routes require authentication except /health.

## Tech stack
- Runtime: Node.js 20
- Database: PostgreSQL with Drizzle ORM
- Testing: Vitest
- Linting: ESLint with Airbnb config

## Conventions
- Use async/await, never callbacks
- All database queries go through the /db layer, never inline SQL
- Error handling: always throw typed errors from /errors/index.ts

## Do not
- Install new dependencies without asking
- Modify migration files that have already been run

Without CLAUDE.md, every session starts cold. Claude doesn't know your stack, your conventions, or what's off limits. With it, every session starts informed — and you spend your tokens on actual work instead of re-explaining your project from scratch.

We’ll cover CLAUDE.md in much greater depth in the next article in this series. For now: create it, fill it in with the basics, and get in the habit of updating it when something important changes.

Understanding the interface

When Claude Code starts, you get a terminal-style chat interface. A few things worth knowing immediately:

• Files are not automatically in context. You have to add them explicitly. Use @filename to include a file in your prompt, or use the /add command.
• The context window is finite. Everything you add — files, conversation history, outputs — counts toward the limit. We’ll discuss managing this carefully in the next article.
• Claude Code has tools. It can read files, run shell commands, edit code, search your codebase, and more. These tools execute in your actual environment. That’s powerful and requires some care — we’ll get to that.

Part 2: Slash Commands

What are slash commands?

Slash commands are shortcuts built into Claude Code. Type / and you'll see a list. They handle common tasks without requiring you to write a full prompt every time.

The most useful built-in ones:

**/help** — Lists all available commands. Worth running once when you start.

**/clear** — Clears the current conversation context. Use this when you're switching to a different task and want a clean slate, or when the context is getting long and cluttered.

**/compact** — Compresses the conversation history into a summary. Unlike /clear, it preserves a sense of what happened — useful when you want to continue the same work but need to free up context window space.

**/add** — Adds files to the current context. Example: /add src/auth/middleware.ts. You can add multiple files at once.

**/status** — Shows what's currently in context: which files are loaded, how much of the context window is used. Get in the habit of checking this regularly.

**/undo** — Rolls back the last code change Claude made. Your safety net when something goes wrong.

Why slash commands matter more than they seem

The biggest waste in most people’s Claude Code sessions is repetition. They write the same setup instructions at the start of every conversation. They re-add the same files. They re-explain the same constraints.

Slash commands — particularly custom ones, which we’ll cover in a later article — eliminate most of that. But even the built-in ones save meaningful time. The /clear and /compact commands in particular are habits worth developing early, because context management becomes more important the longer you work in a session.

Part 3: Making Code Changes

How Claude Code edits files

When you ask Claude Code to make a code change, it uses its built-in tools to read your file, generate the modified version, and write it back. This is not copy-paste — it edits your actual files directly.

This means two things:

1. Version control is non-negotiable. If you’re not using git, start now. Every Claude Code session should begin with a clean git state so you can diff, review, and roll back anything that goes wrong.
2. Review before you move on. Claude Code will tell you what it changed. Read it. Every time. The habit of accepting changes without reading them is exactly how vibe coding creeps back in.

A structured approach to requesting changes

The difference between a good change request and a vague one is specificity. Compare:

Vague: “Fix the login bug”

Specific: “The login endpoint at POST /auth/login is returning 500 when the user’s email doesn’t exist in the database. It should return 401 with the message ‘Invalid credentials’. The handler is in src/auth/routes.ts around line 47.”

The specific version gives Claude the location, the current behavior, the desired behavior, and the boundary of what should change. It produces a targeted edit. The vague version produces a guess.

One change at a time

This is the discipline most developers resist because it feels slower. It isn’t.

When you bundle multiple changes into one request — “fix the login bug, also add rate limiting, and update the error messages” — you get code that’s hard to review, hard to test, and hard to roll back if something goes wrong. The scope bleeds. Unexpected side effects compound.

One change, reviewed, committed. Then the next. This is the pace that produces maintainable code.

Using Plan Mode before big changes

For anything beyond a small, isolated fix, use Plan Mode before asking for code. Type:

Let's plan how to add rate limiting to the auth endpoints. 
Don't write any code yet — just outline the approach and what files we'll need to touch.

Review the plan. Push back if something looks wrong. Agree on the approach. Then say:

That looks right. Now implement it.

This one step — separating planning from implementation — produces dramatically more coherent code because Claude has reasoned through the architecture rather than jumping straight to the keyboard.

Part 4: Adding Image Context

Why image context matters

Claude Code can accept images as context alongside your prompts. This sounds like a small feature. In practice it changes how you work.

Here are the situations where it becomes indispensable:

Matching a UI design. If you’re building a component from a Figma export or a designer’s mockup, pasting the image and saying “build a React component that matches this” is dramatically faster than describing the layout in words — and far more accurate. Claude can see the spacing, the colors, the hierarchy.

Debugging a visual problem. “The layout breaks on mobile” is an underspecified problem. A screenshot of the broken layout is specific. Claude can look at it and identify what’s causing the issue.

Referencing a diagram or schema. If you have an architecture diagram, an ERD, or a flowchart that describes how something should work, including it as context means Claude can write code that reflects the actual design — not a guess about it.

Understanding error screenshots. Some errors are easier to understand visually — a browser console with a stack trace, a failing test output, a misconfigured UI. Drop the screenshot in as context.

How to add an image

In Claude Code’s terminal interface, you can reference image files using the @ syntax:

@screenshot.png Look at this broken mobile layout. The sidebar is overlapping the content area. 
What's causing it and how do I fix it?

You can also drag and drop images directly into the Claude Code interface if you’re using the desktop version.

For Figma designs, export your frame as a PNG and include it. For screenshots, grab them directly. For diagrams, export from whatever tool you’re using.

The right way to prompt with images

Images give Claude visual context, but your prompt still needs to tell Claude what to do with that context. A few patterns that work well:

For UI implementation:

@design-mockup.png 
Build a React component that matches this design exactly. 
Use Tailwind for styling. The component should be in src/components/HeroSection.tsx.

For debugging:

@console-error.png 
This error is happening when I click the Submit button on the checkout form. 
The form is in src/checkout/CheckoutForm.tsx. What's causing it?

For design matching:

@current-ui.png @figma-target.png
Here's what our component currently looks like (first image) and what it should look like (second image).
What CSS changes do I need to make to get from the current state to the target?

Notice the pattern: image first (as context), then a specific question or instruction. Don’t just drop an image — tell Claude what you want done with it.

Putting It All Together: A Typical Session

Here’s what a structured Claude Code session looks like when these four pieces are in place:

1. Start clean. Check git status — make sure you’re starting from a committed, clean state.

2. Start Claude Code. Your CLAUDE.md loads automatically. Claude knows your project.

3. Define the task clearly. Before prompting, know what you’re trying to accomplish and what “done” looks like.

4. Use Plan Mode for anything non-trivial. Plan first, then implement.

5. Add context intentionally. Use /add to bring in the specific files relevant to the task. If you have a design or screenshot, include it.

6. Make one change at a time. Review each change. Commit when you’re satisfied.

7. Manage context. Watch your context window. Use /compact when things get long. Use /clear when you switch to a different task.

8. End with a commit. Don’t leave sessions in an uncommitted state.

This isn’t the fastest way to start. It’s the fastest way to stay fast over time — because you’re building code you understand, in a codebase that stays comprehensible.

What’s Next

This is the foundation. With setup, slash commands, structured change-making, and image context in place, you have the basic toolkit.

The next article goes deeper into the part most developers underestimate: Context and Memory Management — how CLAUDE.md works in detail, how to use Claude Code Skills to encode reusable knowledge, and how SubAgents help you tackle work that's too large for a single context window.