{"slug": "heres-how-i-get-the-most-out-of-my-claude-md", "title": "Here’s How I Get the Most Out of My CLAUDE.md", "summary": "A developer outlined a practical approach to configuring the CLAUDE.md file in Claude Code projects, placing recurring instructions at the repository root and in subdirectories so the agent retains context across sessions. The guide emphasizes concrete, project-specific commands and constraints over vague directives, and recommends keeping temporary, task-specific notes out of the persistent file. It also highlights path-scoped rules in .claude/rules/ for separating task-specific guidance.", "body_md": "Every time I started a new session with Claude, I found myself repeating the same instructions. Which commands to use, how I wanted the code written, what to test. I kept copy-pasting the same saved message from my notes whenever I started a new chat.\n\n**That’s when I found out about the CLAUDE.md file.**\n\nIt gives those recurring instructions a place in your project, so Claude can read them across sessions without you having to repeat yourself.\n\nThere are plenty of ways to write a CLAUDE.md file, but here’s how I like to approach it for maximum benefits. I’ll walk you through the structure I use, what I include, and what I leave out, with a few examples you can adapt to your own project.\n\nStart with your project’s root folder, the same place you’d usually find the README. Create a file named CLAUDE.md, like this:\n\n```\nmy-project/\n - CLAUDE.md\n - README.md\n - package.json\n - src/\n - tests/\n```\n\nCommit the file to Git so your teammates can use the same guidance.\n\n**You can also keep this file at .claude/CLAUDE.md**\n\nAs the project grows, you might need different instructions for particular areas. In such cases, you can create CLAUDE.md at sub-directory paths as well. For example:\n\n```\nmy-project/\n - CLAUDE.md\n - src/\n   - frontend/\n     - CLAUDE.md\n   - backend/\n     - CLAUDE.md\n```\n\nFor a start, one file at the root is enough. Add more when different parts of your project actually need different instructions.\n\n*An instruction that feels clear to you can still be vague to your agent.*\n\nFor example, if you keep giving prompts like these:\n\nThese sound like good instructions, but they leave a lot for your AI agent to guess. Think from its perspective: what does thorough testingmean in your project, and which best practices should it follow? You know what you mean, but your agent needs those details spelled out.\n\nHere’s a more useful version for an example TypeScript API:\n\n*Now these are concrete decisions to follow.*\n\nA project might have unit tests, integration tests, browser tests, and several ways to start the app. In such cases, writing “Run the tests after any edit” doesn’t give concrete steps to the agent.\n\nFor a hypothetical project using pnpm and Vitest, you could write:\n\n**Commands**\n\nRun these from the repository root.\n\nThe working directory and prerequisites matter as much as the command.\n\nBefore adding these, run them yourself. A copied command that starts watch mode or needs an undocumented service creates another problem to debug.\n\nAlso, avoid making every tiny change trigger every expensive check. Describe the checks that make sense for your project and let CI enforce the required gates.\n\nThis is where the file can earn its place.\n\nSuppose an API represents money in integer cents. A price of $19.99 travels through the system as 1999. Without that context, a perfectly reasonable looking change could introduce inconsistent values.\n\n**Better way:**\n\n**Money**\n\nOr suppose an older mobile client depends on an unusual response:\n\n**Compatibility**\n\nA short explanation of why something exists can prevent an unnecessary fix.\n\nImagine Claude adds a new date formatting library when the project already has a shared formatter.\n\nYou could respond with:\n\nDon’t add **unnecessary** dependencies.\n\nBut the next task might produce the same disagreement about what unnecessary means.\n\nA better instruction would be:\n\n**Dependencies**\n\nBe selective, though. One unusual task doesn’t always justify a permanent rule. Ask whether the correction will still matter next month.\n\nA note like this has an expiry date:\n\n*We are fixing the checkout bug today.*\n\n*The failing account is test-user-42.*\n\n*Try increasing the timeout first.*\n\nThese kinds of instructions don’t belong in CLAUDE.md because, if they’re left there after the work is done, they can cause confusion later.\n\nThat’s why I prefer keeping task-specific instructions in separate files.\n\nClaude Code supports path-scoped rules in .claude/rules/.\n\nStart with the information Claude needs to work on your project: what it does, how to run it, which conventions to follow, and how to check changes. You can use this structure and fill in the details.\n\n```\nProject overview\n - Briefly explain what this project does and its main technologies.\n\nUseful commands\n - Set up the project: [command]\n - Run locally: [command]\n - Run tests: [command]\n - Check formatting and linting: [command]\n\nMention where to run these commands and any required setup.\n\nWhere things live\n - Point to the main source code, tests, and important documentation.\n - Include locations that may be difficult to find or easy to confuse.\n\nProject conventions\n - Describe the patterns to follow and existing helpers to reuse.\n - Focus on decisions that aren't obvious from reading the code.\n\nThings to watch out for\n - Explain unusual behavior that must be preserved.\n - Identify generated files and how they should be updated.\n - Give a short reason for each restriction.\n\nChecking changes\n - Explain how to choose and run the relevant checks.\n - Ask Claude to report what it checked and anything it couldn't verify.\n```\n\nYou don’t have to fill every section. If there’s nothing useful to say under one, leave it out. Replace the placeholders with real commands and paths before using the file.\n\nThat brings us to the end of this blog! If there’s a practice you find helpful when writing your CLAUDE.md, share it in the comments. I’d love to give it a try.\n\n**Originally published on [Medium](https://medium.com/@the_infinity/heres-how-i-get-the-most-out-of-my-claude-md-843db3f321f9). Follow me there for more articles on AI tools and software development.**", "url": "https://wpnews.pro/news/heres-how-i-get-the-most-out-of-my-claude-md", "canonical_source": "https://dev.to/aditi2905/heres-how-i-get-the-most-out-of-my-claudemd-1682", "published_at": "2026-09-14 07:33:07+00:00", "updated_at": "2026-09-14 08:02:04.284480+00:00", "lang": "en", "topics": ["ai-tools", "ai-agents", "developer-tools", "ai-products"], "entities": ["Claude", "Claude Code", "Git", "pnpm", "Vitest", "TypeScript"], "alternates": {"html": "https://wpnews.pro/news/heres-how-i-get-the-most-out-of-my-claude-md", "markdown": "https://wpnews.pro/news/heres-how-i-get-the-most-out-of-my-claude-md.md", "text": "https://wpnews.pro/news/heres-how-i-get-the-most-out-of-my-claude-md.txt", "jsonld": "https://wpnews.pro/news/heres-how-i-get-the-most-out-of-my-claude-md.jsonld"}}