Put Your “House Rules” in CLAUDE.md So You Don't Have to Repeat Them

When relying on Claude Code for home automation tasks, you often find yourself repeating the same instructions over and over: "Don't activate the virtual environment," or "Save files containing non-ASCII characters (like Japanese) in this format." Having to repeat yourself every time you start a new conversation is frustrating, and the exact same mistake inevitably happens on days you forget to mention it.

The place to document these "things you repeat every time" is CLAUDE.md. Here is how I write mine, along with specifications verified in the official documentation.

What Is CLAUDE.md?

According to the official documentation, Claude Code starts with a clean slate for each conversation (session). One mechanism that bridges the gap between sessions is CLAUDE.md, an instruction file written in standard Markdown that you create yourself and that Claude reads at the start of a session. The official docs describe it as a place to jot down things you would otherwise have to explain repeatedly.

There is one important caveat: the official docs explain that Claude treats CLAUDE.md as "context," not as "enforced settings." Behaviors that must strictly be enforced (such as prohibiting specific operations) should be blocked through hooks or permission settings rather than CLAUDE.md. CLAUDE.md is ultimately just a request for how you want things done.

Scope Changes Based on Location

The scope of CLAUDE.md changes depending on where you place it. Summarized from the official documentation, the breakdown is as follows:

Any CLAUDE.md files in the launch directory and its parent directories are loaded together at startup. Rather than overwriting each other, they are all concatenated. Subfolder files are not read at startup; they are loaded when Claude reads or edits files in that folder. In addition, personal notes you do not want committed to Git belong in CLAUDE.local.md by convention.

I separate my rules by putting folder-wide agreements in the top-level CLAUDE.md and project-specific considerations in that project's CLAUDE.md. You can check which files are currently loaded by running /context during a session to view the list under "Memory files."

How CLAUDE.md Files Are Loaded

1. 1. LaunchConcatenates and reads CLAUDE.md files in the current folder and parent directories
2. 2. WorkActs based on documented guidelines
3. 3. Work with files in a subfolderLoads that folder's CLAUDE.md additionally
4. 4. VerifyCheck the loaded list with /context

Let /init Generate Your First Draft

If starting from a blank page feels daunting, run /init. Claude inspects the folder contents and creates a draft detailing what it finds, such as build instructions and conventions. According to the official docs, if a CLAUDE.md already exists, it proposes improvements rather than overwriting it. However, it can only automatically discover what is evident from the code. Specific nuances like "it breaks in this environment unless you do it this way" must be added manually afterward.

Example House Rules

In my CLAUDE.md, I document guidelines I want followed across projects. Adapted for home automation, it looks like this:

# House Rules

## Windows Notes
- Do not activate Python virtual environments (Activate.ps1).
  Call python.exe inside the venv by its full path.
  Reason: Execution policy blocks .ps1 execution.
  Example: "C:\path\to\.venvs\myproject\Scripts\python.exe" main.py
- Save .ps1 files containing non-ASCII characters (such as Japanese) with UTF-8 BOM.
  Reason: Without a BOM, PowerShell 5.1 throws syntax errors.

## Automated Scripts
- For unattended execution via Task Scheduler, create the venv outside OneDrive
  ($env:USERPROFILE\.venvs\myproject).
  Reason: Files have disappeared during sync in the past.

## Research Notes
- Record findings even when the conclusion is "could not be done."
  Reason: Without notes, you end up redoing the same investigation from scratch on another day.

As shown in this example, each entry pairs "what to do" with "why." I covered venv placement in A Python venv Inside OneDrive Can Break Your Scheduled Scripts, and setting up automated execution in Run Claude Code Automatically Every Day with Windows Task Scheduler.

Tips for Writing

Be Specific

The official documentation recommends writing verifiable instructions. For example, specify "2-space indentation" instead of "format the code," or "run npm test before committing" instead of "test it." Saying "call python.exe in the venv by its full path" is far more likely to be followed than "be careful with the Python environment."

Include Reasons and Examples

This comes from my own experience rather than official recommendations. Adding reasons provides guidance for similar scenarios that are not explicitly documented. Including a one-line example of a past failure also helps you judge whether the rule is still necessary when reviewing it later.

Keep It Concise and Prune Outdated Entries

The official documentation suggests keeping a single file under 200 lines. Longer files consume more context and make instructions harder to follow. It also notes that if instructions conflict, Claude may arbitrarily pick one. Since files bloat quickly if you only add to them, trim duplicates and outdated notes once readability declines. Running /doctor prompt-audit surfaces stale instructions and contradictions (available in Claude Code v2.1.283 and later). While you can include other files using the @path syntax, imported files are also read at startup and do not save context.

Choosing Between CLAUDE.md and Auto-Memory

Claude Code also features "auto-memory," where Claude accumulates notes on its own. According to official documentation, the differences are as follows:

Auto-memory is enabled by default in local sessions. It is stored at ~/.claude/projects/<project>/memory/, where MEMORY.md serves as an index and detailed notes are split into topic-specific files. Running /memory lets you view and edit contents or toggle the feature on and off. If you ask Claude to "add this to CLAUDE.md," Claude will add it for you.

My approach is to put rules I want followed into CLAUDE.md, and leave context notes that emerge during conversation—such as "here is the background on this issue"—to auto-memory. Because I prefer to review and update rules myself, keeping them in a local file gives me greater peace of mind.

Summary

• CLAUDE.md is an instruction file for documenting recurring notes. It is read as context rather than hard enforcement.
• Scope depends on location: global preferences in ~/.claude/CLAUDE.md, project rules in ./CLAUDE.md, and special circumstances in subfolders.
• Start with /init to create a draft, then manually add rules unique to your environment.
• Keep instructions specific, concise, and backed by reasons. Prune them as they become outdated.
• It serves a different purpose than Claude's auto-memory. Keep deliberate rules in CLAUDE.md.