Claude Code Tutorial: How to Use Claude Code on a Real Task

The fastest way to learn Claude Code is to ship one real change with it. This tutorial walks through a complete feature on an existing project: understanding the code, planning, implementing with tests, reviewing, committing, and finally saving the workflow so next time takes one command. Commands are checked against the official docs as of October 24, 2026.

You’ll need Claude Code installed and signed in. If it isn’t yet, follow How to install Claude Code (five minutes), and skim Getting started with Claude Code for the basics.

The example task

We’ll use a typical small backend project with a test suite, and add one feature:

Add a --since option to the export command so users can export only records created after a given date.

Use any repository you have with tests and a similar small feature. The prompts below adapt to any stack; replace the names with yours.

Step 1: Open the project and get oriented

cd ~/code/my-project
claude

Before changing anything, ask Claude to explain the area you’ll touch. It reads files itself; you don’t paste code.

how does the export command work? trace it from the CLI entry point to where records are written

how are dates parsed elsewhere in this codebase? is there a helper I should reuse?

Point it at specific files with @, for example explain @src/commands/export.py. Questions like these are cheap, and they surface conventions Claude should follow later.

If the project has no CLAUDE.md, run /init now. Claude writes one with the build and test commands it discovers. Trim it to the essentials; our CLAUDE.md guide shows what to keep.

Step 2: Plan before you code

Press Shift+Tab until the status bar shows plan mode. In plan mode Claude reads and proposes but doesn’t edit.

I want to add a --since option to the export command that accepts an ISO date and only exports records created after it.
Reuse the existing date helper. Invalid dates should exit with a clear error.
Write a plan: which files change, what tests to add, and how you'll verify it.

Read the plan carefully. This is the cheapest moment to fix a misunderstanding. Press Ctrl+G to open the plan in your editor and change it directly, or reply with corrections:

good plan. also handle timezone-less dates as UTC, and add a test for that

When to skip this step: if you could describe the whole diff in one sentence, such as fixing a typo or renaming a variable, just ask for it directly.

Step 3: Implement with a built-in check

Approve the plan. Claude leaves plan mode and starts editing. Make sure the request includes a way for Claude to verify its own work:

implement the plan. write the tests first, run them to see them fail, then implement until the full test suite passes. show me the test output at the end.

This is the most important habit in Claude Code: with a pass/fail signal, Claude iterates until the check passes, rather than stopping when the code merely looks right. Asking for the test output means you review evidence, not a claim.

While it works:

• Claude may ask permission to edit files or run commands, depending on your permission mode.
• Press Esc to stop it mid-action if it heads the wrong way; context is kept, so just redirect.
• Press Esc twice or run /rewind to restore code and conversation to an earlier checkpoint.

Step 4: Review the diff

Don’t skip review just because the tests pass. Ask for a summary, then read the actual changes:

summarise what you changed and why, file by file

what edge cases did you not test?

Then get a fresh-eyes review. /code-review reviews the current diff for bugs in a separate subagent context, so it isn’t biased by the reasoning that produced the code. Fix what matters:

fix the two correctness issues from the review; ignore the style suggestions

If you prefer your own checklist, our code review prompt works well as a starting point.

Step 5: Commit and open a pull request

commit these changes with a descriptive conventional commit message, push the branch and open a PR with a summary and test notes

Claude uses git and, if installed, the gh CLI to open the PR. Installing gh is worth it: Claude knows how to use it for issues, PRs and comments, and it’s more context-efficient than API calls.

That’s one complete loop: explore, plan, implement, verify, review, ship.

Step 6: Keep the session healthy

Long sessions degrade as the context window fills with file contents and command output. Three commands keep things sharp:

Command	Use it when
/clear	You’re switching to an unrelated task
/compact Focus on the export feature	You’re continuing the same task but context is getting large
/context	You want to see what’s filling the context window

A rule of thumb from Anthropic’s guidance: if you’ve corrected Claude twice on the same issue, /clear and start again with a better prompt. More in the context management guide.

To pause and resume later, name the session with /rename export-since, then use claude --continue (most recent) or claude --resume (pick from a list).

Step 7: Save the workflow as a skill

You’ll do “plan, test-first implement, review, PR” again. Save it as a skill so it’s one command next time. Create .claude/skills/ship-feature/SKILL.md:

---
name: ship-feature
description: Plan, implement test-first, review and open a PR for a small feature
disable-model-invocation: true
---
Ship this feature: $ARGUMENTS

1. Explore the relevant code and list the files involved
2. Write a short plan and wait for my approval
3. Write failing tests, then implement until the full suite passes
4. Show the test output
5. Run /code-review and fix correctness issues only
6. Commit with a conventional message, push and open a PR with gh

Now run:

/ship-feature add a --format=csv option to the export command

disable-model-invocation: true means the skill runs only when you call it, which suits workflows that push code.

Step 8: Use it outside the interactive session

Once you trust a workflow, Claude Code also runs non-interactively, which is handy for scripts and CI:

claude -p "list every CLI command in this project and its options" --output-format json

The headless mode guide covers flags and safety, and Claude Code GitHub Actions shows how to run it on pull requests.

Anatomy of a good Claude Code prompt

Look back at the prompts in this tutorial. The ones that worked best share four parts:

Part	Example from this tutorial
What you want	“add a —since option to the export command”
Constraints that matter	“reuse the existing date helper; invalid dates exit with a clear error”
Where to look	“trace it from the CLI entry point”, @src/commands/export.py
How to verify	“run the full test suite and show me the output”

You don’t need all four for every request, but when a result disappoints, the missing part is usually the cause. A vague prompt is fine for exploring (“what would you improve in this file?”); a specific one is better for changes. Our Claude prompting best practices go deeper on wording.

Beginner mistakes to avoid

• Doing everything in one session. Fixing a bug, then asking about deployment, then returning to the bug leaves Claude juggling irrelevant context. One task per session, /clear in between.
• Accepting a plan you didn’t read. Plan mode only protects you if you actually review the plan. Two minutes here saves twenty later.
• Trusting “done” without evidence. Always ask for the test output or a screenshot. If there’s no way to verify the change, write a small check first.
• Fighting the same mistake repeatedly. After two corrections on the same issue, start a fresh session with a clearer prompt that includes what you learned.
• Relying on checkpoints instead of git. /rewind restores edits made through Claude’s file tools, not changes made by shell commands such as migrations or package installs. Commit at every good state.
• Pasting secrets into prompts. Keep API keys in environment variables or .env files and tell Claude where they’re loaded from, rather than pasting the values.

Where else you can run the same workflow

Everything above works the same way outside the terminal. Claude Code also runs as a desktop app, as VS Code and JetBrains extensions with visual diffs, and on the web. The prompts, plan mode, skills and CLAUDE.md carry across, so you can start a task in the terminal and review it in your editor.

If you work on several features at once, run one session per git worktree so their edits never collide.

What to learn next

Goal	Read
Better results on every task	Claude Code best practices
Connect GitHub, databases or a browser	MCP servers for Claude
Delegate research and reviews	Subagents guide
Enforce rules automatically	Hooks guide
Every command in one place	Slash commands cheatsheet
Understand costs and limits	Claude Code pricing

As your skills, hooks and subagents grow, you’re building a Claude kit: a reusable setup you can share with your team. The Claude kit hub shows how others structure theirs.