The Best CLAUDE.md File for Vibe Coding
Here's how to write a Claude.md file that Claude Code will actually follow.
- claude.md
- claude code
- vibe-coding
A CLAUDE.md file is a plain markdown file that Claude Code reads at the start of every session. To get the best out of it, you need to give Claude just enough information to work reliably, without overloading it. Let’s walk through how to do that.
CLAUDE.md Best Practices
Before adding anything else, start by downloading the CLAUDE.md from this Karpathy-Inspired Claude Code Guidelines repo. It’s a small, battle-tested base derived from Andrej Karpathy’s observations about the downsides of LLM-generated code, and it gives you a solid foundation to build the rest of your rules on top of.
The Karpathy Behavioral Guidelines
Andrej Karpathy is a founding member of OpenAI and the former Director of AI at Tesla. He is also one of the leading commentators on the capabilities and limitations of LLMs. In one of his famous posts, he laid out the recurring ways LLMs sabotage their own code:
The models make wrong assumptions on your behalf and just run along with them without checking. They don’t manage their confusion, don’t seek clarifications, don’t surface inconsistencies, don’t present tradeoffs, don’t push back when they should.
They really like to overcomplicate code and APIs, bloat abstractions, don’t clean up dead code… implement a bloated construction over 1000 lines when 100 would do.
They still sometimes change/remove comments and code they don’t sufficiently understand as side effects, even if orthogonal to the task.
The repo turns these complaints into four principles that map directly onto each failure mode:
| Principle | Addresses |
|---|---|
| Think Before Coding | Wrong assumptions, hidden confusion, missing tradeoffs |
| Simplicity First | Overcomplication, bloated abstractions |
| Surgical Changes | Orthogonal edits, touching code you shouldn't |
| Goal-Driven Execution | Leverage through tests-first, verifiable success criteria |
This is the core of a good CLAUDE.md, and it’s worth keeping even before you add a single project-specific rule. Most of the pain people feel with AI coding tools isn’t a knowledge gap, it’s behavior: the model charging ahead on a bad assumption, gold-plating a simple change, or quietly rewriting code it didn’t need to. These four principles are guardrails against exactly that, which is why they belong at the top of the file. You can read the full guidelines (and grab the raw file to drop straight into your repo) here.
Document Your Commands, Conventions, and Gotchas
List the things Claude cannot reliably infer from the codebase: exact build and test commands, required environment variables, project-specific conventions, branch and PR rules, integration constraints with external systems, and any other limitations that could lead to incorrect assumptions.
Emphasize the Rules That Actually Matter
If a rule keeps getting ignored, add weight to it. Marking critical instructions with IMPORTANT or YOU MUST measurably improves how reliably Claude follows them. Use this sparingly, though, because if everything is shouting, nothing is.
Keep It Short and Prune Ruthlessly
A bloated CLAUDE.md is worse than a short one. Important rules get lost, and Claude may start missing them. It also costs more because the file is read into context at the start of every session. Treat length as a budget: every extra line makes the useful ones easier to miss.
Push Sometimes-Relevant Knowledge Into Skills
CLAUDE.md loads on every session, so it should only hold things that apply broadly. For domain knowledge or workflows you need occasionally, like a specific migration process or a one-off deployment runbook, use a skill instead. Claude loads skills on demand, so you get the context when it’s relevant without paying for it on every unrelated task.
Don’t Settle for the /init Default
If you run the /init command, Claude Code will scan your project and generate a starter CLAUDE.md. Even if you go down this route, don’t treat the output as finished. Review it carefully, cut the obvious filler, add the project-specific details it missed, remove any inapplicable TODOs, and tighten the rules that actually matter.
Check It Into Git and Treat It Like Code
Commit CLAUDE.md so your whole team shares the same rules and can improve them over time. Treat it like code: review it periodically, test whether the instructions are actually working, remove what no longer helps, and update it as the project evolves.
Wrapping Up
A great CLAUDE.md doesn’t need to be long. In fact, it shouldn’t be. Keep it focused, keep it current, and make every line earn its place. Happy coding!
If your codebase has already drifted past the point where a CLAUDE.md alone can save it, that’s a different problem, and one we deal with all the time. Contact us for a free consultation today!