Claude Code can build a feature, fix a bug or write your tests in minutes. It can also burn through your usage limit in an hour while going in circles. The difference is almost never the model. It is the workflow.
This tutorial gives you a workflow that works from day one. Commands and behaviour are taken from Anthropic's official Claude Code docs, checked on 8 November 2026.
What you need before you start
- A Claude plan or API credits. Claude Code is included in Pro, Max, Ultra, Team and Enterprise, or you can use a Claude Console account with pay-as-you-go credits. It is not on the Free plan. See Claude Code pricing to pick one.
- A project folder with some code in it, ideally a Git repository.
- Basic terminal comfort. You should know how to open a terminal and
cdinto a folder. Anthropic has a terminal guide if this is new. - Git installed. You will commit after every working step. On native Windows, Anthropic recommends Git for Windows so Claude Code can use Bash.
Step 1: Install and start
The recommended install is one command.
# macOS, Linux, WSL
curl -fsSL https://claude.ai/install.sh | bash
# Windows PowerShell
irm https://claude.ai/install.ps1 | iex
Homebrew (brew install --cask claude-code) and WinGet (winget install Anthropic.ClaudeCode) also work, but those do not auto-update. Open a new terminal and check with claude --version.
Then start it inside your project:
cd your-project
claude
It asks you to sign in on first use. If you prefer an editor, install the VS Code or JetBrains extension instead; the workflow below is the same.
A few commands you will use daily:
| Command | What it does |
|---|---|
claude |
Start a session in the current folder |
claude -c |
Continue the most recent conversation here |
claude -r |
Pick an earlier conversation to resume |
/clear |
Start fresh, dropping the conversation history |
/usage |
See where your usage is going |
| Shift+Tab | Cycle permission modes, including plan mode |
| Esc | Stop Claude mid-action without losing work so far |
Step 2: Let it read before it writes
Your first prompt should not ask for a change. Ask for understanding:
Explain what this project does, how it is organised, and how I run it and its tests.
Claude reads your files and answers. Now you know whether it understood the project, and you have learned something too. If the answer is wrong, that tells you what to put in CLAUDE.md.
Step 3: Write a short CLAUDE.md
CLAUDE.md is a Markdown file at the project root that Claude Code loads at the start of every session. /init can generate a starting version from your codebase.
The key rule from Anthropic's own best practices: only write down what Claude cannot find by reading the repo. It already reads your file layout, conventions and test framework. What it cannot see:
- The exact commands to run tests and the dev server
- Folders it must never edit (generated code, vendored files)
- Decisions made in a meeting, not in code
- Environment variables a test needs
A good beginner CLAUDE.md is 10 to 30 lines. Anthropic recommends staying under 200. Every line is loaded on every task, so a long file costs you on every turn and makes it more likely that the important lines get missed.
# Commands
- Run tests: npm test
- Dev server: npm run dev
# Rules
- Never edit files in src/generated/
- Use the existing api client in src/lib/api.ts, do not add a new HTTP library
# Gotchas
- Tests need DATABASE_URL set; use the value in .env.example
Our post on context engineering explains why less is more here.
Step 4: Plan before you build
For anything bigger than a one-line fix, use plan mode. Press Shift+Tab until the status bar shows plan mode, or start a prompt with /plan. In plan mode Claude reads files and writes a plan, but does not edit your source until you approve.
Write a specific prompt. Anthropic's docs give a good contrast:
| Instead of | Try |
|---|---|
| fix the login bug | users report login fails after the session times out. look at token refresh in src/auth/, write a failing test that reproduces it, then fix it |
Name the file, describe the symptom, and say what "fixed" looks like. If you do not know what you want yet, ask Claude to interview you and write a spec to a file, then build from that spec in a fresh session.
Read the plan. Push back on anything you do not understand. This is the cheapest moment to change direction.
Step 5: Build in small steps, with a check
Approve the plan and let Claude build, one step at a time. The single most useful thing you can do is give it a check to run: a test, a type check, a build command. Without one, Claude cannot know it is finished, and neither can you.
Add the streak counter. Write tests for the reset-at-midnight case first, then make them pass. Run npm test before you say you are done.
New sessions start in auto mode, where Claude works without asking about routine actions and a classifier reviews risky ones, such as production deploys or force pushes, before they run. If you are learning and want to see every edit and command first, press Shift+Tab to switch to manual mode.
Watch the first minute of every task. If it heads the wrong way, press Esc and redirect. If you have corrected the same thing twice and it is still wrong, do not try a third time. Run /clear, and write one better prompt that includes what you learned.
Step 6: Review, commit, clear
When Claude says it is done, read the change. You can see it in your editor, in the VS Code extension's inline diff, or with git diff. Ask yourself:
- Did it touch files I did not expect?
- Did it add a dependency, a secret or a network call I did not ask for?
- Did the tests actually run and pass?
- Can I explain this change in one sentence?
If yes to the last three and no to the first two, commit:
git add -A && git commit -m "Add streak counter with midnight reset"
Commit after every working step. If a later step goes wrong, /rewind (or Esc twice on an empty prompt) can roll back the code and the conversation, and Git gives you a second safety net.
Claude writes the code. You decide whether it ships.
Then clear before the next task
Before the next unrelated task, run /clear. Every request sends the whole conversation, so a session that has collected three tasks keeps re-reading all three. Clearing costs nothing and gives the next task a clean start.
That is the loop: plan, build a small step, check, review, commit, clear.
Habits that save tokens
These come straight from Anthropic's cost and best-practice docs, plus what we see trip up beginners.
- One task per session. Use
/clearbetween unrelated tasks. Useclaude -cto pick up a task you paused. - Specific prompts. Name files with
@path/to/fileinstead of making Claude search. - Short
CLAUDE.md. It loads every time. - Disconnect MCP servers you are not using. Each adds context to every request.
- Right model for the job. The default on most plans is Opus 5.5 at medium effort. Anthropic notes Sonnet costs less on routine work.
- Skip the magic words. Phrases like "think harder" are ordinary text, not switches. Use the
/effortsetting, or putultrathinkin a single prompt when one question needs deep reasoning. - Check
/usage. It shows usage by skill, subagent, plugin and MCP server, and flags long context or frequent cache misses. - Stop the correction spiral. Two failed corrections means
/clearand a better prompt.
Mistakes we see from beginners
- Asking for a whole app in one prompt, then trying to fix 40 files of guesses.
- Never reading the diff, so bugs pile up silently.
- No Git, so there is no way back to the version that worked.
- A 500-line
CLAUDE.mdcopied from the internet. - Keeping one session open all day across unrelated tasks.
Each of these wastes usage and produces worse code. All of them are fixed by the loop above. If you are weighing Claude Code against other tools, read Claude Code vs Cursor and Codex vs Claude Code.
The best way to learn this loop is to watch it once and then do it yourself. At our free Saturday workshop we install Claude Code, write a CLAUDE.md, plan, build, review and commit a small feature live, and you follow along on your own laptop. Save your seat for Saturday.