daBongo LMS AI Training Courses

Lesson Content

The memory layer most users never know exists.

The auto-memory system is the deepest and most sophisticated layer of Claude's memory stack. It is specific to Claude Code mode. It allows Claude to maintain a persistent, file-based knowledge base about you – who you are, what you have learned, what you are working on, and where to find important information – that grows more complete and more useful over every session.

Most users never discover it because it is not surfaced in the main interface. The files exist on your local machine, and Claude writes to and reads from them automatically across sessions.

How it works.

The auto-memory system stores information in markdown files in a directory on your computer, typically under your user Claude configuration folder. There is an index file (MEMORY.md) that lists all memory entries as a navigable index, and individual memory files for each entry.

At the start of every Claude Code session, Claude reads the MEMORY.md index and the relevant memory files to re-establish its knowledge about you. At any point in a session, you can ask Claude to save something to memory, or Claude may proactively identify something worth saving and write a new memory entry.

You can view, edit, and delete memory entries at any time using the /memory command in Claude Code mode.

The four memory types.

The auto-memory system uses four categories, each storing a different kind of information:

User memory: Information about you as a person – your background, role, goals, knowledge level, working preferences, and how you like to collaborate. This is what lets Claude know it is talking to a 30-year QA veteran rather than a first-time user. Example entry: "User is a software QA professional with 30+ years experience, currently focused on LMS development. Prefers direct, concise responses. Learns by doing – appreciates examples over abstract theory."

Feedback memory: Guidance you have given Claude about how to approach work – corrections, confirmations, things to avoid, things to keep doing. This is how Claude learns from your explicit feedback over time. Example entry: "Do not add trailing summaries to responses unless explicitly asked. User has confirmed this preference multiple times. Why: they find summaries redundant and prefer to read the diff directly."

Project memory: Information about ongoing work, goals, initiatives, and context that changes over time but is too detailed for Custom Instructions. Example entry: "Current primary project: Dabongo LMS WordPress plugin. Status: active development and course content creation. Goal: import-ready course bundles for multiple AI services. Timeline: ongoing through 2026."

Reference memory: Pointers to where information can be found in external systems. Example entry: "Course files are stored at C:UserscongoDocumentsWeb WorkdaBongoLMS-wordpressCourses-Lessons Files. Header file for Claude AI bundle is at Claude AIclaude-ai-course-path-HEADER.md."

Asking Claude to save to memory.

You can direct Claude to save any information at any time: "Remember that I prefer snake_case for all variable names in this project." "Save this as a reference: the production database connection string uses the DB_PROD environment variable." "Note in memory that we decided to use JSON rather than CSV for the export format."

Claude will write the appropriate memory file and confirm what it saved.

Maintaining your memory files.

Memory files are markdown files you can read and edit directly. Good maintenance habits:

• Review your memory files every few weeks using /memory
• Update project memory entries when project status changes
• Remove feedback memory entries that are no longer relevant
• Check that user memory entries still accurately describe you
• Delete memory entries about completed or abandoned projects

Stale memory – entries that describe a past state of your work or preferences – can actually degrade Claude's performance if it acts on outdated context. Regular maintenance keeps the memory system useful.