Мой CLAUDE.md — 582 строки. Вот зачем

от автора

Каждый новый чат с Claude Code начинается с нуля. Агент не знает ваш проект, не помнит что вы обсуждали час назад в соседнем окне, не в курсе что на этом сервере нельзя трогать определённый порт. Вы объясняете одно и то же в пятый раз, и на шестой он всё равно полезет “чинить” конфиг который работал нормально.

Каждую неделю в r/ClaudeAI новая история. Агент удалил production базу. Агент запушил секреты в публичный репо. Агент “оптимизировал” billing-сервис и выставил клиентам нулевые счета. И каждый раз думаешь: очень не хочется стать этим человеком из заголовков.

CLAUDE.md должен решать обе проблемы: и контекст между сессиями, и защиту от катастроф. Типичный CLAUDE.md на 5-10 строк не решает ни одну. Я решила подойти к этому системно — не по одной проблеме за раз, а как к архитектурной задаче.

Сейчас мой конфиг — 582 строки, 6 слоёв, и за каждым правилом стоит конкретная история.

Три случая которые всё изменили

Агент “починил” рабочую систему. Воскресенье вечером. Агент видит в конфиге 127.0.0.1 для внешнего сервиса хранения. Решает что предыдущая сессия оставила ошибку — вместо реального адреса стоит localhost. Логично, правда? Он заменяет на настоящий IP. Upload ломается. Дальше полчаса дебага, прежде чем понимаешь: это был SNI-proxy через локальный туннель, 127.0.0.1 был правильным значением. Без контекста очевидное решение оказалось катастрофой.

Правило которое появилось: “не менять конфиги без понимания зачем текущие значения такие. Если значение выглядит странно — сначала понять, потом действовать.”

fail2ban принял агента за брутфорсера. Агент проверял состояние сервера. Для каждой проверки он открывал новое SSH-подключение. Десяток подключений за минуту — fail2ban интерпретировал как brute-force и заблокировал IP на полчаса. В это время на сервере шла тренировка модели, и я потеряла к ней доступ.

Правило: “один SSH-мост на всё. Один клиент на сессию. Не писать отдельные скрипты для check, fix, verify — объединять в один.”

“Отфильтровать” оказалось “удалить”. Я попросила отфильтровать датасет — убрать неподходящие изображения. Агент интерпретировал буквально: удалил файлы. Не переместил, не пометил — удалил. Данные пропали.

Правило: “‘фильтрация’ = переместить или пометить, не удалить. Перед любым удалением убедиться что пользователь явно попросил именно удалить.”

Написать “будь аккуратен” не работает. Нужна система.

6 слоёв: как это устроено

Ни один слой не был запланирован. Каждый появился после конкретной проблемы.

Слой 1: Rules (9 файлов). Набор правил которые подгружаются по ситуации. Агент пишет статью — ему не нужны правила про SSH. Дебажит код — не нужны правила про оформление текста. Claude Code умеет подключать нужные rules-файлы в зависимости от задачи.

Слой 2: Memory (78 файлов). Появилась когда агент в третий раз забыл конфигурацию сервера. Между сессиями он теперь запоминает: настройки инфраструктуры, решения по проектам, мои предпочтения, прошлые ошибки. Файлы связаны ссылками [[filename]] — 178 перекрёстных ссылок, получается граф знаний из обычного markdown. Часть грузится всегда (базовые правила), остальное — по теме.

Слой 3: Handoffs. Появились когда новый чат повторил тупик предыдущего. При закрытии чата агент записывает сводку: что сделано, что НЕ получилось (самая ценная часть), одно следующее действие. Вот реальный handoff:

## Цель сессииColor checker: CNN sweep + diffusion, первые визуальные результаты.## Сделано- CNN baseline: median 1.99 deg (11M params, 21 MB)- Sweep на 5 GPU: crop128(3.17), bs16(2.04), lr3e-4(NaN)- Diffusion training запущен: epoch 5/50, loss 0.827## НЕ сработало- EfficientNet-B0: hash mismatch в Docker image- lr=3e-4: NaN после epoch 10-13, нет gradient clipping- CNN визуально: 3 числа дают паразитные кастинги## Следующий шагInference скрипт для diffusion + visual sheets с 24 patches

Следующий чат читает 1500 токенов вместо того чтобы заново анализировать проект. За 4 дня накопилось 27 handoff’ов — ни один тупик не повторился. Работает не только между чатами: у меня три подписки (две рабочих, одна личная), и handoff позволяет стартовать в другой подписке без повторных объяснений.

Слой 4: Chronicles. Появились когда после 20 handoffs стало непонятно, почему проект вообще пришёл к текущему состоянию. Handoff отвечает “что дальше”. Хроника — “как сюда пришли”. Ключевые решения, повороты, тупики. 3-7 строк на каждую веху.

Слой 5: Hooks. Появились когда правило “проверяй ссылки в CLAUDE.md” перестало работать через 20 минут сессии. Об этом — отдельная секция ниже.

Слой 6: Skills (16 штук). Готовые наборы знаний для конкретных задач. Описание написано как триггер для модели: “используй когда: GPU зависло, нужна проверка здоровья сервера”, а не “помогает с серверами”.

Правило — пожелание. Hook — гарантия.

Это самый неочевидный вывод за месяц.

Правило в CLAUDE.md — инструкция в промпте. Агент может забыть, переинтерпретировать, проигнорировать на длинной сессии когда контекст забит другими вещами. Правило “проверяй ссылки перед работой” работало первые 10 минут. Потом агент увлекался задачей и забывал.

Hook — это Python-скрипт который Claude Code запускает автоматически при определённых событиях. SessionStart, Stop, PreToolUse. Скрипт не забывает, не переинтерпретирует. Он исполняется механически, каждый раз.

Пример — hook который напоминает записать handoff перед закрытием длинной сессии:

# remind_handoff.py (Stop hook, упрощённо)age = session_age_minutes()if age < 15:    return  # короткая сессия, не нужноif fresh_handoff_exists():    return  # уже записан# Блокируем закрытие и просим записать handoffprint(json.dumps({    "decision": "block",    "reason": f"Сессия {int(age)} мин, handoff не записан. "              f"Запиши в .claude/handoffs/ перед выходом."}))

Модель сама знает когда пора — когда задача завершена или контекст переполняется. Hook страхует от случаев когда она забыла.

Если что-то должно происходить гарантированно — это hook, не правило.

Одна строка конфига которая спасла от supply chain атаки

31 марта 2026 года группа Sapphire Sleet (DPRK) скомпрометировала официальный npm-пакет axios (~100M загрузок в неделю). Опубликовали версию 1.14.1 с вредоносным кодом. Окно: 3 часа, с 00:21 до 03:29 UTC.

В моём .npmrc стояла одна строка:

min-release-age=7

Пакеты опубликованные меньше 7 дней назад не устанавливаются. Большинство вредоносных пакетов обнаруживают за 1-3 дня, 7 дней — комфортный буфер.

Меня не затронуло. Одна строка в конфиге.

Аналогично для Python — в uv.toml:

exclude-newer = "7 days"

За конфигом — 37 papers

Многие правила пришли не из личного опыта, а из академических работ. 37 arxiv papers, переработанных в принципы. Вот те, которые изменили мой workflow больше всего:

Proof Loop. Агент говорит “тесты прошли” — проверяете, тесты не прошли. Proof Loop запрещает агенту подтверждать собственную работу. Нужны файлы-доказательства: вывод тестов, verdict от верификатора в свежей сессии, который не видел процесс создания. Источник.

Structured Reasoning. Вместо свободного “ну, может это, а может то” — формат: что точно знаем из кода и логов → пошаговая трассировка → что следует → какие гипотезы проверили и отбросили. На реальных патчах accuracy с 78% до 93%. Источник.

Deterministic Orchestration. Если задача детерминированная — тесты, линтер, форматирование — она идёт через shell-скрипт. Модель плохо считает, теряет счётчики, путает условия в циклах. Скрипт — нет.

Red Lines. Обычные правила агент может интерпретировать “творчески”. Red Lines — абсолютные запреты без исключений. “Не удалять без подтверждения.” “Не менять production конфиги без понимания.” Каждый привязан к инциденту. Паттерн из китайского инженерного сообщества (红线).

Остальные принципы — generator-evaluator, autoresearch, multi-agent decomposition, codified context, agent security, documentation integrity и ещё 7 — подробно описаны в репозитории.

Цифры

78 memory файлов. 178 перекрёстных ссылок. 27 handoffs за 4 дня. 96.9% KV-cache hit rate на 83 сессиях за неделю.

Файл конфигурации обновляет сам себя: после каждого изменения агент проверяет не устарели ли ссылки. SessionStart hook валидирует автоматически.

Работает ли идеально? Нет. При аудите нашлись 4 memory файла которые выпали из индекса. Documentation drift случился с системой, которая должна его предотвращать. Но без неё было бы хуже.

Чего не знаю

Не уверена что все принципы нужны каждому. Для большинства проектов, вероятно, хватит пяти: Deterministic Orchestration, Structured Reasoning, Supply Chain Defense, Codified Context, Handoffs.

Не уверена что 6 слоёв — минимум. Может я overengineered. Но за месяц ни разу не потерялся контекст и ни один тупик не повторился.

Один из принципов (Assumption Testing) прямо говорит: каждый компонент кодирует предположение о неспособности модели. Модели улучшаются. Убирайте компоненты и измеряйте — может какой-то из слоёв уже не нужен.

Попробовать

Скопировать в чат Claude Code:

https://github.com/AnastasiyaW/claude-code-config - изучи, выбери что подходитдля моей работы и настрой мой Claude Code

Начать с малого: Supply Chain Defense (одна строка в .npmrc) + Deterministic Orchestration (тесты через скрипты) + Structured Reasoning (формат дебага). Добавлять по мере необходимости.

Всё под MIT. github.com/AnastasiyaW/claude-code-config

ссылка на оригинал статьи https://habr.com/ru/articles/1022578/