Mental Models

cd first, then claude

Order matters when you start a Claude Code session. Navigate into your system folder first, then start Claude. Not the other way around.

The wrong order

# Open Terminal, immediately type:
claude

# Then try to talk about files Claude can't see.

If Claude is started from outside your system folder (your home folder, your Desktop, anywhere else), it cannot see your files. Asking it to read your CLAUDE.md or update a skill will not work, because those files are not in the directory Claude is looking at.

The right order

# Go into your folder first:
cd ~/Downloads/four-languages-part-1

# Then start Claude:
claude

Now Claude is "inside" your folder. It can see your files, your skills, and your memory system. Everything works.

What does cd mean?

cd stands for "change directory". A directory is just the technical word for a folder. So cd ~/Downloads/four-languages-part-1 means "go into your system folder, inside Downloads". That is all it does.

If you ever lose track of which folder you are currently in, type pwd (print working directory). It will tell you.

Don't tell Claude where, ask Claude where

You will hit small structural decisions all the time. Where should this folder go? What should this file be called? Is this the right place to save this? Is this format better than that one?

It is tempting to try to figure these out yourself. The faster move is to hand them to Claude.

The pattern

Instead of asking yourself: "Where should I move this folder?"

Type to Claude: "Can you move this to a location on my computer that makes it easiest for us to access and work with?"

Claude knows where its working directory should live. It knows which paths are short, which are stable, which are easiest to navigate to. It will move the folder, tell you where it went, and explain why.

Where this pattern shows up

• Folder structure: "Where do you think this client should live in my system?"
• File naming: "Suggest a name for this skill that fits how the others are named."
• Format choice: "Which format works best here, YAML or markdown? Pick one and tell me why."
• Architecture: "Look at what we have. Should this be split into two files? You decide."

Screenshot debugging

If you only take one trick from this whole page, take this one. It will save you more time than any other technique in the course.

The terminal is hard to copy text from. You cannot easily select multiple lines, errors wrap in confusing ways, and pasting them into Claude often loses the formatting that contained the actual error. Trying to manually copy a stack trace will frustrate anyone.

The move

1. Press Cmd + Shift + 4 (Windows: Win + Shift + S)
2. Drag a box around the part of the terminal you want to share
3. Drag the screenshot file straight into your Claude conversation
4. Type "what is happening?"
5. Press Enter

Claude reads the screenshot, identifies the error, and tells you the next step. It is faster, more accurate, and less frustrating than any other approach.

This works for almost anything visual

• Terminal errors that are hard to read
• Browser console errors
• Confusing app screens or settings pages
• Diagrams or charts you want explained
• Receipts or invoices you want logged
• Anything visual you do not want to retype

The rule is simple: if you cannot copy it, screenshot it and drag it. You never need to retype anything from a screen. You never need to "explain what you see" to Claude. Just show it.

"Press 2" and what permissions actually mean

The first time Claude asks for permission to do something (run a command, edit a file, push to git), the options will look something like this:

Do you want to allow this?
1. Yes
2. Yes, and don't ask again for this in this conversation
3. No

It is tempting to pick option 1 every time, because option 2 sounds like it might allow something dangerous. It does not.

What option 2 actually does

Option 2 means "yes, and stop asking me about this kind of action". How long that lasts depends on what Claude is doing.

For file edits (creating, editing, or deleting files), it lasts for this conversation only. Start a new session and Claude asks again, fresh.

For shell commands (things Claude runs in the terminal), it sticks. Claude writes the rule to a settings file in your project and stops asking for that command in future sessions too. Handy, but the rules build up, so it is worth reviewing now and then with /permissions.

When to press 2 (most of the time)

• Editing files inside your own system folder
• Reading files inside your own system folder
• Running standard git commands like git status or git add
• Running skills you have already used before

When to slow down and pick 1

• The first time you see a brand new kind of action you have never authorised before. Pick 1 the first time, watch what happens, then press 2 next time if it was fine.
• Anything that touches outside your system folder, like installing software at the OS level.
• Anything that posts to a public place: social posts, public repos, anything other people will see.

Where Claude's knowledge actually comes from

You might think Claude "just knows" things in a conversation. It does not. Everything Claude knows in any given session came from somewhere specific, and there are exactly four sources. Once you can see the four sources, the way your root system is organised stops feeling arbitrary and starts feeling obvious.

The four sources of context in any conversation

The map and the terrain

Here is the frame that makes all four sources click. The three auto-loaded files (CLAUDE.md, MEMORY.md, and your rules) together ARE the map. Everything else is the terrain: your fact files, your skills, your content folders, your history. The map points to where things live and when to load them. The terrain is where the actual detail lives.

The map needs to stay small because it loads in every single conversation. The terrain can be infinite because each piece only loads when you actually need it.

Why a bloated map causes more mistakes (not fewer)

It is tempting to put more and more into the map because "Claude will see it every session." That instinct is wrong, and it actively makes Claude worse. Here is why.

This is why discipline about what goes in the always-loaded layer is not pedantic. It is the single biggest lever you have over the quality of every future conversation.

A practical test

Next time you are about to add a line to CLAUDE.md, ask yourself: "Could a skill or task do its job without reading this line?" If yes, it belongs in the terrain (a skill, a fact file, a content folder), not the map.

Next time you tell Claude something in a conversation, ask: "If I close this terminal and open it tomorrow without resuming this exact session, will Claude still know this?" If no, and it matters, save it to the right layer based on how often it should load. Permanent truth about you = a fact file. A lesson learned today = learnings.md. An observation about how you work = patterns.md. A draft you want to come back to = a scratchpad in context/pad/.

The rest of the course is built on this. Once you can feel the difference between the map and the terrain, every other architectural decision in your root system becomes obvious.

Keep your keys and passwords safe

Sooner or later your system holds real secrets: an API key for Stripe, your database key, a password, an access token for your email service. They are the most dangerous thing your system holds. Anyone who has one can act as you, charge cards, read your data, send email from your name. So they get handled differently from everything else.

The one rule: every secret lives in one file

Every secret your system uses lives in a single file called .env, in your system folder. That is the only place a raw key is ever written down.

You do not set this up. Your system ships with the .env already there, alongside a .gitignore that keeps it out of your saved history and the deny rule further down that blocks Claude from reading it. The plumbing comes ready. You only add your keys.

.env starts with a dot, which makes it hidden by default. To see it in Finder, press Cmd + Shift + . (the full stop) to show hidden files. Or just ask Claude to open your .env.

Add your keys, and refer to them by name

When a service gives you a key, open your .env and add it with a name:

STRIPE_SECRET_KEY=sk_live_...
RESEND_API_KEY=re_...

Add it in the file yourself rather than pasting it into the chat. From then on you refer to a key by its name, never its value. To have Claude use it, you say "the Stripe key is in .env as STRIPE_SECRET_KEY". Claude or your code reads the value from the file at the moment a command needs it, so the raw key never lands in your conversation.

Why it matters: your conversation gets saved as a transcript file on your computer. A key you type into chat sits in that history for good. A key in .env, called by name, never lands there.

How your system keeps Claude out of it

There is one catch. .env is a normal file. Claude can open it like any other, unless something tells it not to. Your system already carries that instruction: one line in .claude/settings.json that denies Claude read access to .env.

{
  "permissions": {
    "deny": ["Read(./.env)"]
  }
}

So Claude Code refuses to pull .env into a conversation. Your commands can still use a key when they genuinely need one, Claude just never opens the raw file. This ships in place too. To check it is there, open .claude/settings.json and look for that deny line.

The three places a secret must never go

• Your saved history. Committed keys travel to anyone you ever share the system with. Keeping .env in .gitignore prevents it.
• Your website's code. Anything on a public page can be read by anyone who opens View Source. Secret keys stay out of the pages you publish.
• Anywhere other people can see. A screenshot, a shared doc, a group chat. Once a secret is public, treat it as burned.

Two kinds of keys

Some keys are meant to be public. A "publishable" or "anon" key allows only safe, limited actions and is fine in your website code. A "service" or "secret" key can do anything, so it lives in .env and never touches a public page. When a service hands you a key, check which it is. If you are unsure, ask Claude: "is this safe to use in the browser, or does it belong in .env only?"

If a key ever leaks, rotate it

If a secret ends up somewhere it should not, do not try to quietly hide it. Go to that service, delete the old key, generate a new one, and put the new one in .env. It takes two minutes and it is the only real fix. A leaked key you "meant to keep private" is still live in someone else's hands.