You have an idea, a laptop, and no idea what happens next. This is the whole thing in one place: the setup, the loop that actually works, the exact words that get good output, and the mistakes that cost us real days so they never cost you any.
Written by a self-taught engineer who has shipped 40+ products with this tool, for the friend who keeps saying they would build it if they knew how.
Kalispell, Montana
Claude Code is a very fast engineer who has read every manual ever written and knows nothing about you, your project, or what you said yesterday.
It types faster than you and it will happily build the wrong thing at full speed. Every habit in this guide fixes one half of that sentence: give it context, and make it prove the work. Do those two things and it feels like a senior teammate. Skip them and it feels like a slot machine.
In order. Do not skip the fourth one, it is the step that makes every step after it work.
You need Node 18 or newer first (nodejs.org, the green button). Then one line in your terminal. Terminal means Terminal on a Mac, PowerShell on Windows.
npm install -g @anthropic-ai/claude-code
Claude works inside the folder you launch it from, and it cannot see anything above that folder. Launch it in the wrong place and it will be confused about everything.
cd my-project claude
It opens a browser window the first time. Sign in with your Claude account, come back to the terminal, done. If sign-in ever gets strange, the /login command starts it over.
This reads your entire project and writes a file called CLAUDE.md: a briefing it reads automatically at the start of every future session, forever. Twenty seconds now, better answers for the life of the project. Open what it wrote and correct anything wrong.
/init
Not "hello". Ask about your own code so you can judge the answer. This is also the fastest way to learn what your own project actually does.
Read this project and explain in plain English what it does, what the main files are, and the one thing most likely to break.
The Esc key stops it mid-sentence, mid-edit, mid-anything, and keeps everything it did up to that point. You are never trapped watching it do the wrong thing. Hit Esc the second it heads somewhere you did not intend, and say what you actually wanted.
Almost every bad result comes from jumping straight to step three. This sequence is the difference between a tool that ships features and a tool that generates confident wreckage.
Ask it to read the relevant code and explain it back, and end the request with "do not write any code yet". Those six words are load-bearing. You are buying a Claude that understands your codebase instead of one that invents a second one alongside it.
Press Shift+Tab twice for plan mode: it can read and think, and it cannot change a single file. Ask for the approach and the exact files it will touch. Most bad code is an approved bad plan. Thirty seconds of reading here is the highest-return time in the whole process.
One outcome per request. "Add the API route" and then "wire the form to it" beats "build the whole feature", because when something breaks you can still tell which step broke it.
Never accept "done" as evidence. Ask for the proof: the test output, the page loaded in a browser, the response from the endpoint. When it can run the check itself, it finds and fixes its own mistakes before you ever see them. This one habit is worth more than every other tip here.
Say "commit this with a clear message". A save point at every working state turns every future disaster into a one-command undo. It is the cheapest insurance in software and beginners skip it every time.
This is the actual skill, and it is learnable in an afternoon. Vague requests get vague answers with confident formatting. Every prompt below names the outcome, the constraint, and the proof. Tap Copy, paste it in, replace the brackets.
Run these first, on any project, including one you inherited or one Claude built for you last week.
Your very first real prompt in any codebase.
Read this project and explain it to me like I have never seen it. Cover: what it does, who uses it, the five files that matter most and why, how data moves through it, and the one thing you think is most likely to break. Plain English, no jargon. Do not write any code.
You need to change something and do not know where it lives.
Trace exactly what happens when a user [DOES THE THING], from the first click to the last thing saved. List every file involved in order, and say what each one is responsible for. Do not write any code yet.
Before a launch, or any time you inherit something.
Find the five things most likely to break this in real use, worst first. For each one give me the file, what goes wrong, who notices, and the smallest fix. Do not tell me what is good about the code.
Anything in [BRACKETS] is yours to replace. That is the only editing these need.
Six keys cover ninety percent of your day. The four characters underneath are the ones nobody tells beginners about, and they change how the whole tool feels.
| Esc | Stop it immediately and keep everything so far |
| Esc Esc | Go back and edit an earlier message, then take a different path from there |
| Shift + Tab | Cycle the permission modes: ask every time, auto-accept edits, plan mode |
| Up arrow | Scroll back through prompts you already sent |
| Ctrl + C | Cancel what is running. Twice in a row quits |
| Ctrl + L | Clear the screen clutter without losing the conversation |
| / | Opens the command list for your exact version. The real menu, always current |
| @ | Point at a file or folder as you type, so it reads the right one instead of hunting |
| # | Start a line with this to save a rule into memory permanently |
| ! | Run a terminal command yourself without leaving the session. The output stays in context |
Shortcuts and commands shift between versions. Whatever /help prints in your install beats whatever any guide says, including this one.
Slash commands run inside a session. Terminal commands start one. You do not need to memorize these. You need to know they exist.
| /clear | You are starting a different task. Use this far more than feels necessary |
| /compact | A long session is filling up but you need to keep the same thread |
| /context | You want to see what is eating the working memory |
| /init | First time in a project. Writes the CLAUDE.md briefing |
| /memory | You want to read or edit the rules it remembers |
| /rewind | It broke something and you want the code and the conversation back |
| /model | Switching between the deep thinker and the fast worker |
| /permissions | You are tired of approving the same safe command forty times |
| /agents | You want a specialist with its own instructions and its own fresh memory |
| /mcp | Connecting outside tools, databases, and services |
| /resume | Reopening a conversation from yesterday |
| /cost | Checking what this session has used |
| /doctor | Something is wrong with the install itself |
| /help | Always. It is the true, current list for your version |
| claude | Start a session in this folder |
| claude "fix the login bug" | Start with the job already stated |
| claude -c | Continue the last conversation exactly where you left it |
| claude -r | Pick an older conversation from a list |
| claude -p "list every TODO" | One answer, printed, then it exits. Good inside scripts |
| claude update | Get the newest version |
| claude doctor | Diagnose a broken install |
A file called CLAUDE.md in your project folder gets read automatically at the start of every session, forever. Every correction you find yourself repeating belongs in it. This single file is why one person gets great output and another gets noise from the same tool.
# Project: [YOUR PROJECT NAME] ## What this is One paragraph. What it does and who uses it. ## Stack The tools this is built with. Name the package manager, because guessing wrong here breaks things. ## Commands npm run dev start it locally npm run build must pass before anything ships npm test run the tests ## Rules - Never edit anything inside /generated - Prices come from lib/pricing.ts only, never hardcoded - Do not add a new dependency without asking me first - Ask before deleting any file ## Watch out for - The build fails silently if .env.local is missing DATABASE_URL - Everything under app/(public) has no login, assume strangers see it ## How I like to work - Plan first, show me the plan, then build - Small commits, one thing at a time - Prove it works before you tell me it works
CLAUDE.md in your project folder is the project briefing, and it belongs in your repo so anyone else who works on it gets the same rules. A second one at ~/.claude/CLAUDE.md is personal and applies to every project you ever open. Put your standing preferences there once and stop retyping them.
The second time you correct the same thing, do not correct it. Type # and the rule, and it is saved permanently. A CLAUDE.md grown that way beats one written in a planning session, because every line in it came from a real mistake.
No passwords, no API keys, no database addresses, no tokens. Ever. Secrets live in .env.local, and that file goes in .gitignore. If you are unsure whether something counts as a secret, it does.
Claude has a working memory for each session, and it fills up. A session running two hours across four unrelated tasks has already pushed out what you said in hour one. When it suddenly seems to have gotten worse, this is almost always why.
Finish the thing, save it, then clear. Starting fresh costs ten seconds of restating the goal and buys back full attention. Beginners hoard one long session as if it were progress. It is the opposite.
Every file it opens looking for the right one is memory spent on nothing. Use @ and the path. If you do not know the path, ask it to find the file, then clear and start the real task with the answer.
/compact squeezes the history down so you can keep going. It is a compression, so details do get lost. Restating the goal in five lines right after is not optional.
The fear that stops beginners is that they will break something they cannot get back. Two habits make that fear obsolete, and they take four minutes total.
Git is the undo button for your whole project. You do not need to learn it, you need to have it. Say this once at the start of any project and Claude sets the whole thing up for you.
Set this project up with git, add a sensible .gitignore, and make the first commit. Explain what you did in three lines.
Shift+Tab cycles three permission modes. Know which one you are in before you walk away from the keyboard, because one of them applies changes without asking.
There is a flag that turns off every permission check. It exists for throwaway containers and automated pipelines. Do not use it on a machine that holds anything you would miss, and never in a folder that is not in git.
Skip this on day one. Come back on day ten, when you notice yourself typing the same paragraph for the third time. Every one of these turns a repeated instruction into infrastructure.
Drop a markdown file in .claude/commands/ and it becomes a slash command. A file named ship.md becomes /ship and can hold your entire deploy checklist. Anyone who pulls the project gets it too.
/agents creates a specialist with its own instructions and its own fresh memory: a reviewer that only hunts bugs, a researcher that only reads. They work in parallel and never clutter your main thread.
Your own scripts, run automatically on events. Format after every edit. Block edits to a protected folder. Play a sound when a long job finishes. This is how a preference becomes something that cannot be forgotten.
Connect outside systems so Claude can read your database, your issue tracker, your designs, your logs. Fewer copy-pastes from a browser, and far better answers, because it is looking at real data.
A folder of instructions and reference files that loads itself only when the work calls for it. Where a CLAUDE.md rule is always on, a skill is deep knowledge waiting in the wings. This is how a studio bottles its standards.
Claude runs happily in several windows at once, and that is a real speed multiplier. One rule keeps it from becoming a disaster: give each session its own branch or its own copy of the project. Two sessions editing the same files will quietly overwrite each other, and you will find out later.
Every one of these is here because ignoring it cost us a day, a deploy, or a client's afternoon. They are ordered by how much the lesson stung.
Done is not evidence. Shipped means you loaded the real address and saw the thing with your own eyes. A green terminal is a claim, not a fact. Ask for the proof before you believe the summary.
Never let it guess at a command. If it is not certain an option exists, make it run the tool with --help and read the real output. Invented options look exactly like real ones and fail at the worst possible moment.
Two failed attempts means the plan is wrong. Not the code, the plan. Stop patching, go back to plan mode, and ask for a different approach. The third try on a bad plan is how a morning disappears.
Save at every working state. Small commits turn every catastrophe into a five second rollback. It costs one sentence and it is the difference between a bad hour and a bad week.
Give it the error, all of it. Your paraphrase deletes the line number that solves it. Paste every line, including the parts that look like noise. It reads all of it in under a second.
One session, one job. Two sessions working on the same files at the same time overwrite each other quietly, and you find out later, from a user. If you run more than one, give each its own copy of the project.
Secrets never enter the chat. No passwords, no keys, no database addresses in a prompt or in CLAUDE.md, not even to test something. They live in an environment file that never leaves your machine.
Read the plan like it costs money. Because it does. Thirty seconds of reading a plan is the highest-return time you will spend all day, and skipping it is the single most common beginner mistake.
It agrees with you by default. So never ask "is this right?". Ask "what breaks first, and why". Frame every review as a hunt and you get a real one.
Fresh memory beats clever wording. When it starts making dumb mistakes, do not argue with it. Clear the session, restate the goal in five lines, and watch it get sharp again.
You own the output. It is the fastest set of hands you have ever worked with, and everything that ships is still yours. Read what changed before you accept it.
Build small, ship it, then grow it. Every real system we run started as one page or one function that worked. This tool makes the first version cheap, so the only genuinely wrong move is spending three weeks planning something you could have had running on Tuesday.
Find your symptom. The cause is almost never the one you assume.
| The symptom | What is actually happening | Do this |
|---|---|---|
| It changed files I never mentioned | Your request was a wish, so it filled in the scope for you | Rewind, then name the file and the single outcome you want |
| It got slow and started making dumb mistakes | The working memory is full of three tasks ago | Clear the session and restate the goal in five lines |
| It is confidently wrong about a tool or library | Its training has a cutoff date. Your installed version does not | Make it read the actual installed source, or run the tool with --help |
| It says it fixed it and it is not fixed | It never ran the thing. It reasoned that it should work | Ask for the real output, every time, before you believe anything |
| It broke something that used to work | There was no save point between working and broken | Rewind, or restore from git, then commit far more often |
| It cannot find a file I keep talking about | The file is outside the folder you launched it from | Point at the exact path with @, or add the other folder to the session |
| It asks permission for the same safe command forever | Nothing has been allowed yet | Open /permissions, allow that one command, never see it again |
| It went in a circle three times | Wrong approach, applied harder | Press Esc, switch to plan mode, ask for a genuinely different approach |
Pick the one that describes a real annoyance in your actual week. Copy the prompt, paste it in, and answer the questions it asks you. That is the whole start.
You have a business and no website, or a website you are embarrassed by.
Build me a fast one page website for [BUSINESS], which does [WHAT] for [WHO] in [CITY]. It needs a headline, three reasons to call us, a photo section, real contact details, and a form that emails me. Use boring, reliable tools. Run it locally and show me. Then walk me through putting it on the internet, one step at a time.
You do the same twenty minutes of copying and pasting every week.
Every week I [DESCRIBE THE REPETITIVE THING] and it takes about [HOW LONG]. Ask me whatever you need to understand it properly, then plan the smallest tool that does it for me. Plan first, no code, and tell me honestly if this is not worth automating.
You have a spreadsheet, a folder of receipts, or an inbox you cannot see through.
I have [THE FILES] and I want to answer questions like [EXAMPLE QUESTION]. Look at the actual data first and tell me what is in there and what is inconsistent, then plan the simplest thing that gets me answers. Do not build anything yet.
Every word in this guide that might have stopped you, defined once.
Claude Code is Anthropic’s AI coding tool that runs in your terminal instead of a browser tab. The difference matters: it can read your actual files, run your actual commands, install things, run tests, and fix what it finds. A chat window can only give you text to copy. Claude Code does the work in the real project.
No, and that is who this guide is written for. What you do need is the ability to describe what you want precisely and to check whether you got it. Ask for plans before code, ask for proof before you believe it, and make it explain each change in plain English so you learn the project as it gets built.
Install Node 18 or newer from nodejs.org, then run "npm install -g @anthropic-ai/claude-code" in your terminal. Move into your project folder with "cd", type "claude", and sign in when the browser opens. Then run /init so it writes itself a briefing about your project.
It is a plain text file in your project that Claude reads automatically at the start of every session. It holds your stack, your commands, your rules, and your traps. Every correction you find yourself repeating belongs in it. It is the single highest-leverage file in a project, and it is why one person gets great output while another gets noise from the same tool.
Its working memory fills up. A session that has run for two hours across four unrelated tasks has pushed out what you said in hour one. Finish a task, save your work, clear the session, and start the next one fresh. Beginners hoard one long session as if it were progress. It is the opposite.
Yes, with two habits. Keep your project in git so every change is reversible, and start real tasks in plan mode, where it can read and think but cannot touch anything until you approve the approach. There is a flag that turns off every permission check. It exists for disposable containers, not for a machine holding work you would miss.
Yes. Plenty of people read a guide like this, get a taste of what is possible, and decide they would rather have the thing than the education. We are a product studio in Kalispell, Montana that builds custom apps, websites, and AI voice agents at set package prices, usually shipped in weeks. Call the ranch line and Mr. Mustard, our own AI agent, will take it from there, or book a call with Sarah directly.
Call the ranch line and Mr. Mustard picks up. He is our own AI voice agent, he is awake at 2am, and he will talk you through what you are stuck on or take down what you are trying to build. If you want a person, book thirty minutes with Sarah and bring whatever you have, including nothing but an idea.
And if you read all of this and thought I would rather someone just built it, that is what we do. Modern Mustard Seed is a product studio in Kalispell, Montana. Custom apps, websites, and AI voice agents, at set package prices, shipped in weeks. You own the code, the repo, and the deploys when we are done.
Free to share, print, and pass along. Send it to the friend who keeps saying they would build it if they knew how.
Same voice as this guide. Short, specific, and nothing you cannot run yourself.