Auto Memory система: типы памяти и MEMORY.md

📖 Теория

Что такое Auto Memory?

Auto Memory — это персистентная файловая система памяти Claude Code, которая хранит информацию между сессиями в директории ~/.claude/projects/<project>/memory/.

Зачем нужна память?

• Claude не помнит прошлые сессии
• Вы не хотите повторять контекст каждый раз
• Важные решения должны оставаться видимыми
• Обратная связь от вас — ценный актив

Четыре типа памяти

Тип	Когда сохранять	Примеры
user	Информация о пользователе	Роль (senior developer), знания (эксперт в Go), предпочтения (краткие ответы)
feedback	Обратная связь о подходе	"Не мокай базу в тестах", "Используй серверную пагинацию, не клиентскую"
project	Текущая работа и цели	Дедлайны, кто что делает, почему выбрали этот подход
reference	Где искать информацию	"Баги в Linear проекте INGEST", "Дашборд oncall: grafana.internal/d/api-latency"

Структура памяти

~/.claude/projects/my-project/memory/
├── MEMORY.md           # Индекс (всегда загружается)
├── user_role.md        # user тип
├── feedback_testing.md # feedback тип
├── project_deadline.md # project тип
└── reference_bugs.md   # reference тип

MEMORY.md — это индекс. Claude всегда читает его. Каждая строка — указатель на файл:

- [Роль пользователя](user_role.md) — senior backend developer, эксперт Go
- [Правило тестирования](feedback_testing.md) — не мокай базу, используй testcontainers
- [Дедлайн релиза](project_deadline.md) — мобильная команда режет ветку 2026-03-05
- [Баги в Linear](reference_bugs.md) — проект INGEST для багов пайплайна

Формат файла памяти

Каждый файл памяти имеет frontmatter:

---
name: feedback-testing
description: Правило тестирования базы данных
metadata:
  type: feedback
---

Не мокай базу данных в интеграционных тестах.

**Why:** Прошлым кварталом мокнутые тесты прошли, но prod миграция упала.

**How to apply:** Используй testcontainers для реальной БД в тестах.

Что НЕ сохранять в память

• ❌ Код, паттерны, архитектура — это в коде, не в памяти
• ❌ Git история — для этого есть git log
• ❌ Решения багов — это в коммитах
• ❌ Эфемерные задачи — текущая сессия не нуждается в персистентности
• ❌ Документация — это в CLAUDE.md или README

Команда /remember

Явное сохранение в память:

/remember Я предпочитаю короткие ответы без лишних объяснений.

Claude спросит тип памяти (user/feedback/project/reference) и сохранит.

🛠 Практика

Пример 1: Сохранение информации о пользователе

/remember Я senior backend developer с 10 годами опыта в Go. Знаю Kubernetes, PostgreSQL, Redis. Предпочитаю краткие технические ответы без введений.

Claude создаст user_role.md:

---
name: user-role
description: Senior backend developer, Go expert
metadata:
  type: user
---

Пользователь — senior backend developer с 10 годами опыта в Go.

**Технологии:** Kubernetes, PostgreSQL, Redis

**Стиль общения:** Краткие технические ответы, без введений и объяснений основ.

Пример 2: Сохранение feedback (обратная связь)

Вы говорите Claude:

Не используй моки для базы данных в тестах. Прошлым кварталом мокнутые тесты прошли, но prod миграция упала. Используй testcontainers.

Claude отвечает:

Понял, буду использовать реальную БД через testcontainers. Сохранить это правило в память?

Вы: "Да"

Claude создаёт feedback_testing.md с типом feedback и структурой:

• Правило
• Why: причина (инцидент)
• How to apply: как применять

Пример 3: Сохранение project информации

/remember Мы замораживаем все некритичные мержи после 2026-03-05. Мобильная команда режет release branch.

Claude создаёт project_freeze.md:

---
name: project-freeze
description: Merge freeze начинается 2026-03-05
metadata:
  type: project
---

Merge freeze начинается 2026-03-05 для release cut мобильной команды.

**Why:** Мобильная команда режет release branch, нужна стабильность.

**How to apply:** Флагнуть любые некритичные PR после этой даты.

Пример 4: Сохранение reference (ссылки)

/remember Баги пайплайна трекаются в Linear проекте "INGEST". Oncall дашборд: grafana.internal/d/api-latency

Claude создаёт reference_external.md:

---
name: reference-external
description: Где искать баги и метрики
metadata:
  type: reference
---

**Баги пайплайна:** Linear проект "INGEST"

**Oncall dashboard:** grafana.internal/d/api-latency — мониторинг latency, который пейджит oncall

Пример 5: Связывание памяти через [[name]]

В файле памяти можно ссылаться на другие записи:

Мы выбрали серверную пагинацию вместо клиентской.

**Why:** См. [[feedback-performance]] — клиентская пагинация не масштабируется на 50K товаров.

**How to apply:** Всегда используй LIMIT/OFFSET на уровне БД.

Пример 6: Использование памяти в новой сессии

Новая сессия, вы говорите:

Добавь пагинацию в /api/products

Claude автоматически загружает память и видит:

• Пользователь — senior Go developer
• Feedback — использовать серверную пагинацию
• Feedback — не мокать базу в тестах

Claude отвечает кратко (стиль пользователя) и сразу предлагает серверную пагинацию с testcontainers тестами.

📝 Домашнее задание

🎓 После урока вы умеете

• Различать 4 типа памяти: user, feedback, project, reference
• Использовать /remember для явного сохранения
• Структурировать feedback с Why и How to apply
• Связывать записи памяти через [[name]]
• Понимать, что НЕ нужно сохранять в память
• Работать с MEMORY.md как с индексом

⚠️ Частые ошибки

1. Сохранение кода в память

Ошибка: "Сохрани этот код в память."

Правильно: Код живёт в файлах проекта. В память сохраняется РЕШЕНИЕ, почему выбрали этот подход.

2. Сохранение эфемерных задач

Ошибка: "/remember Сейчас работаю над багом #123"

Правильно: Текущая задача не нуждается в памяти между сессиями.

3. Дублирование документации

Ошибка: Сохранять в память то, что уже есть в README или CLAUDE.md

Правильно: Память для неожиданных решений и feedback, не для документации.

4. Отсутствие Why

Ошибка: "Не используй моки" без объяснения причины.

Правильно: Всегда добавлять **Why:** — почему это правило существует.

💡 Продвинутые техники

Структура feedback для команды

Если в проекте несколько человек, используйте общие правила:

---
name: team-feedback-auth
description: Архитектура аутентификации (командное решение)
metadata:
  type: feedback
---

Auth middleware переписывается из-за compliance requirements от legal.

**Why:** Старый middleware хранил session tokens не по новым требованиям.

**How to apply:** Все scope решения должны приоритизировать compliance над ergonomics.

**Team decision:** 2026-02-15, участники: @alice, @bob, @charlie

Экспирация project памяти

Project память быстро устаревает. Добавляйте даты:

**Valid until:** 2026-03-10

После этой даты memory может быть неактуальна — перепроверьте с командой.

Linking с другими файлами

Ссылайтесь на реальные файлы проекта:

См. `docs/architecture.md` для полного контекста.

См. [[feedback-database]] для связанного правила.

🔗 Связанные инструменты

• CLAUDE.md — правила проекта (всегда загружается)
• MEMORY.md — индекс памяти (всегда загружается)
• /remember — команда для явного сохранения
• Superpowers brainstorming — результаты можно сохранить в память

🔍 Проверка памяти

Посмотреть, что Claude помнит о проекте:

ls ~/.claude/projects/<project>/memory/

Прочитать индекс:

cat ~/.claude/projects/<project>/memory/MEMORY.md

Прочитать конкретную запись:

cat ~/.claude/projects/<project>/memory/feedback_testing.md