Перечень долгой памяти
Долгая память — это набор маленьких файлов на диске. Каждый хранит один факт и всплывает в контекст по релевантности к текущей задаче — в том числе когда основной контекст уже переполнен и договорённости из начала сессии «выпали».
Как организованы файлы
Правила и логи в проекте живут на двух уровнях — репозитория и отдельного проекта:
- Уровень репозитория (общий для всех проектов):
CLAUDE.md— правила и технические принципы, касающиеся всех проектов (грузятся в контекст в начале каждой сессии); корневойuser_commands.md— лог общей / инфраструктурной работы, не привязанной к конкретному проекту. - Уровень каждого проекта (только про него): свои
user_instructions.md,tech_instructions.mdиuser_commands.md— в них только то, что касается этого проекта.
Ниже — переиспользуемые правила, очищенные от привязки к конкретным проектам.
Архитектура вслух — до и после
Для всего сложного (новый сервис, эндпойнты, схема хранилища, интеграция с внешним API, авторизация, заметный рефактор): до кода — разложить план (компоненты и потоки данных, структура API, структура БД, авторизация и где секреты, риски и альтернативы, этапы) и дождаться подтверждения. После — снова разложить архитектуру по факту: что получилось, что изменилось относительно плана и почему, какие грабли вылезли. Мелкие правки — без этого ритуала.
Тестируй перед сдачей — всегда
«Скомпилировалось» и «задеплоил» — это не проверка. После правки — прогон реального сценария: фронтенд через браузерную автоматизацию (кликнуть, ввести, увидеть, измерить геометрию), API — реальным запросом с разбором ответа. Проверять оба состояния (с данными и без, до и после), а не только «счастливый путь» — половина багов живёт именно во втором. Тяжёлые прогоны запускать сабагентами, чтобы основной контекст не забивался дампами. Докладывать честно: не проверено — так и сказать.
Документация на каждый проект
В каждом проекте держим три файла: user_instructions.md (для пользователя — весь видимый функционал), tech_instructions.md (для разработчика — стек, структура, ключевые модули, потоки данных, грабли) и user_commands.md (лог работы по проекту). На уровне всего репозитория им соответствуют общий CLAUDE.md и корневой user_commands.md — для того, что касается всех проектов. Доки проекта обновляем в той же правке, что и код, чтобы они всегда описывали проект целиком. Зачем: когда у модели закончится контекст, именно они — опора, чтобы восстановить полную картину без чтения всего кода.
Лаконичные тексты правил — один каноничный источник
Глобальный принцип не размазываем по всем сущностям. Если правило касается всех — записываем его один раз в общем месте, а в правилах конкретных сущностей держим только специфичное для них. На уровне всего проекта таким общим местом служит CLAUDE.md (правила и технические принципы) или корневой user_commands.md (если это лог всей работы); у отдельного скилла — его инструкция. Boilerplate-повторы одного и того же мешают видеть содержательное. Перед массовой рассылкой одного текста по многим объектам — остановиться и выбрать единственное место.
Лог команд по проектам
Лог называется user_commands.md и ведётся на двух уровнях: корневой в репозитории — для общих / инфраструктурных задач, и отдельный user_commands.md в папке каждого проекта — для работы именно по нему. После выполненной просьбы дописываем короткую запись в соответствующий лог (что просили + что сделано), а не в один общий файл. Формат: под датой, буллетами, кратко, со ссылками на файлы. Делать это самому, без напоминаний.
Стандарты сервисов
Комментарии в коде — на английском (докстринги, описания эндпойнтов). Грамотная обработка ошибок: всё, что может упасть (сеть, парсинг, доступ к БД, 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 сборки, локальные конфиги, ключи, зависимости) — сразу дополняем, чтобы мусор не попадал в репозиторий. При этом релизные артефакты (собранные бинарники под распространение) наоборот держим под версиями специально — это удобный способ их раздавать; игнорим только промежуточные каталоги сборки.