All video notes
Video notes · Claude Code memory

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

Video by GritAI Studio on YouTube · 7 min · uploaded January 2026

Notes and analysis by BrainTube, written from the video. Not affiliated with GritAI Studio. Watch on YouTube

In short

Alex from GritAI Studio gives a compact, accurate tour of CLAUDE.md: generate it with /init, understand which memory files load and in what order, split rules into .claude/rules with path patterns, and save lessons after every hard debugging session. It is a solid starting checklist. Its favourite workflow, logging every rabbit hole into project memory, works against its own advice to keep the file short, and the video overstates how reliably a memory file prevents repeat bugs.

The argument

The video argues that the gap between Claude Code being merely useful and being very good comes down to actively managing one file. CLAUDE.md is read at the start of every session, so it should work like onboarding notes for a new teammate: the stack, where the important code lives, the patterns you follow and the mistakes you have already made. You start it with /init, extend it with modular and path-specific rule files and imports, and grow it by asking Claude to record what each solved problem taught you, which the presenter calls compounding engineering. Regular review keeps it lean.

Key ideas, with timestamps

  1. 0:58

    CLAUDE.md as onboarding notes

    Claude reads the file every time it starts, so its contents persist across sessions. The presenter lists what belongs there: the tech stack, where the important code is, the patterns you follow and lessons learned. Without it, Claude guesses or spends tokens re-exploring the repository each session.

  2. 1:29

    Start with /init

    Rather than writing the file from scratch, run /init. Claude explores the repository, reads package.json, scans the directory structure and key files, and writes a summary. He treats that as a first draft to customise, not a finished file.

  3. 1:58

    The memory hierarchy

    At the top is an enterprise policy set by an organisation, which cannot be overridden. Below it sit the project CLAUDE.md in the repo root (shared through Git), project rules in a .claude/rules folder, a personal CLAUDE.md in your home .claude folder that follows you across projects, and a CLAUDE.local.md for private project notes kept out of Git. When files conflict, the higher level wins.

  4. 3:16

    Ask Claude to remember

    To add a learning, you simply tell Claude to remember it, for example after finally solving a tricky bug. At 3:37 he points to the /memory command for viewing and editing the loaded memory files directly.

  5. 3:42

    Modular and path-specific rules

    Borrowing an idea Cursor had earlier, large projects can split rules into focused files under .claude/rules, such as testing or security, loaded alongside the main file. At 4:00 he shows path-specific rules that load only when Claude works on files matching a glob pattern. At 4:11 he adds @ imports so the main file can pull in other files and stay clean.

  6. 4:30

    The post-debugging habit

    His favourite workflow: after a painful debugging session, ask Claude to summarise the dead ends and add them to project memory, then turn that request into a slash command. Claude records what went wrong, why and how to prevent it. He calls this compounding engineering in action.

  7. 5:11

    Six pro tips

    Run /init first, keep the file concise because it loads every conversation, and date your learnings. Subfolders can have their own CLAUDE.md, and referencing a file with @ also loads the CLAUDE.md in its directory. Finally, review periodically; at 6:04 he suggests asking Claude to flag sections to simplify or remove as duplicates, since a bloated file can hurt results.

What it gets right

The hierarchy explanation is the most useful minute. Many people keep everything in one project CLAUDE.md, including personal preferences that do not belong in a shared repo. Knowing that a home-folder file carries your own habits across projects, and that CLAUDE.local.md holds private notes for one repo, fixes that quickly.

Path-specific rules are the right answer to bloat. Rules about database migrations do not need to load when Claude edits CSS. Scoping them by glob keeps the always-on context small, which matters because, as he says, the file is loaded every conversation.

Dated learnings are an underrated tip. A note saying a library version broke something is only useful if you know when, so you can tell whether it still applies after an upgrade.

The closing review prompt is practical. Asking Claude to find duplicates and stale rules is cheap, and it is the step most people skip.

What it leaves out or overstates

The favourite workflow fights tip two. Logging every debugging session's rabbit holes into project memory is a fast way to grow a long, narrow file. A better filter: only save a lesson if it is likely to recur and Claude could not work it out from the code. One-off war stories belong in a commit message or a separate notes file that CLAUDE.md can point to.

Memory is context, not enforcement. The claim that the same bug never happens twice is too strong. CLAUDE.md is guidance the model usually follows, not a rule it must obey. If a mistake would be costly, back the note with a test, a lint rule or a hook that blocks the action. Instructions guide; tests and hooks enforce.

External URL imports need checking. He says imports can reference external URLs. Claude Code's documentation describes @ imports in terms of file paths, so if you rely on a URL, confirm Claude actually reads it rather than just seeing the link text.

No sense of size. Keep it concise is the right instinct, but there is no example of a good file, no rough length, and no guidance on what /init tends to get wrong, such as listing every folder instead of the few that matter.

How this applies to memory across AI tools

Everything in this video is specific to Claude Code. The same project facts usually need to exist again in Cursor rules, in an AGENTS.md for other agents, and in whatever you paste into a chat app, and the copies drift. One fix is to keep durable knowledge, such as decisions, reference notes and research, in a single store that every tool can query, and keep each tool's instruction file short. See one memory across ChatGPT, Claude and Cursor.

For the research part of that store, BrainTube saves YouTube videos with their transcripts, articles, PDFs and podcasts into one compiled knowledge base and exposes it as an MCP server, so Claude, ChatGPT, Cursor and other MCP clients can search the same material. Other options are covered in Claude Code memory tools.

Who should watch it

Watch it if you are new to Claude Code or have a single, growing CLAUDE.md and have never used the other memory files; the hierarchy at 1:58 to 3:13 and the rules and imports section at 3:42 to 4:26 are the parts to take notes on. The pro tips at 5:11 make a good checklist. Skip it if you already use .claude/rules and path-scoped rules, since there is nothing deeper here, and do not treat the post-debugging habit at 4:30 as a rule without the filter described above.

Frequently asked

What should go in a CLAUDE.md file?
Put in what a new teammate would need and could not easily infer: the tech stack, build and test commands, where key code lives, conventions to follow and mistakes to avoid. Keep it short, because Claude Code loads it every session. Move narrow rules into path-specific rule files.
What is the difference between CLAUDE.md and CLAUDE.local.md?
CLAUDE.md in the project root is meant to be committed and shared with your team. CLAUDE.local.md holds your personal notes and preferences for that project and is usually kept out of Git. A separate CLAUDE.md in your home .claude folder applies to all your projects.
How do I make Claude Code remember something?
Ask Claude to remember it or add it to project memory, and it will write the note into the right memory file. You can view and edit loaded memory with the /memory command. For anything critical, also add a test or hook, because memory files guide behaviour rather than enforce it.

Keep videos like this one searchable

BrainTube saves YouTube videos with their transcripts into one compiled knowledge base that Claude, ChatGPT, Cursor and other MCP clients can search.

Start free

Go deeper

More video notes

Are you the creator and want this page changed or removed? Contact us and we will act within 48 hours.