CLAUDE.md Initialization and Best Practices in Claude Code

John Lindquist
InstructorJohn Lindquist

Social Share Links

Tweet

CLAUDE.md initialization primes Claude Code with a single, evolving source of truth. Use it to record team guidance, keep updates flowing, and separate shared memory from personal notes.

Generate CLAUDE.md

Initialize from the codebase:

/init

Keep it fresh

  • Temporarily allow edits:

    claude --permission-mode acceptEdits
    
  • Update conversationally:

    Update the build section to use pnpm instead of npm.
    

Layer private context with file references

Add references in CLAUDE.md:

@~/.claude/info.md
@./.claude/common-commands.md

Example personal file:

# ~/.claude/info.md
Favorite Pizza: Turkey

To permit reading your user file, grant access in your user settings:

{
  "permissions": {
    "allow": ["Read((/Users/you/.claude/**))"]
  }
}

Patterns that scale

  • Keep team-wide instructions in CLAUDE.md.
  • Keep individual notes out of the repo via @~/.claude/....
  • Break large docs into referenced modules for faster updates.

You’ve finished the series. You can now set up Claude Code, work fast, scale context, manage costs, secure secrets, collaborate via settings, and maintain living project memory.

[00:00] When you run slash init on your project, it will read through your project and create a clod.md file. Now this has a custom prompt from Anthropic which explores the repo and gathers a bunch of information. As this is going through, I'm going to press 2 to allow all grep commands. You'll see that will update my settings local to allow Grip, and it will start reading files like package.jsons and readmes trying to figure out what's important and what's not. This can take a couple minutes, might as well go grab a sandwich.

[00:30] Then finally when it's ready to write a file it will ask us to set the permission mode. And permission mode, when I accept this with 2 or shift-tab, I prefer pressing 1, 2, or 3 as the shortcuts. So I'll just press 2 here. You'll see that's not persisted in my settings.json, it's only persisted for the session itself. And I've essentially given it permission to write and update any file in my project.

[00:53] As always please make sure you're using Git to be able to undo any of those changes. You can also see in your status line that accept edits is now enabled. Now as a quick tip you can just start Clawed, immediately hit shift tab to turn on accept edits, or you can even start Clawed with permission mode accept edits, and you'll see it's enabled by default here. Or you can go into your settings and under permissions hardcode default mode to accept edits. And that way once you launch Cloud, accept edits will always be on by default, which is fairly safe provided you're using git, since you're only telling it it can write files.

[01:34] So now that we have a clod.md file created, we'll look at it here. You'll see that this is isolated to our project, and it gathered the custom commands and architecture, and essentially read through here and verify that everything follows the guidelines that you would expect. Now I'd recommend if you see anything out of place just open up an instance of Clod, fire up Clod again. You'll see thanks to the extension we're already referencing Clod MD. Otherwise you can inline the file and then just dictate the things you'd like changed.

[02:04] Please update all of the npm commands to use pnpm because we always want to use pnpm, and other stuff like that based on version numbers or commands or anything you see on here. Just read through and dictate while you're reading and capture all that information, and it will go ahead and update this for you, rather than trying to tweak everything by hand. Now what gets really interesting here is that if you want custom behaviors inside of your ClawedMD file, which is checked in, you can use what are called file references. I can reference a file on my system called info.md in this directory, and if we open this file up, so clod info.md, you'll see that my favorite pizza is turkey. I'm just using that because even if it hallucinates it's never gonna guess turkey.

[02:49] So if you try and run this, I cleared out everything so it's not influenced by any context. We'll open up Claude. Let's make sure that Claude isn't selected. And I'll even go so far as to disconnect from the IDE so we don't accidentally automatically include some file or context over here. And I'll ask it what is my favorite pizza?

[03:12] And you'll see we get turkey back as the answer because our Claw.md file is essentially inlining this information into this Claw.md memory file. Now if it failed to read this file for you for any reason in your Claw.settings.json file, go ahead and add a permissions allow read. So I'll paste this in here, remove all of these, and add a read to wherever that file would be, such as users, John Lindquist, Cloud, and any file in the cloud directory, or anywhere on your system where you want to store those types of files that will be inlined into your Claw.md. This way you can check in your Claw.md file and have various information about your own individual role on the project, maybe some common resources, your documentation, things you always want in context based on your personal workflows on the project. And you can include pretty much as many of these file references as you want, and even nest file references in there.

[04:13] And it becomes up to you on how large your claud.md file gets. If you want to break out some of these sections, let's say common commands, we'll cut that and we'll at and drop this in our current clod directory. Common commands.md and create a file called clod common commands.md Drop this in here. So now this will be inlined here, and if we start another session we'll say clod what are some of our common commands. And again make sure that files are closed so we're not accidentally bringing in context through the extension.

[04:48] So if I say what are some common commands, and it looks like I misspelled the path in my Claw.md. Common commands. So we'll try this again. And one tip here if you're trying something out and you want to run it over and over, is you can provide an initial prompt with what are the common commands. Rather than waiting for the session to start and then typing in the initial prompt, you can actually just provide the initial prompt right away.

[05:13] So you can see that we got the common commands out of CloudMD without ever invoking a read tool. It's just automatically provided. So now we have that. We have what's my favorite pizza, and all of this is provided without ever invoking read tools, with a caveat being this all comes at the cost of context. So the best practices here essentially are anything in your main memory file should be things that apply to the entire team and the entire project.

[05:39] For example, if you expect everyone to read from GitHub issues then put information on how to access and update GitHub issues. But anything else that's not project critical you can export that into file references where individual users on the team can customize how they want their version of Cloud to behave. Then you could check in all of these files into various repos for various team members, for various squads on your team, or however you want to set that up to create that clean separation between project memories and user memories.