Tips & Setup

How to set it up when you're starting out

This is the practical page. What vibe coding means to me and why this particular set of tools is over on Vibe Coding — it doesn't belong here and I won't repeat it. This is the plain how: what to turn on, how to have it configured, and in what order, so that someone starting out doesn't step on the same mines I did. It's not a full manual. It's the selection of what held up across dozens of sessions.

Start with the CLAUDE.md file

First thing in every project, before you write a single instruction. Put a CLAUDE.md file in the project root. It's the project's memory — the model loads it at the start of every conversation. Without it you start from zero every time and the model guesses: it doesn't know what you're building, what it must not touch, or where to put notes. With it, context holds across sessions and the model behaves consistently.

What goes in there, concretely:

What the project does — two or three sentences, what it's for and who for. Not history, not marketing. Just enough for the model to know what it's reaching into.
Rules — output language, style, format, what to avoid. What you write here you don't have to repeat in every message.
What not to touch — specific files, folders, or procedures that are sensitive. This one prevents the most damage.
Where to save notes — the path to the memory files, so notes don't scatter randomly across the project.

Keep the headings short and plain. Literally fine as:

# What the project does
# Rules
# What not to touch
# Where to save notes

Skills, hooks, agents

Three different things people mix up. Worth knowing when to reach for which.

A skill is a knowledge file that activates itself based on context. The rule for spotting that something belongs in a skill: you're explaining it for the third time. When you repeat the same thing — a procedure, a convention, how something is done in this project — for the third time, it's time to write it down once and let it offer itself when it's relevant. You stop repeating yourself and the model stops improvising.

A hook is what's supposed to happen automatically — a check before a commit, formatting after an edit, blocking some operation. The key difference: a hook is fired by the system, not the model. So it happens every time, not just when the model remembers. Anything that genuinely must not be skipped (a security check, a build verification) belongs in a hook, not in a plea inside the prompt.

Agents are parallel, independent contexts for independent tasks. Each agent is its own working thread with its own memory. Useful when you have several things that are unrelated and don't have to run one after another.

Run agents in parallel

This is the biggest speed lever and it's easy to miss. When you have several independent tasks — say a security check, a performance review, and type checking — don't run them one after another. Send them as several agents in a single message. Each gets its own context, runs concurrently, and returns a result. Three tasks in sequence is three waits; three agents at once is one.

The hard condition this otherwise breaks on: agents must not touch the same files. One writer per file at a time. When two agents write to the same file, they overwrite each other's work and the result is unusable. Split the work so each one owns its own files. If it can't be split cleanly, it's not a job for parallel runs.

MCP servers — how to add them

An MCP server is the bridge between the model and a service. Without one the model only talks; with one it actually reads the database, deploys the site, creates the page. Adding one is three steps, not a long ritual:

Register the server in the Claude Code config. That's a one-time entry where you say how the server starts.
Key via an environment variable, never hardcoded in the code. A token, a password, an API key — always through a variable, not written into the file.
Restart the session and verify the tools loaded. Until you verify it concretely, you don't know it works — don't infer it from the command running.

Keys belong in .env or in a secrets manager that lives outside the repository. Never in a file that goes to Git. This isn't optional and it comes back below.

Git and commits

Git for everything. Every project gets its own repository now, not "once it's done". A lost session survives; lost code with no history doesn't. Create the repository at the first meaningful commit, not at the end.
Small commits. One change, verify, next. When you mix a refactor, a new feature, and a fix into one commit and it breaks, you can't tell which one did it. Separate commits mean you isolate the fault in a minute, not a day.
Build verify before push. Before you send anything, let the build pass cleanly locally. A broken build on a remote server is far harder to chase than the same problem on your own machine, where you can see everything.

Security and secrets

The cheapest rule with the highest price for breaking it. Hold it from minute one, not after the first blow-up.

No keys in code or in Git. API keys, passwords, tokens — never directly in a file that gets versioned. A secret pushed once is in the history forever, even if you delete it afterwards.
.env or a vault outside the repository. Secrets live in .env or in a secrets manager that isn't part of the repository.
Verify the sensitive files are in .gitignore. It's not enough to assume they are. Look in .gitignore and confirm .env and similar files are actually there, before you commit.
Back up before editing important config. Before touching settings.json, CLAUDE.md, or .env, make a .bak copy. It costs a second and gives the data back when something breaks.

Cross-review with a second model

Whatever goes out or matters, have a different model read it before it's approved. Here Gemini does that job. The reason is simple: one model won't critique itself — a second model has no reason to praise the first and actively looks for holes in it. It's not ground truth, it's a second pair of eyes; verify each objection, not every one lands. Why this way and why specifically a second model is laid out over on Vibe Coding — here it's just that it's done and when.

Memory and notes as you go

A session can be lost. The memory file stays. The whole procedure follows from that:

Project memory. CLAUDE.md plus note files you point to from it. One place where what happened, when, and why gets saved.
Write as you go, not at the end. After every change — a deploy, a fix, a config edit — write it down right away, not in a batch "later". That "later" doesn't come, the session ends first.
Save state before clearing context. Before context gets shortened or cleared, save the current state to memory. Otherwise the model doesn't know where you left off after the clear and starts redoing things.

The point of this whole block is one thing: the same mistake should not happen a second time. When it's written down, it doesn't repeat. When it isn't, it repeats reliably.

Verify with a concrete test, not an impression

Never claim "loaded", "ready", or "works" off the back of a command running without an error. A command that ran is not the same as a working result. Verify it with a concrete test — open the page in the browser, call the endpoint, check the tool actually loaded. When you don't have a test, say so plainly ("ran, but not verified") instead of claiming done. Half-verified work you know is half is better than whole work you only think is whole.

When you get stuck, fix it directly

When something won't work or breaks, fix it directly — not five agents endlessly watching something and reporting still nothing. Decisive action beats a monitoring loop. When something needs checking, check it once and act on the result. If you do send an agent at something in the background, have it return a concrete usable result, not an endless "waiting". Watching isn't work; fixing is work.

This is the selection of what held up, not a full manual. What specifically runs here, what works, and what broke is described honestly on Vibe Coding.