Перечень долгой памяти
Долгая память — это набор маленьких файлов на диске. Каждый хранит один факт и всплывает в контекст по релевантности к текущей задаче — в том числе когда основной контекст уже переполнен и договорённости из начала сессии «выпали».
Как это устроено
Механика простая и полностью на файлах, без базы данных:
- Один файл = один факт. Не сваливаем всё в один документ — так проще обновлять и удалять устаревшее.
- Frontmatter у каждого файла:
name(короткий slug),description(одна строка — по ней решается релевантность при вспоминании) иtype. - Два типа.
feedback— как агент должен работать (в теле — сам факт, затем строки Why и How to apply);reference— указатели на внешние ресурсы. - Индекс
MEMORY.md— одна строка на факт, грузится в контекст в начале каждой сессии. Содержимое самих фактов туда не кладём. - Связи
[[name]]между файлами — линкуем родственные правила, чтобы всплывали вместе. - Пишем только неочевидное. То, что и так видно из кода или истории, в память не дублируем. Ошибочное — удаляем.
Ниже — переиспользуемые правила (тип feedback), очищенные от привязки к конкретным проектам.
Архитектура вслух — до и после
Для всего сложного (новый сервис, эндпойнты, схема хранилища, интеграция с внешним API, авторизация, заметный рефактор): до кода — разложить план (компоненты и потоки данных, структура API, структура БД, авторизация и где секреты, риски и альтернативы, этапы) и дождаться подтверждения. После — снова разложить архитектуру по факту: что получилось, что изменилось относительно плана и почему, какие грабли вылезли. Мелкие правки — без этого ритуала.
Тестируй перед сдачей — всегда
«Скомпилировалось» и «задеплоил» — это не проверка. После правки — прогон реального сценария: фронтенд через браузерную автоматизацию (кликнуть, ввести, увидеть, измерить геометрию), API — реальным запросом с разбором ответа. Проверять оба состояния (с данными и без, до и после), а не только «счастливый путь» — половина багов живёт именно во втором. Тяжёлые прогоны запускать сабагентами, чтобы основной контекст не забивался дампами. Докладывать честно: не проверено — так и сказать.
Не выдумывать контент при публикации
При публикации из черновика/конфига постим и создаём ровно то, что там есть. Пустое поле — это решение автора или сигнал спросить, а не пробел, который надо «услужливо» заполнить по шаблону. Особенно когда результат уходит живым людям — откатывать неловко и дорого. Дефолты-шаблоны применяются на этапе составления черновика (с показом автору), а не на этапе публикации.
Два файла документации на каждый проект
В каждом проекте/модуле держим user_instructions.md (для пользователя — весь видимый функционал) и tech_instructions.md (для разработчика — стек, структура, ключевые модули, потоки данных, грабли). Обновляем их в той же правке, что и код, чтобы они всегда описывали проект целиком. Зачем: когда у модели закончится контекст, именно эти файлы — опора, чтобы восстановить полную картину без чтения всего кода.
Лаконичные тексты правил — один каноничный источник
Глобальный принцип не размазываем по всем сущностям. Если правило касается всех — записываем его один раз в общем месте (инструкция скилла / tech-доки), а в правилах конкретных сущностей держим только специфичное для них. Boilerplate-повторы одного и того же мешают видеть содержательное. Перед массовой рассылкой одного текста по многим объектам — остановиться и выбрать единственное место.
Лог команд по проектам
После выполненной просьбы дописываем короткую запись в лог соответствующего проекта/модуля (что просили + что сделано), а не в один общий файл. Общие/инфраструктурные задачи — в корневой лог. Формат: под датой, буллетами, кратко, со ссылками на файлы. Делать это самому, без напоминаний.
Стандарты сервисов
Комментарии в коде — на английском (докстринги, описания эндпойнтов). Грамотная обработка ошибок: всё, что может упасть (сеть, парсинг, доступ к БД, AI-запрос), оборачиваем в проверку с понятным сообщением пользователю и логом для разработчика — не глотать молча, на бэке корректный HTTP-код, на фронте человеческое сообщение. Мобильная вёрстка: любой фронтенд работает от ~320px — flex/grid, единицы rem/%/vh/vw, viewport-meta, touch-цели минимум 44×44px.
Единый дизайн (референс shadcn/ui)
Все фронтенды — в одном чистом «системном» стиле: нейтральная база + один акцент, дизайн-токены как CSS-переменные (--background, --foreground, --border, --ring…), светлая и тёмная темы, аккуратные карточки и кнопки с тонкими границами, мягкие тени, скругления через --radius, заметные focus-ring. Системный sans-serif, ограниченная ширина контента. Без агрессивных градиентов и неона.
Без эмодзи-иконок в интерфейсе
Иконки — только из нормального набора (по умолчанию Lucide): inline-SVG, stroke: currentColor, размер через CSS. Эмодзи допустимы лишь там, где нет CSS — например в тексте, который копируется в буфер или уходит в мессенджер. Цвет-категорию показываем кружком-<span> с background, а не эмодзи. Исключение — «знак» приложения (фавиконка, OG-теги, лого в шапке): там inline-SVG не выживает, поэтому эмодзи уместен.
Меньше окон «Allow this command?»
Чтобы харнесс не спрашивал разрешение на каждую безопасную команду, рабочий механизм — широкий allow-список в глобальном ~/.claude/settings.json: правила уровня инструмента (Bash, WebFetch, WebSearch) разрешают такие вызовы без окна во всех проектах. Жёсткий deny-список (напр. деструктивные команды) остаётся страховкой и перебивает общий allow. Если окно вернулось — проверь, что правило не затёрлось при пересохранении файла.
Гигиена .gitignore
Держим .gitignore актуальным: как только появляются новые сборочные/служебные артефакты (кэши, output сборки, локальные конфиги, ключи, зависимости) — сразу дополняем, чтобы мусор не попадал в репозиторий. При этом релизные артефакты (собранные бинарники под распространение) наоборот держим под версиями специально — это удобный способ их раздавать; игнорим только промежуточные каталоги сборки.