Memory у Claude Code: MEMORY.md, типи спогадів, ручне редагування
Версія CC з auto-memory (стандартна у 2026). Доступ до ~/.claude/projects/<slug>/memory/ — slug автогенерується з робочого каталогу при першій сесії. Корисно мати текстовий редактор з підтримкою YAML-frontmatter (VS Code, vim з підсвічуванням).
Що таке memory у двох реченнях
Memory — це file-based persistent storage у ~/.claude/projects/<slug>/memory/. Кожен спогад — окремий .md-файл з фронтматером (тип, name, description) і тілом. Індекс — MEMORY.md з рядком на кожен файл.
Memory не зберігає діалоги — для цього є /resume. Не зберігає файли проєкту — для цього є git. Memory зберігає висновки: про користувача, про правила гри, про стан проєкту, про зовнішні ресурси.
Структура каталогу
~/.claude/projects/E--EDT-dle/memory/ ├── MEMORY.md # індекс — один рядок на спогад ├── user_role.md # хто користувач ├── feedback_phpbb_posting.md # правила поведінки ├── project_dle_site.md # стан проєкту ├── reference_dle_uploads_files_whitelist.md # дані про зовнішнє └── ...
MEMORY.md — це індекс, не контейнер. CC при старті бачить його повністю (до ~200 рядків), і використовує як точку входу. Якщо рядок зацікавив — CC підтягне відповідний файл.
4 типи спогадів
| Тип | Про що | Як використовуєш |
|---|---|---|
user | Про людину: роль, експертиза, уподобання | CC підлаштовує тон і деталізацію під твою аудиторію |
feedback | Правила поведінки: «не роби X», «роби Y» | CC застосовує без нагадувань |
project | Стан робіт, рішення, інциденти у проєкті | CC дотягує контекст у пропозиції |
reference | Куди дивитися: URL, IDs зовнішніх систем | CC підказує точне місце |
Структура файлу:
--- name: phpBB posting quirks description: Особливості публікації на forum.it-format — :80 redirect, server clock drift, founder moderation type: feedback --- Якщо публікація через HTTP падає з FORM_INVALID — перевір: 1. URL без `:80` (форум редіректить на https-логін) 2. Server clock drift — у нашому випадку +40 сек проти UTC...
Що НЕ зберігати у memory
Це часто плутає новачків — і призводить до купи застарілих спогадів.
- Конвенції коду, структуру файлів, шляхи. Це деривовно з самого проєкту (Read + Glob).
- Git історію.
git logавторитетний. - Рецепти баг-фіксів. Фікс уже в коді; контекст — у commit message.
- Все, що вже є у CLAUDE.md. Це дублювання.
- Ephemeral state. Поточна задача, тимчасові висновки, in-progress робота — тримай у плані сесії, не у memory.
Правило: спогад має сенс, якщо без нього довелось би пояснити те саме у наступній сесії. Якщо «це є у коді» — не зберігай. Якщо «це я скажу йому ще раз» — зберігай.
Реальні кейси
1. Як виглядає MEMORY.md після місяця роботи
Приклад фрагмента (анонімізовано):
- [DLE anti-brute is aggressive](feedback_dle_antibrute.md) — ніколи не ретраїти логін DLE, IP банить миттєво
- [Article markup conventions](reference_article_markup_conventions.md) — <pre> з кнопкою Копіювати, callout-блоки
- [Статті — циклами-проектами](feedback_article_cycles_approach.md) — кожна стаття частина циклу
- [DLE 12 theme gotchas](reference_dle_theme_gotchas.md) — allow_smartphone override, {php} не виконується
- [phpBB email pipeline](reference_phpbb_email_pipeline.md) — flow, точки збою, 24 підписники
Це індекс. Кожен рядок — посилання на окремий файл з повним змістом. Корисний рівно тому, що CC бачить весь індекс при старті — і вирішує, що треба підтягти, не плутаючись у деталях усіх 40 файлів.
2. Як зберегти feedback після pushback'у
Ти сказав CC «не використовуй git push --force, був прецедент». CC має це запам'ятати. Створює файл:
--- name: Avoid git push --force description: Корисно знати — push --force заборонено у цьому репо. Реальний інцидент 2026-03 з перезаписом колеги. type: feedback --- Не використовуй `git push --force` у цьому репо. **Why:** Інцидент 2026-03-15 — push --force перезаписав 3 коміти колеги, що готувались до релізу. **How to apply:** Перевикористовуй rebase з обов'язковим reading log перед push. Замість force — `git push --force-with-lease` (як мінімум).
Зверни увагу: лід-фраза + Why + How to apply — це структура з мого власного шаблону. Дозволяє CC потім судити edge cases, а не сліпо застосовувати правило.
3. Спогад застарів — стерти
Project-спогад про «реліз 2026-04-15» через місяць застарів. Можна:
- Видалити файл руками —
rm ~/.claude/projects/<slug>/memory/project_release_2026_04.md. - Прибрати рядок з
MEMORY.md— інакше CC буде бачити мертве посилання. - Або через slash
/memory— інтерактивний редактор.
Гігієна memory — раз на квартал перевіряти індекс: «що тут вже не актуальне?». Корисно після завершення великих проєктів.
4. Memory для типу user — як CC підлаштовує тон
Якщо у memory є user_role.md з «користувач — senior sysadmin, 15+ років досвіду, не люблю розжовування очевидного» — CC не пише «крок 1: відкрий термінал». Натомість: «робиш стандартний netstat для перевірки X». Економить контекст і не дратує.
Підводні камені
Sub-агенти НЕ читають memory автоматично. Якщо у твоїй memory є важливий feedback («не пиши коментарі без потреби»), і ти запускаєш sub-агента писати код — він напише з коментарями, бо memory не успадковує. Або повтори правила у prompt, або у prompt вкажи «прочитай ~/.claude/projects/<slug>/memory/MEMORY.md».
Скіли теж не успадковують. Якщо скіл запускається у новій сесії (наприклад, через cron), і ти очікуєш, що він буде слідувати feedback-правилам — поточається. У SKILL.md явно інструктуй: «прочитай MEMORY.md перед роботою».
Креди у memory = небезпека. Memory не зашифрована. Якщо випадково зберігся пароль або токен — він читається будь-яким процесом твого користувача. Перевір grep -ri 'password|token|secret' ~/.claude/projects/ після перших тижнів. Все, що знайдеш — переноси у .env з chmod 600 або у keyring.
MEMORY.md довший 200 рядків — обрізається. CC бачить тільки перші ~200 рядків. Якщо твій індекс розрісся — групуй по темах, видаляй мертве, виноси деталі у файли.
Конфлікти спогадів. Два feedback-файли, що один одному суперечать («використовуй pytest» vs «використовуй unittest») — CC вибере довільний. Періодично перевіряй несумісні правила. git diff не допомагає — memory не у git.
Stale memory часто гірший за відсутність. Спогад «реліз 2.4 заплановано на 2026-04-15» через місяць може спровокувати CC давати поради, що базуються на застарілому стані. Якщо memory старша 3 місяців і стосується змінного контексту — перевір актуальність перед використанням.
Як редагувати MEMORY.md
- Slash
/memory— інтерактивний редактор; найзручніший для швидкого огляду. - Руками у файлі
~/.claude/projects/<slug>/memory/MEMORY.md+ окремі.md-файли. - Через prompt у сесії: «зайди у memory, оновии запис про X» — CC сам прочитає, оновить, перепише.
Якщо плануєш масові правки (видалити 10+ застарілих) — швидше руками через текстовий редактор. Якщо точкові (виправити один рядок) — через slash або prompt.
Cross-refs
- Редактор — slash
/memory. - Скіли і memory — «Власні скіли».
- Sub-агенти і memory — «Sub-агенти».
- MEMORY.md ≤ 200 рядків; якщо більше — обрізати або групувати.
- Жодного запам'ятовування того, що читається з коду / git / docs.
- Ніяких credentials у файлах memory.
- Кожен спогад має чіткий тип (user/feedback/project/reference), не «змішаний».
- Feedback-спогади містять Why і How to apply — це дозволяє моделі судити edge cases.
- Project-спогади містять дату — це critical для оцінки актуальності.
- Раз на квартал — побіжний огляд: «що тут вже не актуальне?».
- Перевірено перед запуском sub-агента: чи потрібні правила з memory повторені у prompt.
Auto-memory — найновіший шар CC, з'явився у 2025-2026. Структура може ще змінитись (наприклад, додатися cloud-sync між машинами). Свіже — /memory у сесії і documentation Anthropic.
