using-memorylisted

# Using the auto-memory system The harness on this machine maintains a memory directory at `~/.claude/projects/<project-slug>/memory/`. `MEMORY.md` inside that directory is the index. Individual memory files live alongside it. Memory is loaded into Claude's context at session start - so its quality directly affects every future answer. ## When to trigger - The user states a durable preference, role, or working style. - The user corrects something Claude got wrong and wants the correction to stick. - A project-specific fact emerges that is not in CLAUDE.md (and should not be, e.g. machine paths). - You hit a piece of memory that is wrong or stale. ## What belongs in memory Four categories. Use the same tags as filenames or front-matter so future-you can sort them. - **user** - the user's role, preferences, working style, recurring conventions. Example: "Prefers terse PR descriptions, no emojis." - **feedback** - corrections from past sessions. Example: "When asked to 'run tests', means the integration suite, not unit tests." - **project** - long-lived facts about a specific project that are not yet in its CLAUDE.md. Example: "The `analytics` service deploys via the `legacy` pipeline, not Argo." - **reference** - pointers to external resources Claude should consult. Example: "Internal API docs at https://wiki.example.com/api - requires VPN." Memory entries are short. One claim per entry, with enough context to be useful out of session. ## What does NOT belong in memory