Claude Code runs in your terminal and works directly in your project. It can read your files, run commands, write and edit code, manage git, and iterate — all without copying anything in or out of a chat window.
Claude Code runs with your permissions on your machine. Treat it accordingly — read prompts before approving commands or file changes.
Navigate to your project and run:
cd your-project
claudeClaude Code reads your project structure on startup. If you have a CLAUDE.md file, it loads that too.
To start with a specific task immediately:
claude "explain the authentication flow in this codebase"To run a one-off task without entering interactive mode:
claude -p "what does the UserService class do?"The same principles from How to Prompt apply here — context, specificity, iteration. A few things that matter more in Claude Code than in chat:
Scope your tasks. Claude Code works best with tasks that have a clear finish line. "Improve the codebase" is too open-ended. "Add input validation to the registration endpoint and write tests for it" is something it can complete and hand back to you.
Tell it what not to do. If there are files, patterns, or behaviors you don't want touched, say so upfront. Claude Code will work across your whole project unless you constrain it.
That said, constraints given in a prompt aren't guaranteed to hold — especially as a session gets long and earlier instructions drift out of focus. For anything that really matters, don't rely on telling it once. Put hard constraints in your CLAUDE.md so they're loaded every session. For behaviors you need enforced at the tool level — blocking certain commands, restricting file access — use hooks or permission settings rather than trusting the model to remember. If you notice Claude Code doing something you told it not to, check what changed and add the constraint somewhere more durable.
Level up:
CLAUDE.mdis one piece of a larger picture. See Context Engineering for how to think about everything an agent sees — rules files, skills, memory, hooks — as a system.
Review before it runs commands. By default, Claude Code will ask for permission before running shell commands or making file changes. Pay attention to these prompts — don't approve everything automatically.
Reference files explicitly. You can use @filename to point Claude Code at specific files:
Review @src/auth/login.ts and tell me if there are any security concerns
Claude Code narrates what it's doing as it works. When it makes file changes, you'll see diffs. Claude Code can be confidently wrong, especially around edge cases, business logic it doesn't have context for, and anything that requires knowledge outside the codebase.
If something looks off, say so immediately:
That change will break the existing behavior for unauthenticated users — revert it and try a different approach
| Command | What it does |
|---|---|
/help |
List all available commands |
/config |
Open settings — output style, model, permissions |
/memory |
View and edit memory files |
/init |
Generate a CLAUDE.md for this project |
/clear |
Clear conversation history and start fresh |
/compact |
Summarize the conversation to free up context space |
/review |
Ask Claude Code to review its own last output |
/doctor |
Run diagnostics — useful when something feels broken |
Run /help in any session to see the full list including any skills or plugins you have installed.
Claude Code can work autonomously for stretches — especially on well-defined tasks in a codebase with good test coverage. But it's not hands-off by default.
A few signals that it's time to step in:
- It's asking clarifying questions it shouldn't need to ask — your task wasn't specific enough
- It's making changes outside the scope you gave it
- Tests are failing and it's been trying the same fix in different ways
- It's touched a file you wouldn't expect to be involved
The /compact command is useful when a session gets long — it summarizes the conversation to free up context without losing the thread. Start a fresh session (/clear) when the task is done or when it's clearly going in the wrong direction.
On first use, run an orientation session before implementation:
Read through this project and give me:
1. A summary of what it does and how it's structured
2. The main entry points
3. Any patterns or conventions I should know about
4. Anything that looks unusual or worth flagging
Then run /init to generate a CLAUDE.md based on what it learned. Review that file, add anything it missed, and you're set up for future sessions.
Once you're comfortable with a basic session, the next step is understanding how Claude Code fits into a test-driven workflow. Head to Best Practices.