Claude
Code.

Claude Code is more than a chat box that suggests snippets. It can work with the files in a project and use tools to act on them. Give it a task such as “find why this button fails,” and it can search the project, read the relevant files, change code, run a test, inspect the result, and try again.

The basic cycle is:

1. Understand: Claude reads the files and asks questions if the goal is unclear.
2. Act: It edits files or runs a command.
3. Check: It tests the result and reports what happened.
4. Repeat: You give feedback, and it improves the work.

You remain the project owner. Claude can be wrong about requirements, produce code that fails outside its test environment, or make a visual design you do not like. A useful habit is to ask, “What changed, how did you test it, and what still needs checking?” Then verify the result yourself.

The words you need first

Claude Code is available in a terminal, the Claude desktop app's Code tab, supported editors such as VS Code, and a browser-based cloud environment. The core work is similar; the interface and location where commands run are different. A local session works with files on your computer. A cloud session works in an isolated environment connected to a repository.

What Claude can and cannot see

Claude sees files and tool results that its session can access. It does not know every detail of your business, your taste, or the result you imagined unless you explain them. When it can use a shell, it may be able to run many of the commands you can run. Permission controls determine when it must ask first. A separate browser tab or private account is not automatically part of a local project.

Give Claude the smallest useful scope. Open the folder for the project you intend to work on. Tell it which files or areas matter, and name anything it should leave alone. This makes the work easier to review.

A quick exercise

Before asking for edits, ask: “What can you see in this project folder? Summarize it in five bullets and do not change anything.” This teaches you what Claude thinks the project is.

You need an account with Claude Code access and an internet connection. The free claude.ai plan does not include Claude Code. Individuals commonly use a Pro or Max subscription. Teams may use Team or Enterprise access. The Anthropic Console is another route for API-based billing, and organizations can use supported cloud providers. Availability depends on country, plan, organization settings, and the interface you choose.

Choose an account route

For the desktop walkthrough in Chapter 4, use an eligible Pro, Max, Team, or Enterprise account. Check the current price and your organization's access rules before paying or inviting colleagues. A subscription and an API key are separate billing routes. If an ANTHROPIC_API_KEY environment variable is set, the terminal version can ask to use it instead of the usual browser sign-in. Check the active account with /status when billing matters.

Choose an interface

Desktop app: The simplest starting point if you do not use a terminal. Open the Code tab, choose a folder, and work through a visual conversation. The app includes what it needs for this experience. Mac and Windows are the straightforward desktop paths; Linux desktop support is in beta.

Terminal CLI: The most direct route for developers and advanced users. It runs in a terminal and fits naturally with Git, build tools, and scripts. “CLI” means command-line interface.

VS Code extension: An add-on inside the VS Code editor. It gives you a Claude panel beside your files. The extension does not install the claude command for your terminal.

Browser cloud session: Useful when your project is in GitHub and you want the work to continue away from your computer. Connect GitHub, select a repository and branch, and review the resulting changes. The cloud environment does not automatically have your local files and tools.

Which one should you pick?

• Choose Desktop for your first project if you are new to development.
• Choose CLI if you already use a terminal or want scripts and automation.
• Choose VS Code if that is where you already work.
• Choose Cloud for a GitHub-based task you want to run remotely.

You can use more than one interface. Start with one so you learn the workflow without learning several interfaces at once.

Desktop: the route with no terminal on Mac or Windows

1. Visit Anthropic's Claude desktop download page from the source notes at the back.
2. Choose the installer for your computer. Open the downloaded file and follow the on-screen installation steps.
3. Open Claude from Applications on a Mac or the Start menu on Windows.
4. Sign in with your eligible account.
5. Click Code at the top. The Chat tab is general conversation; the Code tab works with project files.

If Code asks you to upgrade, verify that you signed in to the account that has the subscription or organization seat. If your organization manages Claude access, an administrator may also need to enable the feature.

Terminal: a step-by-step introduction

The terminal is a text window for giving your computer commands. On a Mac, press Command + Space, type Terminal, and press Return. On Windows, search the Start menu for PowerShell. On Linux, search your applications for Terminal. A command is the text you type; press Enter to run it.

The current native installer supports macOS 13+, Windows 10 version 1809+ or Windows Server 2019+, Ubuntu 20.04+, Debian 10+, and Alpine Linux 3.19+. You need at least 4 GB RAM, a supported x64 or ARM64 processor, internet access, and an Anthropic-supported country. The native installer does not require Node.js.

Copy the command for your system. Copy only the command inside the box:

Mac, Linux, or Windows Subsystem for Linux:

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

Windows PowerShell:

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

Windows Command Prompt:

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

These commands download and run Anthropic's installer. If your organization requires a package manager, Anthropic also provides Homebrew, WinGet, Linux package, and npm options. The npm route requires Node.js 22+ for a supported installation; do not run a global npm install with sudo.

When installation finishes, close the terminal, open a new one, and type:

claude --version
claude doctor

The first command should print a version number. The second checks installation health. If the first says claude is not found, see Chapter 13.

To start, open the folder you want to work in. In a terminal, cd means “change directory.” For a folder called my-first-project in Documents:

cd ~/Documents/my-first-project
claude

In Windows PowerShell:

cd "$HOME\Documents\my-first-project"
claude

Use your actual folder path if it is elsewhere. The first launch opens a browser to sign in. If a remote terminal cannot receive the browser callback, Claude may ask you to copy a login URL or paste a code.

VS Code: the editor route

VS Code is a separate app for viewing and editing files. Its “Extensions” area is an app store for add-ons. Open a project folder in VS Code, click the Extensions icon in the sidebar, search for Claude Code, install the official extension, open its Claude panel, and sign in. If you also want to type claude in VS Code's built-in terminal, install the standalone CLI above.

Browser: the cloud route

Sign in at claude.ai/code, connect a GitHub account, choose a repository, and submit a task. GitHub is a service for storing and collaborating on Git projects. A repository is the project's tracked files. Cloud sessions run away from your computer and usually push a branch for you to review. Team and Enterprise organizations may need administrator setup before members can connect GitHub.

Installation checkpoint

You are ready to continue when you can open a Code session, see the correct account, and select the project folder or repository you intend to use.

This chapter makes a small task tracker. It is deliberately modest: one page, no payments, no logins, and no external database. You will learn the full cycle of planning, building, previewing, improving, and checking without needing to write code yourself.

Prepare the folder

1. Open your computer's Documents folder.
2. Create a new folder named my-first-task-tracker. On a Mac, use Finder's File → New Folder. On Windows, use File Explorer's New → Folder.
3. In Claude's Code tab, choose Local, then Select folder and choose the folder you made.
4. Confirm the folder name shown in the session before asking for an edit.

The folder may be empty. Claude will create files inside it. If you use the CLI, change into that folder with cd and start claude.

Choose how Claude asks for approval

Select Manual or Ask permissions for your first session. In this mode, Claude proposes file edits and commands, and you decide whether to accept them. A diff shows lines it intends to add or remove. You do not need to understand every line yet. Check the file names, the kind of action, and whether the change fits the project. If an action is unclear, ask Claude to explain it.

Ask for a plan

Copy this prompt into the message box:

Build a small task tracker website in this empty folder. I want to add tasks, mark them complete, delete them, and keep them after I refresh the page. Make it easy to use on a phone. Keep the first version simple: no accounts, paid services, or external database. Before writing files, tell me what you will build, what files you will create, and how I can preview it.

Claude may propose HTML, CSS, and JavaScript. HTML holds the page content, CSS controls its appearance, and JavaScript makes the controls work. It may use browser storage to remember tasks on this computer. You do not have to choose a framework or database for this exercise.

Read the plan. If it includes extra services or complicated setup, say: “Make the first version simpler and explain why any extra tool is needed.” When the plan matches the goal, reply: “Build the first version.”

Preview the result

When Claude finishes, ask: “Show me the files you created and tell me exactly how to open the app.” It may open a preview inside Desktop, give you a local address such as http://localhost:3000, or identify a file you can open in a browser. A local preview is on your computer; it has not been published online.

Try the app yourself:

1. Add a task.
2. Mark it complete.
3. Delete a task.
4. Refresh and check that saved tasks remain.
5. Make the browser window narrow and check that buttons and text still fit.

If something fails, describe the action and result: “I added a task, refreshed, and the task disappeared.” Paste any visible error. That is enough information for Claude to investigate.

Improve it once

Ask: “Add a filter for All, Active, and Completed tasks. Explain how you tested it.” Try each filter. If the design feels wrong, describe one specific issue at a time, such as “The Add button is too small on my phone.”

Finish with: “Compare the app against my original request. Fix clear bugs, run the checks available in this project, and tell me what you could not verify.”

Save and return

Your project is the folder my-first-task-tracker. Copy that folder to another location before a major change. Ask Claude to create a README.md file, a short set of instructions explaining how to open the app. In Desktop, reopen the project and its conversation when you return. In the terminal, claude -c continues the latest session in the current directory.

Success checklist

• The app opens.
• The four main actions work: add, complete, delete, and refresh.
• The layout remains usable on a narrow screen.
• You know where the files are and how to preview them again.
• You can explain, in one sentence, what Claude built and what still needs work.

The most useful skill is not a clever one-line prompt. It is running a clear cycle: define the task, let Claude inspect, review a plan when needed, approve the work, and verify the outcome.

Give a complete task

A good request has four parts:

1. Goal: What should change?
2. Context: Where does it happen, and who uses it?
3. Constraints: What should stay the same or remain untouched?
4. Verification: What should Claude check before calling it done?

For example:

Goal: Make the task list easier to use on a phone. Context: The Add button currently wraps below the input on narrow screens. Constraint: Keep the desktop layout and existing task behavior. Verification: Preview at phone and laptop widths, then summarize what you changed.

Compare that with “Make it better.” The second request leaves Claude to guess what matters. You do not need technical words; you need observable details.

Four common workflows

Explore a project: “Explain how this project works. Name the main files and how to run it. Do not edit anything.” Use this before changing an unfamiliar project.

Build a feature: “Add [feature]. First show a plan, then implement it, run relevant checks, and summarize the changes.” Use this when you know what users should be able to do.

Fix a bug: “When I do [action], [actual result] happens. I expected [expected result]. Reproduce it if possible, find the cause, fix it, and check the same steps again.” Include an error message or screenshot when you have one.

Review work: “Review the current changes for bugs, missing checks, security problems, and confusing behavior. Give specific findings with file names. Do not edit until I approve.” Use this before merging or publishing.

Keep tasks small enough to inspect

Ask for one meaningful improvement at a time. For a large request, ask Claude to map the project and propose milestones. Review the first milestone before moving to the next. A small verified change is easier to trust than a large unexplained rewrite.

You can interrupt a running session and steer it: “Stop. Keep the existing design and only fix the mobile button.” Corrections are part of normal use.

Use visual evidence

For visual problems, attach a screenshot or sketch when your interface supports it. Point to the specific element, name the screen size, and say what should be different. “At phone width, the navigation covers the title; place it below the title” is a useful request. “Make it premium” is a taste judgment that needs examples or more detail.

Know what “done” means

Claude's final message is a report, not proof. Ask what tests ran, which manual flows were checked, and what remains uncertain. Then open the app and try the important paths yourself. When you publish a site, run a business process, or handle private information, increase the depth of review.

Claude Code can read files, edit them, and run commands. That makes it useful, and it makes your approval choices important. A safe setup is one you understand well enough to recognize when an action goes beyond your task.

Understand a permission request

When Claude wants to use a tool, the interface may show what it proposes and ask for your choice. Read the command or file path before accepting. If the request is unfamiliar, ask Claude what it will do and why. A command that installs dependencies may be reasonable for a new app; one that deletes a folder, uploads files, or changes account settings deserves closer inspection.

Claude Code offers permission modes that vary by interface and organization policy:

The exact labels and available modes change across the CLI, desktop, and managed accounts. In a terminal session, Shift + Tab cycles modes; /permissions lets you inspect or change permission settings. A mode is not a guarantee that Claude understands your business intent.

Set a clear boundary before a task

Tell Claude the folder it should use, the change you want, and the actions that require your approval. For example:

Work only in this project folder. Explain any package you want to install. Ask before deleting files, changing account settings, deploying, or using external services. Build the feature, run local checks, and show me the changed files.

For a first project, keep the default approval behavior. Use Plan mode when the project is unfamiliar. Review the plan, then allow implementation. Inspect the final diff, which is the view of exact file changes.

Treat private data as a deliberate choice

Before opening a folder, ask whether it contains passwords, API keys, customer records, contracts, or personal data. Claude Code sends relevant prompts and tool context to the selected model service so it can perform the task. A local session does not mean all processing happens only on your computer. Read your plan's data terms and your organization's policy before using sensitive files. Keep secrets in approved secret storage, rather than pasting them into prompts or putting them in a project instruction file.

If Claude needs sample data, give it fake or anonymized examples. If a task needs production data, use a limited copy and a reviewed access method. Remember that session transcripts may be stored locally; secure the computer and avoid sharing transcript files.

Recognize instructions hidden in files

A web page, README, issue, or data file can contain text that tells an AI assistant to ignore your request, run a command, or reveal information. Treat that text as project data unless you have verified that it is an instruction you actually want to follow. If Claude proposes an action that came from a file rather than from you, pause and inspect the source.

A five-minute safety routine

1. Choose the correct project folder and account.
2. State what Claude may change.
3. Read approval prompts, especially commands and external connections.
4. Review the diff and run the important path yourself.
5. Keep a copy or Git checkpoint before a large change.

You can use Claude Code without becoming a programmer, but you should know how to recognize a changed file and a working result.

Read a project's map

Ask: “Show me the main files, what each one does, and how to run this project. Explain it for a beginner.” Claude can identify files such as package.json, which often lists a JavaScript project's scripts and dependencies, or a README.md, which often gives setup steps. It can also explain whether the project already has tests.

Do not worry about memorizing filenames. The useful distinction is between the project files you want changed, generated files created by tools, and private files such as .env that may hold secrets.

Inspect edits in a diff

A diff marks removed lines with a minus and added lines with a plus. Review it by asking:

• Did Claude change the files you expected?
• Did it remove something you still need?
• Did it introduce a new dependency or external service?
• Are there obvious placeholders, fake results, or unexplained shortcuts?

In the desktop app or VS Code, use the changes panel. In a Git project, a developer can run git diff. Ask Claude to walk you through a confusing section of the diff in plain language.

Use Git as a checkpoint system

Git records versions of a project. A commit is a named checkpoint; a branch is a separate line of work. A remote service such as GitHub can hold a copy and enable review. Claude can help create commits, but you should decide when a change is worth keeping.

If you are new to Git, start with this request:

Explain the current Git status in plain English. Show me what changed. Do not commit yet.

Before a risky change, ask Claude to create a checkpoint or make a copy of the folder. If the change is wrong, first ask Claude to undo only its changes from this task and show the diff. Do not run a broad reset command just because it appears in an answer; it might erase work you did earlier.

Know the three levels of checking

A command passes: A build, lint check, or automated test exits successfully. This catches many errors but cannot prove the experience is good.

A user flow works: You open the app and try the task a real user would perform. For a form, enter data, submit, refresh, and check what happens.

The result meets your goal: Read the page or output, inspect the design, and compare it with your original brief. A technically valid app can still solve the wrong problem.

Ask Claude to report which checks it actually ran, their results, and which checks it could not run. “The code looks good” is weaker than a named check with an outcome.

When a change breaks something

1. Stop adding features.
2. Tell Claude the last action that worked and the first action that failed.
3. Paste the exact error or attach a screenshot.
4. Ask it to find the cause and propose the smallest fix.
5. Run the same steps again after the fix.

If several attempts fail, return to the last working checkpoint and rebuild the feature in smaller parts. This is normal engineering work, not a failure of the whole project.

A session is a conversation about a project. Claude can refer to messages and tool results in that session, but a long conversation eventually reaches a context limit. Think of context as the working material currently in view. It is useful, but it is not an unlimited record of every decision.

Continue or start fresh

Continue a session when you are still working on the same task and its recent decisions matter. Start a new session for a different goal, a major change of direction, or when earlier discussion is cluttering the work. In the CLI, claude -c continues the most recent session for the project. claude -r lets you choose a prior session. Within Claude Code, /resume helps return to earlier work. Desktop and cloud provide session lists in their interfaces.

When returning after a break, ask: “Summarize our goal, the files changed, the checks completed, and the next decision.” Verify the summary against the project state. The files are the source of truth for what was actually saved.

Understand compaction

As a session grows, Claude Code may summarize older conversation so the current task fits into context. This is called compaction. Important project rules should therefore live in project files or a concise instruction file, not only in an early chat message. Use /context to inspect context use in the CLI. If Claude repeatedly forgets a constraint, restate it in the current task or put a stable rule in CLAUDE.md.

Write useful project memory

CLAUDE.md is a Markdown file Claude Code can read as project guidance. It can live at the project root; a personal version can hold preferences across projects. In the CLI, /init can help create one. Some setups also support AGENTS.md instructions. Keep instructions short, current, and specific. A rule that describes the project's actual commands is more valuable than a long motivational document.

For example:

# Project guidance
- This is a simple task tracker for nontechnical users.
- Run `npm test` after changing task behavior.
- Keep the interface usable at phone width.
- Ask before adding a paid service or changing authentication.

Change the example to match your real project. Do not put a password, token, or private key in this file. Project instructions guide Claude; they are not a security boundary or a substitute for review.

Claude Code can also keep auto memory: notes it writes about recurring preferences, feedback, or project facts. Treat these as drafts of what Claude believes, not as verified project documentation. Inspect and correct them through the memory controls when they affect future work. Written project guidance remains the right place for rules the team has agreed to follow.

Separate facts from preferences

Put durable facts in project guidance: how to run tests, where source files live, naming conventions, and required review steps. Put the immediate goal in the current prompt: the specific feature, bug, or design change. This keeps instructions from becoming a confusing list of old tasks.

Settings control how Claude Code behaves across sessions. Most beginners can leave defaults alone. Change settings when you can name the problem they solve.

Where settings live

The CLI reads JSON settings at several levels. A personal file at ~/.claude/settings.json applies to your user account. A project can share .claude/settings.json with the team. A local project file at .claude/settings.local.json is for settings you do not intend to share. Organizations may also apply managed settings with higher priority.

JSON is a strict data format: property names and text values use double quotes, commas separate entries, and comments are not allowed. Ask Claude to explain a setting and show the smallest valid change before editing a configuration file. Commit shared settings only after teammates review them.

What to configure first

Permissions: Decide which commands or tools should ask, be allowed, or be denied. Keep these narrow. Review them after adding a new integration.

Model: Select a model appropriate for your plan, speed, and task. Use /model to inspect available options in the CLI. A fast model can help with routine edits; a more capable one may suit complex debugging or architecture. Availability and names change.

Usage: Use /usage to view subscription use where supported. API users should also monitor provider billing. Repeated large prompts, long sessions, and tool-heavy tasks consume more capacity.

Project guidance: Add a concise CLAUDE.md when you notice the same project facts need to be repeated. Review it when the build or team process changes.

Keep account and billing routes clear

In the CLI, /status shows session and account details. If you have both a subscription and an API key, confirm which route is active before a long task. An environment variable such as ANTHROPIC_API_KEY can affect authentication. Teams should document the billing route and data policy they expect members to use.

You can finish the beginner project without a terminal. Learn this chapter when you want direct access to project commands, Git, scripts, or remote machines.

The four parts of a terminal command

In claude --version, claude is the program, and --version is an option that asks it to print its version. In cd ~/Documents/my-first-project, cd changes the current folder, and the rest is the destination. The terminal usually shows your current folder before you type. Press Enter to run a command; do not type the dollar sign that some tutorials show at the start of a sample line.

Open a terminal, move into the project folder, then run claude. Claude Code starts an interactive session. Type a request and press Enter. When Claude proposes a tool action, read the prompt and choose the appropriate response. Type /help to see the commands available in your installed version.

Commands you will actually use

Inside an interactive session, a slash command controls the session rather than asking Claude a normal question. Useful examples include /help, /status, /usage, /model, /permissions, /context, /resume, /init, and /mcp. The commands offered can vary by version and account.

A complete terminal example

Suppose a working site has a form that does not show a success message. You could enter:

claude
> Explain how the contact form works. Do not edit yet.
> Plan the smallest fix for the missing success message.
> Implement the fix, run the relevant checks, and tell me what to verify manually.

The > marks above represent your successive messages in the Claude session; do not type them as shell commands. Separate exploration from editing when you are new to the codebase.

One-off output and scripts

claude -p is useful when you want a single answer in a pipeline or scheduled process. Developers can choose machine-readable output formats and set a maximum API budget for a run. Start with a read-only task such as summarizing a project or checking a changed file. Before letting a script edit files, decide how it will authenticate, which folder it can touch, how it handles errors, and who reviews the output. API usage can create charges even when an interactive subscription route is available.

The core tool is enough for most projects. Extensions are useful when you repeatedly need the same instructions, a specialist role, or access to another system. Add one at a time so you can tell what changed.

Skills: reusable instructions for a task

A skill is a set of instructions Claude can load when a task calls for it. For example, a “release checklist” skill could tell Claude how your team checks a build and writes release notes. A project skill can live in .claude/skills/<skill-name>/SKILL.md; a personal skill can live under ~/.claude/skills/. The file is Markdown, so the main work is writing clear steps, inputs, and completion criteria.

Use a skill when the same process applies across many tasks. Use CLAUDE.md for short facts Claude should always know. An enormous always-on instruction file can distract Claude and consume context.

Subagents: focused assistants

A subagent can work on a focused piece of a larger task in its own context and return findings to the main session. This is helpful when one assistant should research a test failure while another inspects UI code, or when you want a separate reviewer. In the CLI, agents can be defined under .claude/agents/ or a personal agents folder. Give a subagent a narrow job and a clear output. Parallel work may use more capacity and can create conflicts if multiple agents edit the same files.

Example request:

Ask a separate reviewer to inspect the proposed checkout change for edge cases. Have it report findings with file names. Keep the implementation in the main session.

MCP: access to external tools and data

Model Context Protocol, or MCP, is a way to connect Claude Code to tools outside the project, such as documentation, databases, issue trackers, or design systems. A server supplies tools; Claude can call them subject to its permissions and your account's access. A connection does not automatically mean every tool is safe or every data source is trustworthy.

A developer can add an HTTP MCP server with claude mcp add --transport http NAME URL, then inspect connections with claude mcp list or /mcp. The command's exact arguments depend on the server. Local scope applies to the current project by default; user or project scope can make a connection available more broadly or share it through a project file. Before connecting, check who operates the server, what data it receives, and whether its tool permissions match your task.

Hooks: automatic actions at specific moments

A hook runs an action when a Claude Code event occurs. A team might automatically run a formatter after file edits or record a notification when a session ends. Hooks are more predictable than merely asking Claude to remember an instruction, because the configured action is triggered by an event. They can also run unwanted commands if misconfigured. Test a hook in a disposable project and keep its command small and understandable.

Plugins: packaged capabilities

A plugin can bundle skills, subagents, hooks, or MCP connections. In supported versions, /plugin opens plugin discovery and management. Inspect a plugin's source and permissions before installing it, especially if it can reach external accounts or run commands. For a beginner, add plugins only after the core workflow is comfortable.

Advanced use is less about writing a longer prompt and more about controlling scope, keeping work reviewable, and choosing the right environment.

Work in branches and worktrees

When a project uses Git, make a branch for a meaningful change. The main branch stays stable while you inspect the new work. A worktree is an additional folder connected to the same repository, usually on a different branch. It lets separate tasks run without constantly switching the files under one session.

Use a worktree when you want to compare two approaches, keep a long-running task isolated, or run more than one agent against the same repository. Decide which folder and branch each task owns. Review and merge completed work deliberately; do not assume parallel edits will combine cleanly.

Use cloud sessions for remote repository work

A cloud session runs in a separate environment connected to a GitHub repository. It is useful for a task you want to continue while your computer is unavailable, or for work that should end as a branch or pull request. A pull request is a review page comparing a proposed branch with the target branch. Inspect that comparison and run the application before merging.

Cloud sessions need explicit setup for secrets, dependencies, and repository access. A local file on your laptop will not appear there simply because it was mentioned in a prompt. Ask Claude to list what it could run in the cloud environment and what it could not verify.

Run a background task when you can review it later

Some Claude Code interfaces can keep a task running in the background while you work elsewhere. This suits a bounded job such as investigating a flaky test or preparing a review. Give it a narrow scope, ask for a written summary and checks, and return to inspect the files before accepting its work. If you use multiple background tasks, isolate their folders or branches so two agents do not overwrite each other's edits.

Plan, implement, and review in passes

For a substantial feature, use three passes:

1. Plan: Map the existing design, list files likely to change, identify risks, and propose milestones.
2. Implement: Complete one milestone, run relevant checks, and show a concise diff summary.
3. Review: Have Claude or another reviewer inspect the result for bugs and missing cases; then test the user flow yourself.

You can ask for a second model or separate session to review an implementation. A fresh review can catch assumptions carried through the first session, but it still needs concrete evidence and human judgment.

Use test-driven work where it helps

For behavior that has a clear expected result, first describe examples that should pass and fail. Have Claude add or update a meaningful test, show that it catches the original bug, implement the fix, and run the test again. This is especially useful for calculations, data transformation, permissions, and regression bugs. For visual design, a preview and manual inspection are usually more informative than a test that only checks whether an element exists.

Automate only after the manual task works

Claude Code can run from scripts and CI systems using print mode and supported integrations. A reliable automation needs a fixed input, clear output, bounded permissions, a failure path, and an owner who reviews results. Good early examples are summarizing a daily build failure or reviewing a proposed change. Publishing, deleting, charging, or changing customer data should have explicit approval and rollback steps.

Developers building their own tools around Claude Code can use the Claude Agent SDK to control sessions programmatically, receive structured output, and integrate tool use into an application. This is a separate development project, beyond the beginner workflow. First prove the task with an interactive session; then encode its inputs, permissions, and review steps in the program.

Before automation, write down:

• What triggers the run and which files or services it can access.
• Which account pays for the usage.
• What counts as success and how a failure is reported.
• Whether it may edit, commit, or open a pull request.
• Who approves the final change.

Roll out Claude Code to a team

Begin with one low-risk repository and a small group. Agree on a shared CLAUDE.md with build commands and review rules. Set organization permissions, data handling, and billing centrally. Teach people to inspect diffs and test outcomes. Keep examples of effective prompts for your own codebase. After a few weeks, revise the guidance from actual failures and successes.

The team goal is repeatable work that another person can understand and verify. Faster code generation is useful only when review and ownership keep pace.

The five patterns below appear often in public Claude Code examples and are useful practice projects. They are not a ranked list of the “most viral” projects; public attention changes quickly, and likes do not prove that a project works. Each example can start small and grow into a serious application. If you have never coded, use the desktop Code tab and create a separate empty folder for each project.

Project 1. A personal website or landing page

What you make: A one-page site for a portfolio, event, service, or small business. It can have a headline, services or projects, a frequently asked questions section, and a contact action.

Why it is a good first project: You can see results immediately and give feedback in ordinary language. The hard part is deciding what the page should say and who it is for.

Prepare: Write the audience, the offer, three facts you want included, your preferred colors, and the action a visitor should take. Collect any images you have permission to use. If you do not have images, ask for a clean text-first version.

First prompt:

Build a responsive one-page website in this empty folder for [audience]. It should explain [offer], include [three facts], and end with a clear contact action. Use plain language and a calm visual style. Ask me for missing copy before inventing business claims. Show me how to preview it locally and test it at phone and laptop widths.

Improve it: Ask Claude to make one change at a time: clearer headline, better mobile spacing, more readable contrast, faster loading, or a working contact link. Replace placeholder copy yourself. If a form sends data somewhere, verify where it goes and what it stores.

Done when: A stranger can understand the offer in a few seconds, links and buttons work, text is true, and the page is readable on a phone.

Project 2. A personal dashboard

What you make: A screen that organizes information you check repeatedly, such as tasks, reading, a home budget, or exercise notes. Start with manual sample data rather than connecting accounts.

Why it is useful: Dashboards turn scattered details into an overview. Public builders frequently show custom dashboards because they can fit one person's exact routine.

Prepare: List the three questions the dashboard should answer. For example: “What needs attention today?”, “What changed this week?”, and “What is overdue?” Decide whether the data is private.

First prompt:

Create a simple personal dashboard in this folder. Use sample data only. Show today's tasks, items due this week, and a small progress summary. Make the labels easy for a nontechnical user to understand. Explain where the sample data lives. Let me preview the dashboard before we add real data.

Improve it: Add one data source at a time. Ask what permissions an integration needs and where credentials will be stored. For a money-related dashboard, independently verify totals and calculations.

Done when: The dashboard answers your three questions quickly, handles missing or unusual data, and does not expose private information.

Project 3. A “year in review” from your own data

What you make: A private report of patterns in a data export: books read, workouts, photos, messages, or spending categories. A popular form is a “Wrapped” style visual story. Start with data you own and are allowed to process.

Why it is useful: Claude can help clean a messy export, calculate summaries, and present the story in a small app or report. This combines data work with design.

Prepare: Export the data from the original service. Remove fields you do not need, especially names, phone numbers, addresses, and message bodies. Keep a copy of the original export so you can compare results.

First prompt:

Inspect this sample data export and explain its columns in plain English. Do not upload it to another service. Propose five interesting, accurate summaries and show how each would be calculated. Wait for my choice before making a visual report.

After selecting summaries:

Build a local, private year-in-review page from the approved summaries. Show source counts and how each number was calculated. Do not invent missing values. Add a clear note when the data is incomplete.

Done when: Counts match a spot check of the raw export, private fields stay out of the report, and the visuals explain rather than distort the data.

Project 4. A small browser game

What you make: A game such as a maze, quiz, puzzle, or simple space explorer. It should have one main mechanic, a start screen, instructions, and a clear way to finish or restart.

Why it is useful: Games make requirements and testing concrete. A public demo may look impressive while controls, scoring, or edge cases are broken, so this project teaches verification.

Prepare: Write the rules in five bullets. State whether the game should work with keyboard, mouse, or touch. Choose a modest first version; animations and sound can come later.

First prompt:

Build a simple browser puzzle game in this folder. The player should [action], win when [condition], and be able to restart. Include on-screen instructions and keyboard controls. First make a playable version with basic shapes. Run the project and tell me exactly how to test winning, losing, and restarting.

Improve it: Play several rounds and describe any confusing controls or unfair situations. Ask Claude to fix gameplay before adding visual effects. If it uses outside art or audio, check rights before selling the game.

Done when: A new player understands the rules without your help, the game can be won and restarted, and it works at the intended screen sizes.

Project 5. A repetitive-work helper

What you make: A small tool that renames files, formats notes, generates recurring reports, or organizes a folder. Start with a dry run that shows what it would do.

Why it is useful: Saving five minutes on a task you repeat every week can matter more than a flashy demo. Public builders often share small personal tools because they solve a precise annoyance.

Prepare: Gather five representative inputs and write the exact desired output for each. Include one awkward case, such as a missing date or duplicate filename. Work on copies of the files.

First prompt:

In this folder, build a helper that [specific repetitive task]. Use these five input and output examples as the rule. First create a preview mode that lists proposed changes without applying them. Do not overwrite original files. Explain how I can check the results and undo a run.

Improve it: Test a small batch, inspect every output, then add error handling. Keep a log of what changed. If the helper sends messages or changes external accounts, require a final human review before each run.

Done when: It handles normal and awkward examples, previews changes clearly, leaves originals intact, and has a reliable recovery path.

What all five projects teach

Pick a real problem, give Claude concrete examples, make a small first version, test the user path, and iterate. That is the practical core of “vibe coding.” The rest of Claude Code (debugging, review, permissions, sessions, extensions, and automation) helps turn an exciting first draft into dependable work.

“I cannot see the Code tab”

Check that you installed the Claude desktop app, opened it rather than the general chat page, and signed in to an eligible account. Team access can depend on an administrator's settings. Update the app, sign out and back in, and check the current plan eligibility if the tab remains unavailable.

“The terminal says claude: command not found”

Close and reopen the terminal after installing. Run claude --version again. If it still fails, use the official installer instructions for your operating system and run claude doctor when the command becomes available. Confirm you used the right shell: a PowerShell command belongs in PowerShell, and a Mac/Linux command belongs in their terminal.

“The login or billing account looks wrong”

Use /status in the CLI to see the active route. Check whether your environment has an API key set and whether your organization supplied credentials. If you expect subscription usage, confirm you signed in to the subscribed account. If you expect API billing, check the Console or provider project.

“Claude changed too much”

Stop the session and inspect the diff. Identify the specific files or behaviors to keep and the changes to undo. Ask for a narrower fix and a plan before another edit. If you have a Git checkpoint, compare against it. Avoid an unreviewed global reset.

“The app does not run”

Ask Claude for the exact command it used to start the app, the error it received, and the dependency it expects. Paste the error back into the session. Make sure you are in the project folder. If a package install failed, check your network and installation method. Do not keep adding features until the basic run command works.

“Claude says tests passed, but the result is wrong”

Describe the actual user flow and show an example of the wrong output. Automated tests only cover what they were written to check. Ask Claude to add a test for the missing case, fix the behavior, and rerun it. Then repeat the manual flow.

“Claude forgot an earlier decision”

The session may have grown and compacted. Restate the current requirement, point Claude to the relevant file, and update CLAUDE.md if the fact is durable. Starting a fresh session with a short written brief can be faster than untangling a long conversation.

“A command asks for permission and I do not understand it”

Do not approve yet. Ask Claude to explain the command's inputs, output, files touched, external connections, and how to undo it. If the explanation is unclear, choose a narrower approach or perform the step manually with help.

“I reached a usage limit or unexpected cost”

Check /usage and /status where available. Confirm whether you are using a subscription, Console API billing, or a provider account. Split a large task into smaller milestones and avoid repeatedly sending the same large files. For scripted runs, set a budget and monitor provider billing.

“Claude cannot access my GitHub repository or other service”

Check that the service is connected to the account and interface you are using. A local folder, a cloud repository, and an MCP connection are different access paths. Confirm repository permissions and organization policies. Never paste a credential into chat as a quick fix.