← Back to learning path
Level 1

Level 1: Prompting with Intent

The definitive guide to going from zero to productive with Claude Code -- from installation through the planning-first workflow that…

Level 1: Prompting with Intent

The definitive guide to going from zero to productive with Claude Code -- from installation through the planning-first workflow that separates beginners from effective users.

Table of Contents

  1. Overview and Goal
  2. Installing Claude Code
  3. Understanding Claude Code's Interface
  4. Plan Mode -- The Most Important Feature
  5. Writing Effective Prompts
  6. The AskUserQuestion Pattern
  7. Context Providing Techniques
  8. Common Workflows for Beginners
  9. Essential Keyboard Shortcuts
  10. Exercises
  11. Pro Tips from Boris Cherny
  12. Anti-Patterns for Beginners
  13. Official Documentation Links

1. Overview and Goal

Why This Level Matters

The difference between someone who fights with Claude Code and someone who gets consistent, high-quality results comes down to one habit: planning before building.

Most beginners open Claude Code, type a vague request, and hope for the best. When the result is wrong, they type another vague correction. The context window fills with failed attempts. Performance degrades. Frustration grows.

This guide teaches you a different approach. You will learn to:

This is the 4-phase workflow: Explore, Plan, Implement, Commit. Every section in this guide reinforces it.

What Claude Code Actually Is

Claude Code is an agentic coding environment. Unlike a chatbot that answers questions and waits, Claude Code can read your files, run commands, make changes, and autonomously work through problems. You describe what you want, and Claude figures out how to build it -- exploring the codebase, planning the approach, and implementing the solution.

This autonomy is powerful, but it comes with a learning curve. Claude works within constraints you need to understand: primarily the context window, which holds your entire conversation, every file Claude reads, and every command output. When the context fills up, performance degrades. Managing this resource is a core skill that separates effective users from frustrated ones.

The Core Constraint

Most best practices in this guide stem from one reality:

Claude's context window fills up fast, and performance degrades as it fills.

Everything you send Claude -- prompts, file contents, command outputs, corrections -- consumes context. A single debugging session can generate tens of thousands of tokens. When the window gets full, Claude may start forgetting earlier instructions or making more mistakes.

The techniques in this guide (Plan Mode, clear prompts, scoped context, knowing when to /clear) all help you work within this constraint.

2. Installing Claude Code

Prerequisites

Claude Code has no software prerequisites beyond a terminal. You do not need Node.js, Python, or any other runtime installed. The native installer handles everything.

You do need:

Installation Methods

Native Install (Recommended)

The native installer is the recommended approach. It automatically updates in the background to keep you on the latest version.

macOS, Linux, WSL:

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

Windows CMD:

curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

Homebrew (macOS)

brew install --cask claude-code

Note: Homebrew installations do not auto-update. Run brew upgrade claude-code periodically.

WinGet (Windows)

winget install Anthropic.ClaudeCode

Note: WinGet installations do not auto-update. Run winget upgrade Anthropic.ClaudeCode periodically.

Verifying Installation

After installation, confirm Claude Code is available:

claude --version

You should see a version number printed. If the command is not found, close and reopen your terminal so your shell picks up the new PATH entry.

First Launch Walkthrough

Navigate to any project directory and start Claude Code:

cd /path/to/your/project
claude

On first launch, Claude Code will:

  1. Prompt you to log in. A browser window opens for authentication. Log in with your Claude account (Pro, Max, Teams, or Enterprise) or Claude Console account.
  2. Store your credentials locally. You will not need to log in again on this machine unless you explicitly log out.
  3. Display the welcome screen. This shows your session information, recent conversations, and any latest updates.

To log in or switch accounts at any time, use:

/login

Authentication Options

Account Type How to Get It Best For
Claude Pro/Max claude.com/pricing Individual developers
Claude Teams claude.com/pricing Small teams
Claude Enterprise Contact Anthropic sales Large organizations
Claude Console (API) console.anthropic.com Pay-per-use, CI/CD
Amazon Bedrock AWS account AWS-native workflows
Google Vertex AI GCP account GCP-native workflows

Other Environments

Claude Code is also available beyond the terminal:

This guide focuses on the terminal CLI, which is the most powerful and flexible interface.

3. Understanding Claude Code's Interface

The REPL (Read-Eval-Print Loop)

When you run claude in your terminal, you enter an interactive session -- a REPL. You type a prompt, Claude reads it, evaluates (explores files, runs commands, makes changes), and prints the result. Then it waits for your next prompt.

This loop continues until you type exit, press Ctrl+C, or close the terminal. The entire conversation history stays in memory (the context window) throughout the session.

The Status Line

At the bottom of your terminal, Claude Code displays a status line. This shows:

The status line is your dashboard. Watch the context usage indicator -- when it gets high, consider running /clear to reset.

Typing Prompts

Your prompt appears at the > character. Type naturally, as you would speak to a colleague. Claude Code understands plain English (and many other languages).

Single-Line Input

> explain the folder structure

Multi-Line Input

For longer prompts, use \ at the end of a line to continue on the next line:

> I want to add a new API endpoint that \
  handles user profile updates. It should \
  validate the input and return appropriate \
  error messages.

You can also simply press Enter within a prompt to start a new line in many terminals (behavior depends on your terminal configuration).

Pasting Content

You can paste multi-line content directly -- error messages, code snippets, stack traces. Claude Code handles pasted content correctly, even across multiple lines.

@ File References

One of the most important input mechanisms is the @ reference. Instead of telling Claude where a file lives, you point directly to it:

> explain the logic in @src/utils/auth.js

This causes Claude to read the full contents of src/utils/auth.js before responding. You are not just mentioning the file -- Claude actually loads and processes it.

You can reference multiple files:

> compare the patterns in @src/old-auth.js and @src/new-auth.js

You can reference directories (Claude gets a file listing, not contents):

> what's the structure of @src/components?

File paths can be relative (to your project root) or absolute.

Image and URL Input

Claude Code is multimodal. You can provide images and URLs as context:

Images:

URLs:

Slash Commands

Commands prefixed with / are built-in operations:

Command Purpose
/help Show all available commands
/clear Clear conversation history and reset context
/compact Summarize conversation to free context space
/login Log in or switch accounts
/init Generate a starter CLAUDE.md for your project
/permissions Configure which tools Claude can use without asking
/hooks Configure automation hooks
/agents View and create custom subagents
/resume Resume a previous conversation
/rename Give the current session a descriptive name
/rewind Restore to a previous conversation checkpoint
/model View or change the current model
/config Adjust global settings
/sandbox Enable OS-level isolation

Type / at the prompt to see all available commands, including any custom skills you have defined.

4. Plan Mode -- The Most Important Feature

What Plan Mode Is

Plan Mode is a read-only research and analysis mode. When Claude is in Plan Mode, it can:

What Claude cannot do in Plan Mode:

This makes Plan Mode completely safe. Nothing can break. You can explore freely, ask questions, and iterate on a plan without any risk to your code.

How to Toggle Plan Mode

You cycle through modes using Shift+Tab:

Normal Mode  -->  Auto-Accept Mode  -->  Plan Mode  -->  Normal Mode
(accept edits)    (accept edits on)     (plan mode on)

Starting from Normal Mode:

  1. First Shift+Tab: Switches to Auto-Accept Mode (Claude makes changes without asking permission each time). The status line shows accept edits on.
  2. Second Shift+Tab: Switches to Plan Mode. The status line shows plan mode on.
  3. Third Shift+Tab: Returns to Normal Mode.

You can also start a new session directly in Plan Mode:

claude --permission-mode plan

Or run a single query in Plan Mode:

claude --permission-mode plan -p "Analyze the authentication system and suggest improvements"

When to Use Plan Mode

Use Plan Mode when:

Skip Plan Mode when:

The 4-Phase Workflow in Detail

This is the workflow that separates effective Claude Code users from beginners. It applies to any non-trivial task.

Phase 1: Explore

Enter Plan Mode. Have Claude read files, understand the codebase structure, and answer your questions. Do not describe what you want to build yet -- first understand what exists.

> [Plan Mode] read @src/auth and understand how we handle sessions and login.
> also look at how we manage environment variables for secrets.

Ask follow-up questions:

> how does the token refresh logic work?
> what happens when a session expires?
> are there any existing OAuth utilities I should know about?

Why this matters: Claude's implementation quality depends entirely on its understanding of your codebase. Skipping exploration means Claude will guess at patterns, conventions, and architecture -- and often guess wrong.

Phase 2: Plan

Still in Plan Mode. Now describe what you want to build, and ask Claude to create a detailed implementation plan.

> I want to add Google OAuth login. What files need to change?
> What's the session flow? Create a step-by-step plan.

Review the plan carefully. Push back on anything you disagree with:

> I don't want to add a new database table for this.
> Can we reuse the existing session model instead?

Keep iterating until the plan is solid:

> What about error handling for expired OAuth tokens?
> How do we handle the case where a user already exists with that email?

Pro tip: Press Ctrl+G to open the plan in your default text editor. You can edit it directly -- add requirements, remove steps, reorder priorities -- and Claude will use your edited version when you proceed.

Phase 3: Implement

Switch back to Normal Mode (Shift+Tab). Now tell Claude to implement the plan. Include verification criteria.

> implement the OAuth flow from your plan. Write tests for the
> callback handler, run the test suite, and fix any failures.

Claude will now write code, create files, and execute commands. In Normal Mode, it asks for permission before each change. If you switched to Auto-Accept Mode, it proceeds without asking (useful when you trust the plan).

Phase 4: Commit

Ask Claude to commit the work with a descriptive message:

> commit with a descriptive message and open a PR

Or use the built-in skill:

> /commit-push-pr

Example: Walking Through a Real Feature Request

Let us walk through adding a "forgot password" feature to an existing authentication system.

Phase 1: Explore (Plan Mode)

> [Plan Mode] I need to understand how authentication works in this project.
> Read the auth-related files and explain the current flow.

Claude reads files, reports back:

"The project uses JWT tokens stored in HTTP-only cookies. Login is handled in src/controllers/authController.js. Passwords are hashed with bcrypt in src/models/User.js. There's no existing password reset functionality. Email sending uses nodemailer, configured in src/services/emailService.js."

> Does the User model already have fields for reset tokens?

"No. The User model currently only has: id, email, passwordHash, createdAt, updatedAt. We would need to add resetToken and resetTokenExpiry fields."

Phase 2: Plan (Plan Mode)

> I want to add a "forgot password" flow. The user enters their email,
> gets a reset link, clicks it, and sets a new password. Create a plan.

Claude produces a plan. You push back:

> The reset token should expire after 1 hour, not 24 hours.
> Also, we should rate-limit the reset endpoint to prevent abuse.

Claude revises the plan. You approve it.

Phase 3: Implement (Normal Mode)

> Implement the forgot password flow from your plan.
> After implementing, run the existing test suite to make sure nothing broke,
> then add new tests for the reset flow covering:
> - valid reset request
> - expired token
> - invalid token
> - rate limiting

Claude implements, runs tests, fixes any failures.

Phase 4: Commit (Normal Mode)

> commit with a descriptive message explaining what was added and why

5. Writing Effective Prompts

The Fundamental Principle

The quality of Claude's output is directly proportional to the specificity of your input. Vague prompts produce vague results. Specific prompts produce specific results.

This does not mean every prompt must be a paragraph. It means your prompt should contain enough information for Claude to do the right thing without guessing.

Bad Prompt vs. Good Prompt: 8 Examples

Example 1: Bug Fix

Bad:

fix the login bug

Good:

Users report that login fails after session timeout. Check the auth flow
in src/auth/, especially token refresh. Write a failing test that
reproduces the issue, then fix it.

Why it's better: Describes the symptom, points to likely location, specifies verification (failing test first).

Example 2: Adding Tests

Bad:

add tests for foo.py

Good:

Write a test for foo.py covering the edge case where the user is
logged out. Avoid mocks -- use the test database. Follow the patterns
in tests/test_bar.py for structure.

Why it's better: Specifies which edge case, the testing approach (no mocks), and points to a pattern file.

Example 3: Feature Implementation

Bad:

add a calendar widget

Good:

Look at how existing widgets are implemented on the home page.
HotDogWidget.php is a good example. Follow that pattern to implement
a new calendar widget that lets the user select a month and paginate
forwards/backwards to pick a year. Build from scratch without
external libraries other than the ones already used in the codebase.

Why it's better: References existing patterns, specifies exact behavior, constrains the solution space.

Example 4: Code Understanding

Bad:

why does ExecutionFactory have such a weird api?

Good:

Look through ExecutionFactory's git history and summarize how its
API came to be. What decisions led to the current design?

Why it's better: Points Claude to a concrete information source (git history) instead of asking it to speculate.

Example 5: Refactoring

Bad:

clean up utils.js

Good:

Refactor utils.js to use ES2024 features while maintaining the same
external behavior. Run the existing tests after each change to
ensure nothing breaks. Focus on: arrow functions, optional chaining,
and nullish coalescing.

Why it's better: Specifies what "clean up" means, names the specific changes, includes verification.

Example 6: UI Work

Bad:

make the dashboard look better

Good:

[paste screenshot] Implement this design for the dashboard. After
implementing, take a screenshot of the result and compare it to
the original. List any visual differences and fix them.

Why it's better: Provides a concrete target (the screenshot), defines a verification method (visual comparison).

Example 7: Code Review

Bad:

review this code

Good:

Review the changes in @src/middleware/rateLimiter.ts. Look for edge
cases, race conditions, and consistency with our existing middleware
patterns in @src/middleware/auth.ts.

Why it's better: Names the specific file, specifies what to look for, references a pattern to follow.

Example 8: Documentation

Bad:

add documentation

Good:

Find functions without proper JSDoc comments in the auth module.
Add JSDoc comments following the patterns used in @src/utils/helpers.js.
Include parameter types, return types, and at least one usage example
per function.

Why it's better: Scopes the work, references existing patterns, specifies what documentation must include.

The Verification Criteria Pattern

The single highest-leverage thing you can do in any prompt is tell Claude how to verify its own work. Without verification, Claude produces something that looks right but may not work. With verification, Claude becomes its own QA engineer.

Pattern:

[describe what you want]

Verify by:
- [specific test to run]
- [specific condition to check]
- [specific output to compare]

Examples:

Write a validateEmail function. Verify by running these test cases:
- [email protected] -> true
- "invalid" -> false
- [email protected] -> false
- @ -> false
Run the tests after implementing.

Add rate limiting to the /api/login endpoint. Verify by:
- Running the test suite
- Manually testing with curl that the 6th request in 60 seconds returns 429
- Checking that the X-RateLimit-Remaining header decrements correctly

Migrate the User model from Sequelize v5 to v6 syntax. Verify by:
- Running all existing user-related tests
- Checking that npm run build completes without errors
- Verifying the migration runs cleanly on a fresh database

Including Test Expectations

When you know what the tests should check, state them upfront:

Add input sanitization to the comment form. Write tests that verify:
1. HTML tags are stripped from comment body
2. SQL injection attempts are neutralized
3. Comments longer than 10,000 characters are rejected
4. Unicode characters are preserved correctly
5. Empty strings are rejected

Run the tests after implementing. Fix any failures.

This prevents the common failure pattern where Claude writes tests that pass trivially or do not actually test the important behavior.

Being Specific About File Ownership and Scope

When Claude knows exactly which files it should and should not touch, the results improve dramatically:

Add error handling to the payment processing module.

Files to modify:
- src/services/paymentService.ts
- src/controllers/paymentController.ts
- src/types/payment.ts

Do NOT modify:
- src/services/stripeClient.ts (third-party wrapper, should stay as-is)
- Any files in src/models/ (database models are not part of this change)
- Any test files (I will write the tests separately)

6. The AskUserQuestion Pattern

What It Is

Claude Code has a built-in tool called AskUserQuestion. When invoked, Claude stops and asks you a question before proceeding. This is different from Claude simply generating text -- it creates an actual interactive pause where Claude waits for your response.

How to Trigger It

The most reliable way to trigger this behavior is to include "interview me" in your prompt:

I want to build a notification system for our app. Interview me in
detail using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns,
and tradeoffs. Don't ask obvious questions -- dig into the hard
parts I might not have considered.

Keep interviewing until we've covered everything, then write a
complete spec to SPEC.md.

You can also use shorter triggers:

Before implementing anything, ask me clarifying questions about
what I want.

Interview me about the requirements before you start coding.

Why It Prevents Wasted Work

Without the AskUserQuestion pattern, you describe a feature, Claude implements it, and then you realize it misunderstood half of what you wanted. You spend time correcting, re-implementing, and correcting again. Context fills up. Quality drops.

With the AskUserQuestion pattern, Claude asks about edge cases, tradeoffs, and decisions you had not considered. The implementation starts from a shared understanding, not from Claude's assumptions.

Example Interaction

You type:

> I want to add user notifications. Interview me first.

Claude asks:

"What types of notifications do you need? For example: in-app only, email, push notifications, or some combination?"

You answer:

> In-app and email. No push notifications for now.

Claude asks:

"For in-app notifications, should they be real-time (WebSocket) or poll-based? And should users be able to mark individual notifications as read, or mark all as read at once?"

You answer:

> Real-time with WebSocket. Both individual and bulk mark-as-read.

Claude asks:

"What's your email sending infrastructure? Do you already have a transactional email service set up, or should I plan for that too?"

And so on, until all the ambiguity is resolved. Then Claude writes a spec you can review before any code is written.

Best Practice: Spec First, Then Fresh Session

After the interview produces a written spec (in SPEC.md or similar), start a fresh Claude Code session to implement it:

claude --permission-mode plan -p "Read SPEC.md and create an implementation plan"

The fresh session has clean context focused entirely on implementation. The spec provides all the requirements without the noise of the interview conversation.

7. Context Providing Techniques

Why Context Matters

Claude Code can only work with what it knows. The better the context you provide, the better the output. But context has a cost: every piece of context consumes tokens from the context window. The goal is to provide the right context -- not too little, not too much.

@ File References

The @ prefix is the most common way to provide context. It reads the file into context before Claude responds.

> explain the logic in @src/utils/auth.js

Multiple files:

> compare the error handling in @src/api/users.js and @src/api/orders.js

Directories (provides file listing, not contents):

> what's in @src/components?

How it works under the hood: When Claude sees @path/to/file, it reads the full file content into the context window. It also pulls in any CLAUDE.md files found in that file's directory and parent directories. This means referencing a file automatically loads relevant project conventions.

When to use it: When you know exactly which files are relevant. This is more efficient than asking Claude to search, because it avoids the exploration overhead.

Pasting Images (Multimodal Input)

Claude Code accepts images directly in the conversation. This is invaluable for UI work.

Methods:

  1. Drag and drop: Drag an image file from Finder/Explorer directly into the terminal
  2. Clipboard paste: Copy an image, then press Ctrl+V in the Claude Code prompt (note: use Ctrl+V, not Cmd+V, even on macOS)
  3. File path: Reference the image by path: "Analyze this screenshot: /path/to/image.png"

Common uses:

> [paste screenshot] This is the current login page. The "forgot password"
> link is not visible on mobile. Fix the responsive CSS so it appears below
> the password field on screens narrower than 768px.

URLs as Context

Paste URLs directly in your prompt. Claude fetches and processes the page content:

> Read the API documentation at https://example.com/api/v2/docs and
> then implement a client that handles pagination correctly.

To allow specific domains without permission prompts each time, use /permissions to allowlist them.

Piping Data In

You can pipe content directly from the terminal:

# Send a file's contents as context
cat error.log | claude -p "explain the root cause of this error"

# Send command output as context
npm test 2>&1 | claude -p "explain why these tests are failing"

# Send git diff as context
git diff main | claude -p "review these changes for security issues"

Copy-Paste from Terminal Output

When you encounter an error, copy the full error output and paste it into your prompt:

> I got this error when running npm start:

Error: Cannot find module '@/components/Header'
  Require stack:
  - /Users/dev/project/src/App.tsx
  - /Users/dev/project/src/index.tsx

Fix this. The component exists at src/components/Header.tsx, so this
is likely a path resolution issue.

Pasting the full error (not paraphrasing it) gives Claude the exact module path, stack trace, and error type -- far more useful than "I got an import error."

Git Diff Context

Git diffs are one of the most valuable forms of context:

> Here's what I've changed so far:
> [paste output of git diff]
> Review these changes and tell me if I've missed anything.

Or let Claude pull the diff itself:

> Look at my current git diff against main and review the changes.
> Focus on security implications and edge cases.

Letting Claude Pull Its Own Context

Sometimes the best approach is not to provide context yourself, but to tell Claude where to find it:

> Use gh issue view 1234 to get the issue details, then look through
> the codebase to find the relevant files and fix the bug described
> in the issue.

> Read the README for setup instructions, then check if our current
> configuration matches what's documented.

This is useful when you do not know exactly which files are relevant, and you want Claude to use its tools (file search, grep, git commands) to locate the right context.

8. Common Workflows for Beginners

Exploring a New Codebase

When you join a new project or open an unfamiliar repository:

cd /path/to/new-project
claude

Start broad and narrow down:

> give me an overview of this codebase

> explain the main architecture patterns used here

> what are the key data models?

> how is authentication handled?

> what technologies and frameworks does this project use?

> trace the login process from front-end to database

Tip: Use Plan Mode for all of this. You are only reading, not changing. There is no reason to risk accidental modifications while learning.

Fixing a Bug

When you have a bug report or error message:

Step 1: Share the error (include full output)

> I'm seeing this error when I run npm test:

TypeError: Cannot read properties of undefined (reading 'map')
    at UserList (src/components/UserList.tsx:23:18)
    at renderWithHooks (node_modules/react-dom/...)

Step 2: Let Claude investigate

> What's causing this? Look at the UserList component and the data
> it receives from its parent.

Step 3: Ask for a fix with verification

> Fix the null safety issue and add a test that reproduces the
> original error. Run the tests after fixing.

Adding a Feature

Step 1: Explore (Plan Mode)

> [Plan Mode] I want to add a search function to the user list page.
> Read the current UserList component and the API endpoints to
> understand how data flows.

Step 2: Plan (Plan Mode)

> Create a plan for adding search. It should:
> - Filter by name and email
> - Debounce input (300ms)
> - Show a loading state
> - Handle empty results

Step 3: Implement (Normal Mode)

> Implement the search feature from your plan. Run the existing tests
> to make sure nothing broke, then add new tests for search.

Step 4: Commit

> commit with message "Add search functionality to user list page"

Code Review

Ask Claude to review changes, either your own or from a pull request:

> Review the changes in my current branch compared to main.
> Look for:
> - Security issues
> - Edge cases
> - Consistency with existing patterns
> - Missing error handling

For pull requests (requires gh CLI):

> Use gh to look at PR #42. Review the changes and leave comments
> on any issues you find.

Writing Tests

Ask Claude to identify untested code and write tests:

> Find functions in @src/services/paymentService.ts that are not
> covered by existing tests. Write tests for them following the
> patterns in @tests/services/userService.test.ts.

> Add edge case tests for the calculateDiscount function:
> - Zero quantity
> - Negative price
> - Discount greater than 100%
> - Missing required fields

Asking Questions About Code

You can ask Claude the same questions you would ask a senior engineer:

> How does logging work in this project?

> How do I make a new API endpoint?

> What does `async move { ... }` do on line 134 of foo.rs?

> What edge cases does CustomerOnboardingFlowImpl handle?

> Why does this code call foo() instead of bar() on line 333?

No special prompting required. Ask directly.

9. Essential Keyboard Shortcuts

Navigation and Control

Shortcut Action When to Use
Shift+Tab Cycle mode: Normal -> Auto-Accept -> Plan -> Normal Toggle Plan Mode or Auto-Accept
Esc Stop Claude mid-action When Claude is going in the wrong direction
Esc Esc (double-tap) Open the rewind menu When you want to undo changes or restore a checkpoint
Ctrl+C Interrupt / Exit Claude Code To cancel current operation or exit
Ctrl+L Clear the terminal screen When the screen is cluttered
Ctrl+G Open plan in text editor To edit a plan directly before Claude proceeds
Up Arrow Cycle through previous prompts To reuse or modify a previous prompt
Tab Autocomplete file paths and commands Speed up typing file references
? Show all available keyboard shortcuts Quick reference during a session
Enter Submit prompt / Approve a change Send your message or accept Claude's suggestion

Mode Shortcuts

Shortcut Action Description
Shift+Tab (from Normal) Enter Auto-Accept Mode Claude makes changes without per-change permission
Shift+Tab (from Auto-Accept) Enter Plan Mode Claude enters read-only mode
Shift+Tab (from Plan) Return to Normal Mode Standard mode with per-change permission

Display and Configuration

Shortcut Action Description
Ctrl+O Toggle verbose mode Show/hide Claude's internal reasoning (thinking)
Option+T / Alt+T Toggle thinking mode Turn extended thinking on/off for current session

Session Management

Shortcut / Command Action Description
/clear Clear context Reset the context window between unrelated tasks
/compact Compact context Summarize conversation to free space
/compact <focus> Focused compact Summarize with emphasis: /compact focus on API changes
/rewind Open rewind menu Restore conversation, code, or both to a checkpoint
/resume Resume a session Pick from recent sessions or resume by name
/rename <name> Rename session Give the session a descriptive name for later

Quick Reference Card

For rapid reference while working, here are the shortcuts you will use most:

Shift+Tab .... cycle modes (Normal / Auto-Accept / Plan)
Esc .......... stop Claude mid-action
Esc Esc ...... rewind menu (undo changes)
Ctrl+G ....... edit plan in your editor
/clear ....... reset context between tasks
/compact ..... free up context space
Up Arrow ..... recall previous prompts

10. Exercises

These exercises build skill progressively. Do them in order. Each one reinforces a concept from this guide.

Exercise 1: Install and Explore

Objective: Install Claude Code and explore a codebase without making any changes.

  1. Install Claude Code using the native installer.
  2. Navigate to any project you are working on (or clone a public repository).
  3. Run claude to start a session.
  4. Enter Plan Mode (Shift+Tab twice from Normal Mode).
  5. Ask Claude to give you an overview of the project.
  6. Ask three follow-up questions about the architecture.
  7. Exit with Ctrl+C.

Success criteria: You completed the entire session in Plan Mode and never switched to Normal Mode. No files were changed.

Exercise 2: The Planning Workflow

Objective: Practice the Explore-Plan-Implement-Commit workflow on a small task.

  1. Start Claude Code in Plan Mode on a project with tests.
  2. Explore: Ask Claude to read a specific source file and explain what it does.
  3. Plan: Ask Claude to create a plan for adding a small improvement (a new utility function, an edge case test, or a documentation comment).
  4. Review the plan. Ask at least one clarifying question. Have Claude revise the plan.
  5. Implement: Switch to Normal Mode. Ask Claude to implement the plan and run the tests.
  6. Commit: Ask Claude to commit with a descriptive message.

Success criteria: You went through all four phases. The plan was revised at least once before implementation. Tests pass.

Exercise 3: The Interview Pattern

Objective: Practice using AskUserQuestion to refine requirements before implementation.

  1. Start Claude Code on a project.
  2. Type: "I want to add input validation to the [pick a form in your project]. Interview me about the requirements first using AskUserQuestion."
  3. Answer Claude's questions honestly, making decisions about edge cases and behavior.
  4. When the interview is complete, ask Claude to write the requirements to a SPEC.md file.
  5. Start a fresh session (/clear or new terminal).
  6. In the fresh session, ask Claude to read SPEC.md and implement the validation.

Success criteria: Claude asked at least 4 questions before starting to implement. The implementation matches your answers.

Exercise 4: Context Providing

Objective: Practice providing context through multiple methods.

  1. Start Claude Code on a project.
  2. Use @ to reference a specific file and ask Claude to explain it.
  3. Run a command that produces an error. Copy the error output and paste it into Claude as context.
  4. (If you have a UI component) Take a screenshot and paste it into Claude. Ask Claude to identify the component in the codebase.
  5. Ask Claude to look at the git diff between your current branch and main.

Success criteria: You used at least three different context methods (@ reference, paste, screenshot, git diff) in a single session.

Exercise 5: Prompt Comparison

Objective: Experience the difference between vague and specific prompts firsthand.

  1. Start Claude Code on a project with tests.
  2. Try this vague prompt: "add tests"
  3. Observe what Claude does. Note whether the result is useful.
  4. Run /clear to reset context.
  5. Try this specific prompt: "Write tests for [specific function] in [specific file] covering these edge cases: [list 3 specific edge cases]. Follow the testing patterns in [reference test file]. Run the tests after writing them."
  6. Compare the quality of the two results.

Success criteria: You can articulate at least three specific differences between the two results.

Exercise 6: Rescue a Derailed Session

Objective: Practice recovering from a session where Claude went off track.

  1. Start Claude Code on a project.
  2. Give Claude a deliberately vague prompt and let it make changes.
  3. When the result is not what you wanted, press Esc Esc to open the rewind menu.
  4. Restore both conversation and code to before the bad changes.
  5. Write a better, more specific prompt and try again.
  6. If the second attempt is good, commit the changes.

Success criteria: You successfully rewound to a clean state and produced a better result on the second attempt.

Exercise 7: Full Feature with Verification

Objective: Combine all the skills from this level in a single end-to-end workflow.

  1. Start in Plan Mode. Explore the codebase to understand relevant patterns.
  2. Use the interview pattern: "Interview me about what I want to build."
  3. After the interview, have Claude write a plan.
  4. Review and revise the plan (push back on at least one thing).
  5. Press Ctrl+G to edit the plan in your text editor. Make at least one manual edit.
  6. Switch to Normal Mode. Implement with explicit verification criteria.
  7. Verify the implementation (tests pass, no build errors).
  8. Commit with a descriptive message.

Success criteria: You used Plan Mode, the interview pattern, verification criteria, and the rewind capability (if needed) in a single session. The final result passes all tests.

11. Pro Tips from Boris Cherny

Boris Cherny is an engineer at Anthropic who works on Claude Code. His publicly documented workflow is one of the most productive approaches to using the tool. These tips are adapted from his practices.

Tip 1: Iterate on the Plan, Not the Code

"Go back and forth with Claude until I like its plan."

Do not accept the first plan Claude produces. Push back. Ask questions. Make Claude consider alternatives. The time spent refining a plan is always less than the time spent fixing a bad implementation.

> I don't like approach #2 in your plan. The singleton pattern will
> make testing harder. What if we used dependency injection instead?
> Revise the plan.

Tip 2: Use Plan Mode for Pull Request Reviews

Before implementing a PR, use Plan Mode to analyze what needs to change. Have Claude read the requirements, explore the codebase, and produce a detailed plan. Only then switch to Normal Mode to implement.

This is the "plan mode for PRs" pattern: the PR implementation starts from a vetted plan, not from Claude winging it.

Tip 3: Color-Code Your Terminal Sessions

When running multiple Claude Code sessions in parallel, use different terminal tab colors for each session. This lets you identify at a glance which session is which, without needing to read the content.

Tip 4: Use Voice Input for Faster Prompting

On macOS, pressing Fn twice activates dictation. Dictating your prompts instead of typing them is significantly faster for longer, more detailed prompts. The extra detail you can comfortably provide via voice leads to better results.

Tip 5: CLAUDE.md is Living Documentation

Check your CLAUDE.md into git. Update it when Claude repeatedly makes the wrong decision. Remove entries when Claude already does the right thing by default. Treat it like code: review it, prune it, test it.

If Claude keeps ignoring a rule in CLAUDE.md, the file is probably too long and the rule is getting lost. Cut aggressively.

Tip 6: Build Custom Subagents for Repetitive Tasks

If you find yourself giving the same set of instructions repeatedly, create a subagent file in .claude/agents/:

---
name: verify-app
description: Runs full verification suite. Use before committing.
tools: Bash, Read, Grep
model: haiku
---

Run the full verification pipeline:
1. Lint: npm run lint
2. Type check: npx tsc --noEmit
3. Tests: npm test
4. Build: npm run build

Report results for each step. Report full error output for failures.

Then use it with: "Use the verify-app subagent to check everything before I commit."

Tip 7: Start Fresh When Corrections Accumulate

If you have corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches. Run /clear and start a fresh conversation with a more specific prompt that incorporates what you learned.

A clean session with a better prompt almost always outperforms a long session with accumulated corrections.

12. Anti-Patterns for Beginners

Anti-Pattern 1: The Hope-Based Prompt

What it looks like:

make it work

Why it fails: "It" is undefined. "Work" is undefined. Claude guesses at both and often guesses wrong.

Fix: Be specific about what "it" is and what "working" means:

Fix the 404 error on the /api/users endpoint. It should return a
JSON array of user objects. Run curl localhost:3000/api/users to
verify it returns a 200 status code.

Anti-Pattern 2: The Kitchen Sink Session

What it looks like: You start with one task, then ask Claude something unrelated, then go back to the first task, then ask about a third thing. The context window fills with irrelevant information.

Why it fails: Context is the most precious resource. Filling it with unrelated topics means Claude loses focus on the actual task.

Fix: Use /clear between unrelated tasks. One task per session. If a session gets tangled, start fresh.

Anti-Pattern 3: Correction Spirals

What it looks like: Claude does something wrong. You correct it. It is still wrong. You correct again. You correct a third time. Context is now full of failed approaches.

Why it fails: Each failed attempt adds noise to the context. After multiple corrections, Claude is working with contradictory instructions and bad examples.

Fix: After two failed corrections, stop. Run /clear. Write a single, better prompt that incorporates everything you learned from the failures. Start clean.

Anti-Pattern 4: Skipping Exploration

What it looks like: You jump straight into implementation without understanding the codebase.

Why it fails: Claude guesses at patterns, conventions, and architecture. The guesses are often wrong, leading to code that works but does not fit the project.

Fix: Always start in Plan Mode. Even five minutes of exploration saves thirty minutes of rework.

Anti-Pattern 5: The Over-Stuffed CLAUDE.md

What it looks like: A CLAUDE.md file with dozens of rules, many of which Claude already follows by default.

Why it fails: When the file is too long, important rules get lost in the noise. Claude ignores your actual instructions because they are buried in obvious ones.

Fix: For each line in CLAUDE.md, ask: "Would removing this cause Claude to make mistakes?" If not, delete it. Keep only what Claude cannot infer from the code itself.

Anti-Pattern 6: Never Using Plan Mode

What it looks like: Every session starts in Normal Mode. Claude immediately starts making changes.

Why it fails: Without a plan, Claude solves whatever problem it thinks you described, which may not be what you actually need. Changes are harder to undo than plans are to revise.

Fix: Use Plan Mode for anything that is not trivially simple. The cost is a few extra seconds. The benefit is dramatically better implementations.

Anti-Pattern 7: Ignoring Verification

What it looks like: Claude implements something, you accept it without running tests or checking the output.

Why it fails: Claude produces plausible-looking code that does not handle edge cases. You ship it, users find the bugs.

Fix: Every prompt should include verification criteria. "Run the tests." "Check that the build succeeds." "Verify with curl." Make Claude prove its work before you accept it.

Anti-Pattern 8: The Infinite Exploration

What it looks like: You ask Claude to "investigate" something without scoping it. Claude reads hundreds of files, filling the context window.

Why it fails: The context window fills with file contents that may not be relevant. Performance degrades. Claude loses track of what it was actually looking for.

Fix: Scope investigations narrowly: "Read the three files related to token refresh in src/auth/." Or use subagents: "Use a subagent to investigate how the caching layer works." Subagents run in separate context windows, keeping your main conversation clean.

Anti-Pattern 9: Using Claude Code as a Search Engine

What it looks like:

what is the syntax for a Python list comprehension?

Why it fails: This consumes context window for something you could Google in two seconds. Claude Code's value is in understanding YOUR codebase, not answering generic programming questions.

Fix: Use Claude Code for project-specific questions: "How does our project handle list transformations? Show me an example from the codebase."

Anti-Pattern 10: Not Naming Sessions

What it looks like: You work on multiple features over multiple days but never name your sessions. When you try to resume, every session is named "explain this function" or "fix the bug."

Why it fails: You cannot find the session you need, so you start over and re-explain everything.

Fix: Use /rename early: /rename auth-refactor or /rename payment-edge-cases. Then resume with claude --resume auth-refactor.

13. Official Documentation Links

Core Documentation

Resource URL Description
Overview code.claude.com/docs/en/overview What Claude Code is, installation, and environments
Quickstart code.claude.com/docs/en/quickstart First-launch walkthrough and first tasks
Best Practices code.claude.com/docs/en/best-practices Prompting patterns, context management, and workflow tips
Common Workflows code.claude.com/docs/en/common-workflows Step-by-step guides for debugging, testing, PRs, and more
CLI Reference code.claude.com/docs/en/cli-reference Complete list of commands and flags

Configuration and Customization

Resource URL Description
Settings code.claude.com/docs/en/settings Configuring permissions, tools, and environment
CLAUDE.md code.claude.com/docs/en/memory Writing effective CLAUDE.md files
Skills code.claude.com/docs/en/skills Creating custom slash commands and workflows
Hooks code.claude.com/docs/en/hooks Automating actions at specific workflow points
Subagents code.claude.com/docs/en/sub-agents Creating specialized delegated agents

Advanced Features

Resource URL Description
MCP Integration code.claude.com/docs/en/mcp Connecting external tools and data sources
Agent Teams code.claude.com/docs/en/agent-teams Multi-agent coordination (experimental)
Headless Mode code.claude.com/docs/en/headless Running Claude Code in scripts and CI/CD
Sandboxing code.claude.com/docs/en/sandboxing OS-level isolation for safe autonomous work

Community Resources

Resource URL Description
Boris Cherny's Workflow howborisusesclaudecode.com Full workflow from an Anthropic engineer
Anthropic Discord anthropic.com/discord Community support and tips
Product Page code.claude.com Demos, pricing, and product details

Quick Reference: The Level 1 Checklist

Before moving to Level 2, make sure you can do all of the following:

Last Updated: 2026-02-20 Compiled from official Anthropic documentation and community best practices Part of the Claude Code Learning Path: Level 1 of 7