Your first week with Claude Code

This is the single most important habit. Git is your undo button, and without it you have none. Commit before every sizeable request, so "throw all that away" is one command instead of an afternoon.

$ git init
$ git add -A && git commit -m "empty project"

Once you're working, commit whenever a change is good. If a change is bad, git restore . and try the request again with better wording — that is usually faster than arguing it back to correctness.

Weak: "create a file called stock.ts and add an interface." You're doing the thinking and getting a typist.

Strong: "Add a stock list page. Each item has a code, a description, a quantity and a location. I should be able to add one, edit the quantity inline, and delete one. Keep it in local state for now — no backend yet."

Constraints are the useful part. "No backend yet", "don't add new dependencies", "match the style of the settings page" all steer it more than another paragraph of description would.

Press Shift+Tab to cycle modes until it says plan mode. In plan mode it reads and investigates but doesn't change files — it comes back with what it intends to do, and you approve or redirect before a single line is written.

Use it for anything you can't describe in one sentence. Reviewing a wrong plan takes thirty seconds; reviewing a wrong implementation takes an hour.

Finish a job, commit it, then type /clear to start the next one with a clean slate. A long session drags the whole history of what you've been doing into every new answer, and quality drifts.

Bundling helps nobody either. "Add the stock page, fix the login bug and change the colours" gets you three half-done things and a diff you can't review.

Run /init once at the start of a project. It reads your codebase and writes a CLAUDE.md file — notes that get loaded automatically every session.

Keep adding to it as you go: the command that runs your app, the command that runs your tests, the rules that aren't obvious from the code. Every time you find yourself explaining the same thing twice, that's a line for CLAUDE.md.

# CLAUDE.md

## Commands
npm run dev    # local server on :5173
npm run build  # production build
npx tsc -b     # typecheck (build does NOT check types)

## Rules
- Quantities are integers. Never round them for display.
- Every new page needs a route in src/routes.tsx.

That last line is a real example of the kind of thing worth recording: something true about the project that no amount of reading the code would tell you quickly.

"Done" from an agent means "I wrote what I believe is correct." It is not evidence. The fix is to make verification part of the request:

"…then run the build and the tests, and show me the output." Or: "start the dev server, open the stock page, and take a screenshot." It can do all of that, and it will find its own mistakes far more often than you'd expect.

It shows you every edit as it makes it. Read them. If you don't understand a change, ask: "explain what this function does and why you added it" — a genuinely good way to learn a language you don't know yet.

Things worth catching early: a new dependency you didn't ask for, a config file quietly rewritten, a "temporary" hardcoded value, a chunk of code that duplicates something you already have.

Press Esc at any point to stop it mid-flight and redirect. You don't have to let a wrong approach finish out of politeness.

Committing, branching, and opening pull requests are exactly the kind of fiddly, well-documented work to hand over. Install the GitHub CLI (gh), sign in once with gh auth login, and then plain English is enough:

> commit this with a sensible message
> push it to a new branch and open a PR describing what changed

It will not commit or push unless you ask — that's deliberate. Ask often; small commits are the thing that makes all of this recoverable.

Get something live while it's still trivial. A blank page on a real URL is worth more than a finished app on your laptop, because every deployment problem you'll ever have is easier to solve when the app is five files long.

For a frontend-only app, GitHub Pages is free and takes one workflow file. Ask for it directly:

> add a GitHub Actions workflow that builds this on every push
  to main and deploys it to GitHub Pages, then explain what I
  need to switch on in the repo settings

From then on, git push is your deploy. When you later add a database and a server, the same pattern holds — one workflow file, triggered by a push.