How to Use CLAUDE.md in Claude Code in 5 Minutes

0:00 The difference between Claude code being useful and Claude code being incredible. Honestly, a lot of it boils down to actively managing one file, Claude MD. It's how you teach Claude your project's architecture, coding standards, and the mistakes you've already made. Skip it and you're leaving power on the table. Welcome to another episode of our mastering claude code series.

0:35 Hey, Alex here from Grit AI Studio. Today we're mastering the Claude MD file, Claude codes memory system. By the end, you'll have Claude understanding your project like a senior teammate. We already did a video about managing rules across coding agents, but this one is all about Claude code. Let's set it up. Claude MD is project memory. Every time Claude starts, it reads this file. It's persistent context that survives across sessions. Think of it as an onboarding documentation for Claude. What's the text stack? Where's the important code?

1:14 What patterns do we follow? What mistakes have we learned from? With a proper Claude MD file, Claude knows your project instead of guessing or wasting tokens exploring every time. But first things first, don't write Claude MD from scratch. Let Claude do it for you. Just run slashinit. Watch what happens. Claude explores your entire repository. It reads package JSON. It scans the directory structure. It looks at key files, identifies patterns, and then it writes a summary.

1:50 This is a great starting point and then you will customize it and iterate over time. CL code has a memory hierarchy. Understanding it can be really useful. On top we have the enterprise policy. This has the highest priority. It's set by your organization and it cannot be overwritten. It's not that relevant if you're a solo developer or someone building your own projects. Importantly, claude MD which is your project memory.

2:22 It lives in the project root typically something you would share with your team with git. In addition to project memory, we also have project rules. They live in the clawed rules folder. Here we have markdown files as modular rule files and uh we can apply path specific patterns. Then we have our own personal global memory file. This claude MD file or the user memory lives in our home claude folder. Here we have our personal preferences and it follows you across projects. We can also define a project local claude.local.md file. This typically is then not committed to git and contains your personal project nodes or preferences.

3:11 When there are conflicts, the higher priority wins. Whenever we want to add a key learning or something to memory, we simply ask Claude to add it for us or remember it. Say you're debugging and you finally solve a tricky issue. That note is now in your project memory. And this is compounding engineering. Every solved problem teaches Claude something. You can always manage memory by typing /memory. Similar to something we had for a while in cursor, we can also specify modular rules for cloud code. Especially in big projects, we might need organized rules.

3:51 Use claude/ rules. You can then create focus files for testing, for security, and so on. These get loaded alongside your main claude MD file. Path specific rules are even more powerful. This rule only loads when working on files matching that globe pattern. Claude MD can also import other files. The at@ symbol imports content from these files. Keep your main Claude MD clean with detailed rules in separate files. You can also import external URLs or reference documentation that Claude should be aware of.

4:30 So here's my favorite workflow. After every painful debugging session, I say something like this. We finally fixed it. summarize all the rabbit holes we went through so we avoid these mistakes in the future. Add it to the project memory. As a bonus, you turn that into a slash command so you don't have to type it every time. By doing this, Claude documents what went wrong, why it happened, and how to prevent it in the future. Next time Claude encounters similar code, it remembers. Your team remembers. The same bug never happens twice. This is compounding engineering in action.

5:11 So, here are some pro tips for Claude MD. One, run/init first, then customize. Let Claude do the heavy lifting and then add your expertise. Two, keep it concise. Claude MD is loaded every conversation. Don't make it a novel. Three, date your learnings. When you add mistakes, note when you discover them. context helps and four subfolders can have their own claude MD front end folder gets front- end rules and so on.

5:43 Number five at referencing a file also loads claude MD from that directory rules flow with file references and number six review periodically. Remove outdated rules and keep your Claude MD file current. This last one is something a lot of people miss. Make sure you review or ask Claude to review for you. You can say something like this. Please review our Claude MD file and highlight any parts we should simplify or remove for duplication. Context is king and a bloated Claude MD can actually have negative effects on our results. Set up your Claude MD today. Your future self will thank you. I hope you found this video helpful. I would really appreciate if you like and subscribe to the channel if you want more mastering Claude code videos. Thanks a lot for watching and I'll see you in the next one.