It is a helper who can walk into a folder, read the plans, do the work, and show you the result. This is a first-day guide for someone who has only used Claude in a browser.
By Zion Boggan ·
claude, and ask it to look around before asking it to change anything.A chat window can give you advice about a house. Claude Code can stand in the workshop with you. It can read the plans, find the right tool, make a change, run a check, and put the finished piece on the bench for you to inspect.
You are still the owner. Claude Code does not know what “done” means unless you tell it. You decide the job, the boundaries, and whether the finished work leaves the workshop.
| You provide | Claude Code does | You approve |
|---|---|---|
| Goal and limits | Reads files, edits, and runs allowed tools | Changes, evidence, and release |
| Project folder | Works against the files in that folder | Anything public, costly, destructive, or hard to undo |
Use the command for the terminal you are actually using. Installation paths can change, so check the official quickstart and installation guide if a command fails.
# macOS, Linux, or WSL
curl -fsSL https://claude.ai/install.sh | bash
# Windows PowerShell
irm https://claude.ai/install.ps1 | iex
# Homebrew
brew install --cask claude-code
# Windows winget
winget install Anthropic.ClaudeCodeThen check the installation:
claude --versionStart claude. The first run opens a sign-in flow. Use the account you intend to use for this work. Keep passwords and tokens out of project notes.
cd path/to/the/project
claudeThe folder is the workshop. Starting one level too high can expose unrelated files. Starting in the wrong folder can make a correct answer useless.
Screenshot 01 · real capture
The bottom of the session is a small dashboard. The exact labels change between versions, but learn to look for four things before you ask for a long run.
| Read this | Ask yourself | Beginner move |
|---|---|---|
| Working folder | Where am I, and what can this session reach? | If the path is wrong, stop and open the smallest correct folder. |
| Context usage | How much of the session's memory is full? | When it is filling and the helper repeats or forgets limits, finish the current check and start fresh. |
| Usage window | What have I got left for a long run? | Save a large autonomous task when the remaining allowance is low. |
| Mode | Will it ask before acting, or act and report? | Use approval mode for unfamiliar or irreversible work. Use autonomous mode only inside a prepared boundary. |
The folder is the blast radius. Context is the attention span. The usage figures are the fuel gauge. The mode tells you whether the next move comes back to you first. This one line makes context management visible before a mistake becomes expensive.
After installation, your terminal will show a prompt. On macOS or Linux it often ends in $. In PowerShell it may begin with PS. The exact decoration does not matter. It is the line waiting for your instruction.
claude --version. You should see a version number. If you see “command not found,” close and reopen the terminal, then run the installer again. Do not paste a password into the terminal.cd followed by the folder you want to work in. You can drag a folder onto many terminal windows to insert its path. Type claude. A sign-in page may open in your browser.A good first request has four parts:
| Part | Plain-language example |
|---|---|
| Goal | Make the receipt page show the customer’s order number. |
| Bounds | Only edit the receipt feature. Do not change billing or deployment settings. |
| Evidence | Show the diff and run the receipt test. |
| Stop point | Stop before commit or publish and ask me to review. |
Read the relevant files first. Tell me what you found and make a plan.
Only edit the receipt feature.
Do not commit, publish, delete, or change credentials.
When finished, show the diff and the test result. Stop for my approval.If a folder contains rules for the project, they may be kept in a CLAUDE.md file. Treat it like a job-site notice: useful for stable instructions, unsafe for secrets and fast-changing facts.
Preferences are instructions, not hopes. The helper has no idea how you like things done until you say so: your conventions, your tone, what to check before calling a job finished, and what never to touch. Write those preferences down once instead of repeating them every session.
A CLAUDE.md in the project folder is the job-site notice for that project. Put shared conventions there: where the important files live, which command checks the work, how the code is formatted, and what the helper must not change. The project version can be committed so everyone gets the same starting point. It can live at ./CLAUDE.md or ./.claude/CLAUDE.md.
Personal preferences that apply everywhere belong in ~/.claude/CLAUDE.md. That is a good place for a preferred writing tone, a favorite local tool, or a habit such as “show the diff before saying a change is done.” If a preference is only for you and one project, use a local project note such as CLAUDE.local.md and keep it out of version control. The official memory guide explains the available scopes.
Write down facts that should remain useful: “run the receipt test before reporting done” is better than “the test was green yesterday.” Never put passwords, tokens, private exports, or other secrets in an instruction file. Do not put fast-changing facts there either. Written rules do not expire when the fact does, so a note describing last month's setup can confidently mislead the next session. Keep the file short, keep it current, and delete more than you add.
# CLAUDE.md
- Run `node test/receipt.js` before reporting done.
- Keep money formatting changes separate from arithmetic fixes.
- Show the diff and the exact file path.
- Stop before commit, publish, or deletion.Context is finite. A long session accumulates plans, files, command output, and corrections until the useful signal thins out. Start fresh for a genuinely new task. Watch for symptoms: it repeats itself, loses an earlier boundary, forgets the requested tone, or drifts away from the brief. Continuing is not always progress.
Opening one level too high pulls unrelated files into the session. That dilutes attention and can expose work the task never needed. The folder boundary is both a safety control and a focus control. Start in the smallest folder that contains the job, then add another directory only when you can explain why it is needed.
Preferences shape how the work happens, but the written brief decides what done means. State the goal, bounds, proof, and stop point. If the helper cannot point to the evidence or says part of the job is unverified, the finish line has not been reached.
You do not need a complicated system to get the useful part of a larger setup. Keep one main session as the foreman: it holds the plan, asks the questions, and makes the judgement calls. Give narrow mechanical work to a smaller helper or a separate short session. Fetching a page, listing files, or extracting fields does not need your biggest model or your main thread.
Standing preferences belong in the project or user instruction file, not in your memory. If you have to type “show the diff and do not publish” every afternoon, write it down once and keep it current.
Use permissions, deny rules, or hooks for actions that must never happen. A request saying “please do not delete” is guidance. A rule that blocks deletion before it runs is a boundary. Review it, because a hook can outlive the fact it was built around.
Anything destructive, expensive, or outward-facing waits for a person. A phone approval is still a real gate: if the owner does not answer before the timeout, the safe result is no action. The helper can prepare the release and show the proof, but it does not get to decide that the release happened.
When a helper says “done,” ask where the file is, what command produced it, and what output proves it worked. Then check the path yourself. A real session once reported a document written when the file was not on disk. Another declared a product absent because a copy error was swallowed. The fix is not a more confident summary. It is a path, a size, and a direct check.
If a task is a long render, a large build, or a deep re-index, route it to a machine meant for that work instead of making the laptop that holds your session do everything. If the helper cannot prove the other machine is safe and available, it should wait rather than compete for the same resource.
This pattern scales down cleanly. Start with one session and one folder. Add a narrow helper only when the work is mechanical, add a separate machine only when the task is genuinely heavy, and keep the proof and final decision in your hands.
Claude Code may ask to read a file, edit a file, or run a command. That is the moment you decide whether the tool belongs on this job.
Use Shift+Tab to cycle permission modes. More automation is useful after the boundaries are clear, not because a prompt is inconvenient.
Screenshot 02 · real capture
Approving every step is safe and slow. Full autonomy is fast and has a real blast radius. The answer is not to pick one forever. Shrink the blast radius until the amount of autonomy fits the job.
Autonomous operation means that you pre-authorise a bounded set of actions so the helper can work through a task without stopping at every small step. It does not mean giving it a whole computer and hoping a polite instruction survives a long session.
Make one folder containing only what the task needs. Keep credentials, private exports, and unrelated projects outside it. The folder is the boundary: if the helper cannot reach a file, it cannot alter that file.
Pre-authorise the tools the task genuinely needs and deny the rest. For a small receipt fix, that might mean reading the source, editing one file, and running one local test. It does not include changing credentials, deleting originals, publishing, or reaching another machine. This turns permission into a configuration decision made once while calm, rather than a judgement call made repeatedly while impatient.
A hook that blocks an action before it runs is stronger than an instruction asking nicely. Keep those rules few and factual. One real guard blocked a container from starting because a note said it was deliberately switched off. The note was months stale, the container had been running for weeks, and the guard still fired. A hook encodes a fact. It does not know when that fact expires. Review enforced rules or they become a second source of stale truth.
Write the goal, the bounds, the evidence that proves the goal, and the point where the helper must stop. For example:
Goal: fix the receipt total when an item quantity is greater than one.
Bounds: edit only the receipt function and its focused test.
Proof: run the test with quantities 1 and 2, then show the diff and file path.
Stop: do not change money formatting, commit, publish, or touch another folder.An agent left to infer the finish line will invent one. A short brief gives it somewhere safe to stop.
Back up before anything destructive and say how to roll it back. Prefer a copy, a patch, or a reversible move over deletion. For anything outward-facing, expensive, or difficult to undo, route the decision back to a person. Speed is useful only while recovery remains possible.
Autonomy often fails quietly. A build can pass because the changed directory is outside the compiler's source list. An agent can report that it wrote a document while the file is missing on disk. A copy error can be swallowed so an existing product is reported as absent. The habit that catches all three is simple: verify the exact artifact on disk yourself, then exercise the changed behavior with a real case. Ask for command output, not only a summary. A green check is not proof that the change was used.
Tell the helper to stop when it is uncertain, outside the folder, missing evidence, or facing a destructive choice. Ask it to say what is uncertain and what decision it needs. “This part is unverified” is a useful result. Guessing is not.
Use autonomous mode for bounded, repeatable work with a clear proof path. Return to step-by-step approval when the task touches secrets, money, production, another person's data, or a rule you cannot explain.
For a larger job, ask for a plan only. Let Claude list the files, the smallest safe change, and the verification. Then approve the work one step at a time.
Make a plan only. Do not edit files yet.
Read the relevant files, list the smallest safe change, and tell me how you will verify it.Screenshot 03 · real capture
| What looked green | What was actually true | Better check |
|---|---|---|
| The build passed. | The changed directory was outside the compiler’s configured source list. | Confirm scope, then run a direct type check or user-path test. |
| The dashboard was current. | It and the live router had current records but zero shared item identifiers. | Use the component that controls the action and reconcile records by ID. |
| The transcript was quiet. | The desktop worker was still actively working. | Watch process, artifact, service, or state signals that belong to the work. |
| The board said files existed. | The files were on a different machine and had not been checked at their real path. | Check the exact artifact, size, receipt, and user-facing result. |
| Command | Use |
|---|---|
claude | Start a session in the current folder. |
claude -c | Continue the latest conversation in that folder. |
/help | Show commands inside a session. |
/clear | Start fresh when the conversation has too much history. |
/exit | Leave the session. |
claude doctor | Check the installation when something seems wrong. |
Point Claude Code at a folder you understand and start with a read-only request. Try a copy or sample before an important original.
Screenshot 05 · real capture
The shift is simple: stop asking what to type into a chat window and start handing over a real job with a clear bench check.