resources /

How to set up Claude Code properly: the setup we use every day

Published

Installing Claude Code takes five minutes. Making it useful takes an afternoon, and it comes down to five things: a project instructions file, a memory habit, a short list of skills, permission rules, and a way to check the work. This is the setup we run every day, across more than a dozen projects.

1. Install it (five minutes)

Anthropic’s recommended route is the native installer. On macOS, Linux or WSL:

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

Homebrew, WinGet (winget install Anthropic.ClaudeCode) and npm installs also exist; the native and Homebrew routes are the ones that keep themselves updated. You need macOS 13+, Windows 10 (1809+) or a recent Linux, 4 GB of RAM, and a paid Claude plan or an API account to sign in. Then, in any project folder, type claude. Anthropic’s setup guide covers the edge cases.

2. Give it a project instructions file

Claude Code reads a file called CLAUDE.md at the start of every session. This is the single highest-leverage thing you will write. Run /init to get a draft, then cut it down to what a new colleague would need on day one:

  • what the project is and who it’s for, in two sentences;
  • how to run, test and ship it — the exact commands;
  • the rules that aren’t obvious from the code (“never edit generated files”, “prices are in CAD”);
  • where the important things live.

Keep it short. A CLAUDE.md that tries to hold everything gets skimmed — by the model as much as by people. Larger reference material can live in separate files that CLAUDE.md imports with an @path/to/file line, which loads them reliably at startup.

A lesson we paid for: we once loaded our core context through a startup hook’s output instead of imports. Hook output is capped, so most of it was silently cut off — for weeks, sessions started without half their context and nothing complained. Imports don’t have that ceiling.

3. Make memory a habit, in files

A session’s conversation does not survive the session. Anything worth keeping has to be written to a file the next session will read. We keep three kinds:

  • a daily log — what was done, decided and left open, appended as work happens rather than at the end;
  • a small core memory — the few facts every session needs, imported from CLAUDE.md;
  • decision records — one file per significant choice, with the reasoning, so it can be challenged later instead of re-argued.

Tell Claude Code to write early and often. The common failure is a long, productive session that fills up and ends with nothing written down.

4. Add a few skills — not fifty

Skills are packaged instructions Claude loads when a task matches: a review checklist, a deploy routine, a research method. They are the right home for anything you explain more than twice. The trap is collecting them: every installed skill competes for attention, and a big pile makes the right one less likely to fire. We cap ours at about thirty and prune regularly. The ones that earn their place are about discipline — write the test first, verify before claiming done, debug systematically — more than about features.

5. Set permissions you can live with

Claude Code asks before running commands or editing files. Rather than approving the same safe commands forever, allow them once in settings (read-only commands, your test runner) and keep the prompt for anything that deletes, deploys, spends money or sends a message. Use plan mode (Shift+Tab) for anything large: Claude proposes, you approve the plan, then it builds.

Two rules we hold everywhere: secrets live in the system keychain and are never pasted into a conversation, and deletions go to the trash rather than straight to oblivion. Hooks can enforce rules like these automatically, so they don’t depend on anyone remembering.

6. Decide how you’ll check the work

The model is fluent, and fluent-and-wrong is more dangerous than obviously uncertain. Every project should have one command that proves it still works — tests, a build, a data check — and Claude should run it before saying a task is done. Ask for evidence, not reassurance: “show me the test output” beats “is it working?”

The afternoon, as a checklist

  1. Install, sign in, run claude in one real project.
  2. /init, then cut CLAUDE.md to a page.
  3. Create a daily log and tell Claude to append to it.
  4. Add two or three skills for things you repeat.
  5. Allow your safe commands; keep prompts for the risky ones.
  6. Name the one command that proves the project works.
  7. Do one real task end to end, in plan mode.

If you’d rather do this once, properly, with someone who runs it daily, that is exactly what AI Setup is.