Getting Started with Claude CLI
My first week with Anthropic's command-line interface for Claude, and why it's becoming my default way to work with AI.
I’ve been using ChatGPT and Copilot for over a year now. They’re fine. But last week I installed Claude CLI, and it’s changed how I think about AI-assisted development.
Here’s what I learned getting it set up and running.
Why Claude CLI?
I’d been hearing about Claude CLI from a few developers I respect. The pitch wasn’t “it’s smarter” or “it writes better code”—it was “it understands context better.”
That sounded vague until I tried it.
The difference is that Claude CLI works directly in your terminal, in your project directory. It sees your files. It reads your codebase. When you ask it to help with something, it’s not working from a copy-pasted snippet in a chat window—it’s looking at the actual code.
This matters more than I expected.
Installation
Getting started is straightforward. I’m on Windows, so I opened PowerShell and ran the native installer:
irm https://claude.ai/install.ps1 | iex
This handles updates automatically in the background, which I prefer.
If you’d rather manage updates yourself, you can use WinGet instead:
winget install Anthropic.ClaudeCode
The WinGet version doesn’t auto-update, so you’ll need to run winget upgrade Anthropic.ClaudeCode periodically.
First run will prompt you to authenticate with your Anthropic account. If you don’t have one, you’ll need to sign up at anthropic.com. You can use a Claude Pro or Max subscription, or connect through the Claude Console with API billing.
Once authenticated, verify it’s working:
claude --version
You can also run claude doctor to check your installation and see useful diagnostic info.
First Session
I started simple. Navigated to a project I was working on and typed:
claude
This drops you into an interactive session. The first thing I noticed: it immediately understood where it was. I asked “what does this project do?” and it gave me an accurate summary based on reading the README, package.json, and a few key files.
No context window to manage. No “here’s my codebase” prompt engineering. It just figured it out.
Slash Commands
Claude CLI has built-in slash commands for common actions. The ones I use most:
| Command | What it does |
|---|---|
/model | Switch between Claude models (Sonnet, Opus, Haiku) |
/init | Initializes a new CLAUDE.md file for the project |
/context | Shows what’s currently loaded into context |
/status | Shows the current session status |
/compact | Compresses the conversation to save context space |
/clear | Clears the conversation and starts fresh |
/cost | Shows token usage and cost for the session |
The /config command is particularly useful. It lets you set things like your preferred model, auto-update channel (latest or stable), and various behavior settings without editing JSON files directly.
The Commands That Stuck
After a week of use, here are the patterns I keep coming back to:
Exploring Unfamiliar Code
What does the AuthService do and where is it used?
Claude finds the file, reads it, traces the imports, and explains both the implementation and the usage patterns. This is faster than grep and more useful than just reading the file myself.
Understanding Errors
When I hit a stack trace I don’t immediately understand, I paste it in:
I'm getting this error: [paste error]
What's causing it?
It reads the relevant files, correlates the line numbers with the code, and usually identifies the problem. Not always right, but right often enough to be useful.
Making Changes
Add a method to UserService that fetches a user by email instead of by ID
It finds the file, reads the existing patterns, and generates code that matches the style already in use. Then it asks if I want to apply the changes.
The key is that it asks first. I review the diff, say yes or no, and it applies or abandons the changes. No surprises.
Skills: Custom Slash Commands
This is where Claude CLI gets interesting. You can create custom slash commands called “skills” that extend what Claude can do.
Skills live in ~/.claude/skills/ for personal use or .claude/skills/ in your project for team-shared commands. Each skill is a folder with a SKILL.md file containing instructions.
Here’s a simple example. I created a skill for code reviews:
~/.claude/skills/review/SKILL.md
---
name: review
description: Review code for issues and improvements
---
Review the provided code for:
1. Potential bugs or edge cases
2. Performance concerns
3. Security issues
4. Code style and readability
Be specific about line numbers and provide concrete suggestions.
Now I can type /review src/auth/login.ts and Claude follows those instructions. The description field helps Claude know when to suggest using this skill automatically.
You can also set disable-model-invocation: true in the frontmatter if you only want the skill to run when you explicitly invoke it—useful for things like deploy scripts that have side effects.
Agents and Subagents
Claude CLI can spawn specialized agents for specific tasks. I haven’t used these extensively yet, but the concept is powerful: instead of handling everything in one conversation, Claude can delegate to focused agents.
The built-in agent types include:
- Explore: Read-only agent for researching codebases without making changes
- Plan: For designing implementation approaches before writing code
- general-purpose: The default, can do everything
You can also define custom agents in .claude/agents/ with specific tools and prompts. For example, a “code-reviewer” agent that only has read access and focuses on finding issues.
The --agents flag lets you define agents on the fly:
claude --agents '{"reviewer":{"description":"Reviews code","prompt":"You are a code reviewer focused on security"}}'
I’m still experimenting with this. The main value seems to be keeping different concerns separated and preventing scope creep in long sessions.
MCP: Connecting External Tools
MCP (Model Context Protocol) is how Claude CLI connects to external services. This is one of the deeper features I’m still learning, but the basics are straightforward.
To see what’s connected:
/mcp
To add a new server, you use the claude mcp add command. For example, connecting to GitHub:
claude mcp add --transport http github https://api.githubcopilot.com/mcp/
Or a local database:
claude mcp add --transport stdio db -- npx -y @bytebase/dbhub --dsn "postgresql://user:pass@localhost:5432/mydb"
Once connected, Claude can interact with these services directly. Ask it to “show me open PRs” or “query the users table” and it uses the MCP connection to get live data.
There are MCP servers for Sentry, Notion, Slack, various databases, and dozens of other tools. The MCP documentation has a registry of available servers.
The scope flag (--scope local, --scope project, or --scope user) controls where the configuration is stored and who can use it.
What Surprised Me
A few things I didn’t expect:
It remembers context within a session. If I ask about AuthService, then later say “how does that interact with the user model?”—it knows what “that” refers to. The conversation flows naturally.
It reads files on demand. I assumed it would try to load my entire codebase into context. It doesn’t. It reads what it needs, when it needs it. This makes it fast even on large projects.
It’s honest about uncertainty. When it’s not sure about something, it says so. “I don’t see a test file for this service” is more useful than a hallucinated test file that doesn’t exist.
Session management is solid. You can continue previous sessions with claude -c or resume a specific one with claude -r "session-name". Useful when you need to pick up where you left off.
My Workflow Now
I keep a terminal open with Claude running alongside my editor. When I hit a question—“what was that API format again?” or “how do we handle pagination here?”—I ask Claude instead of digging through files.
For actual coding, I still write most things myself. But when I need to understand existing code, trace through a system, or scaffold something repetitive, Claude handles it faster than I could.
It’s not replacing my editor. It’s replacing my “stare at the code trying to remember how this works” time.
The Learning Curve
There is one. A few things that tripped me up:
Be specific. “Fix the bug” doesn’t work. “The login function returns undefined when the user doesn’t exist—should it throw an error instead?” does.
Start from the right directory. Claude’s context is your current working directory. If you’re in a subdirectory, it might miss important files at the project root. I learned this the hard way.
Review the changes. Claude is confident. Sometimes too confident. Always read the diff before accepting changes. Most are fine, but catching the occasional mistake is worth the five seconds.
Use /compact in long sessions. The context window fills up. When Claude starts forgetting earlier parts of the conversation, /compact summarizes and frees up space.
CLI Flags Worth Knowing
A few command-line options I’ve found useful:
# Continue the most recent conversation
claude -c
# Resume a specific session by name
claude -r "auth-refactor"
# Start with an initial prompt
claude "explain this project"
# Use a specific model
claude --model opus
# Add extra directories to the context
claude --add-dir ../shared-lib
The --model flag is handy when you want to switch between Sonnet (faster, cheaper) and Opus (more capable) for different tasks.
What’s Next
I’m still exploring. Claude CLI has features I haven’t touched yet—hooks for automating workflows, plugins for extending functionality, and deeper MCP integrations.
There’s also something called spec-kit that GitHub released for “spec-driven development.” A few people have mentioned using it with Claude CLI for more structured workflows. I’m planning to try that next.
For now, though, just running claude in my project directory and asking questions has already changed my daily workflow. It’s the first AI tool that feels like it’s working with my codebase instead of adjacent to it.
If you’ve been using Claude CLI, I’d be curious what patterns you’ve found useful.