How to use Claude Code

Use Claude Code by opening it inside a project folder, giving it a goal in plain language, and letting it read files, edit them and run commands while you review each change. Start in a small repository, keep permission prompts on, write a short CLAUDE.md, and work in four steps: explore, plan, code, commit. The rest of this page covers each piece.

What Claude Code is, in one paragraph

Claude Code is a tool that works on your files, not a chat window. Anthropic's course says it is "an agentic coding tool that understands your codebase, edits your files, runs commands, and integrates with your existing developer tools to help you get things done faster". It runs in your terminal, Visual Studio Code, the Claude Desktop app, on the web and in JetBrains IDEs. The practical difference from Claude.ai is that you stop pasting code back and forth. It goes in and does the work, which also means it can get things wrong in your actual files.

Install it and run your first prompt

Pick one surface and start there. The terminal is the most direct, and the VS Code extension is mostly a launcher that makes opening sessions easier, as Steve Sewell of Builder.io describes. Anthropic's Claude Code 101 course lists the prerequisites: basic familiarity with a code editor and the command line, plus a Claude account (Pro, Max or Enterprise) or an API key.

My first-session routine:

1. Open a small repository you understand, with a clean git state.
2. Start Claude Code in that folder.
3. Ask a read-only question first: "Explain how this project is structured and where the entry point is."
4. Check its answer against what you know. If it is wrong about code you wrote, you have learned how much to trust it before it edits anything.

Do not start on production code, and do not start with a task you could not undo with git checkout. Size is not the limit, though. Sewell writes that Builder has a React component that is 18,000 lines long and that no AI agent had updated it successfully except Claude Code (Builder.io). That is one team's report, so test it on your own largest file before you rely on it.

Work in four steps: explore, plan, code, commit

The reliable way to use Claude Code on any task is to separate thinking from editing. Anthropic's course teaches an explore, plan, code, commit workflow, and the course objectives mention Plan Mode as the way to write prompts that do not edit right away.

• Explore: ask it to read the relevant files and summarize how they work. No edits.
• Plan: ask for a written plan, with the files it would touch and the order. Edit the plan yourself.
• Code: tell it to implement the approved plan, one piece at a time.
• Commit: review the diff, run the tests, then commit. Commit before the next task so every task is one revert.

The Claude Code docs show the same split for bigger jobs: start with claude --permission-mode plan, where Claude reads files and proposes a plan without editing source code, then save the plan to the repo and hand it off. The same page notes that a repository bundled for a cloud session must be under 100 MB. Plan locally, execute afterward.

My rule: if you cannot describe the diff you expect before the code step, you skipped the plan.

Control permissions before you control speed

Keep the permission prompts on until you trust the task. Claude Code asks before running commands or changing files, and the course says you can instead run in auto mode, where a background safety check screens most actions. Sewell finds the prompts annoying and runs claude --dangerously-skip-permissions himself, saying he has not seen a destructive command in weeks of use. That is his risk call, and the flag name tells you what it does.

My decision rule: skip prompts only in a throwaway branch or a disposable environment, on a repository with no secrets in it, and never on a machine that holds credentials you cannot rotate. For anything else, approve edits as they come and let the prompts slow you down.

Manage context so sessions stay useful

The context window is Claude's working memory. The Anthropic course says it can hold a lot, but not everything at once. Two habits matter most.

• Run /clear when you start unrelated work. Sewell recommends this so old history does not eat tokens.
• Use /compact to summarize a long session you still need, and /context to see what is filling the window.

If sessions get expensive or sloppy, I wrote a context burn audit that walks through finding what is consuming context.

Write a CLAUDE.md before your third session

A CLAUDE.md file gives Claude persistent project memory, so it does not rediscover your build and lint commands every session. Sewell notes it can be hierarchical, with a project-level file and nested ones, and the most specific applies when relevant. Keep it short. A file that grows into a manual gets ignored in practice, so I treat every line as something that must earn its place.

Copy this and fill it in:

# CLAUDE.md

## Commands
- Build: <command>
- Test: <command>
- Lint: <command>

## Conventions
- <one rule per line, only rules Claude got wrong before>

## Do not
- Do not edit files in <folder>.
- Do not add dependencies without asking.
- Do not commit; I review and commit.

## Done means
- Tests pass, lint is clean, and you list every file you changed.

Add a line only after Claude makes the same mistake twice. That keeps the file honest. If you want more starting files in this plain-text style, the free starters on jakebauman.io are a place to look.

Add hooks, subagents and MCP after the basics hold

Customization comes after you have a working loop. The Anthropic course covers subagents (to delegate tasks and keep the main context clean), MCP servers (to connect external tools and data) and hooks (for deterministic control over formatting, command blocking and notifications). Builder.io's post shows a .claude/settings.json hook that runs Prettier after edits and a custom slash command stored as a markdown file in .claude/commands.

Hooks are the one I would add first, because a formatter or type check that runs every time does not depend on Claude remembering a rule. If you later want several agents with separate roles, I described a three-agent Claude Code team pattern. Non-developers using agents for marketing work can start with AI agents for marketing tasks.

Review every Claude Code change like a colleague wrote it

Claude Code can misunderstand your intent, introduce a bug or over-engineer a solution. The course says so directly and says staying in the loop helps you catch it early. My workflows keep a human review step before anything ships, and code is no exception. Read the diff, run the tests yourself, and reject changes you cannot explain.

Your next step: pick one small repository, add a CLAUDE.md that lists its build, test and lint commands, and run one explore, plan, code, commit cycle on a task that would take you under an hour.

How this post was made: drafted with AI assistance (Claude Sonnet 5.5) from the sources linked above, then checked by Claude Opus 5.5 and an automated quality gate that matched every figure and quotation to its source on 2026-11-02.