# CLAUDE.md больше 200 строк в 2026: удалить и пересобрать короткий файл

> CLAUDE.md передаёт Claude постоянные правила проекта. Разберись, что положить в файл, где его искать и когда проще удалить его и собрать заново.

Источник: https://vibeceh.ru/guides/claude-md-udalit-ili-perepisat
Автор: Сергей Мазур · опубликовано 2026-08-02

Если запрос `claude md` привёл тебя к файлу с правилами для Claude Code, начни с главного: `CLAUDE.md` - обычный Markdown-файл с постоянными инструкциями. Claude читает его в начале сессии, а сам файл обычно лежит в проекте. Сначала проверь содержимое и пойми, какие правила реально помогают.

## Что такое CLAUDE.md простыми словами

`CLAUDE.md` - обычный Markdown-файл с постоянными инструкциями для Claude, который читается в начале каждой сессии. Файл передаёт контекст, который нельзя надёжно вывести из кода: команды проекта, архитектурные решения и рабочие правила. Специальный синтаксис не нужен - подойдут заголовки, списки и короткие фразы. Главное правило: каждая строка должна предотвращать конкретную ошибку Claude, а не описывать проект в целом.

Я проверял: внутри нет специального языка. Подойдут заголовки, списки и короткие фразы. Например:

```md
## Commands
Коротко: здесь указаны основные команды для установки, запуска и проверки проекта.

- Start the app: `npm run dev`
- Run tests: `npm test`

## Rules
Коротко: здесь перечислены постоянные правила работы Claude с кодовой базой.

- Read a file before editing it.
- Do not change unrelated files.
```

Вот ключевая разница между файлами:

| Файл | Для кого | Что содержит |
|---|---|---|
| README.md | Человек | Описание проекта, установка, запуск |
| CLAUDE.md | Claude | Команды, рабочие правила, частые ошибки |

Разница заметна на простом примере. В README можно написать: «Установи зависимости и запусти приложение». В `CLAUDE.md` лучше указать точные команды, если они нестандартны или их нельзя надёжно вывести из файлов проекта.

Файл может описывать проектный, личный или организационный контекст. В статье речь в основном о проектном файле рядом с кодом.

Файлы CLAUDE.md - это Markdown-файлы, которые задают Claude постоянные инструкции для проекта, личного рабочего процесса или всей организации. Ты пишешь их обычным текстом, а Claude читает их в начале каждой сессии.

## Зачем Claude Code нужен файл с правилами проекта

файл передаёт Claude то, что нельзя надёжно вывести из кода. Это память проекта: команды, локальные зависимости, соглашения, архитектурные решения и повторяющиеся ошибки. Весь этот набор попадает в [контекст](/concepts/kontekst) Claude и влияет на каждое его действие. Claude может открыть файлы и изучить кодовую базу, но решения, которые не видны из структуры, требуют явного описания в CLAUDE.md.

Claude может открыть файлы и изучить кодовую базу. Но одного кода часто недостаточно. В проекте могут быть решения, которые не видны из структуры:

- запускать проверку нужно нестандартной командой;
- конкретную папку нельзя редактировать вручную;
- бизнес-логику держат отдельно от компонентов интерфейса;
- перед изменением нужно найти уже существующую реализацию;
- определённый файл нельзя переименовывать без отдельного согласования.

`CLAUDE.md` передаёт такой контекст заранее. Это уменьшает число повторяющихся объяснений в каждой сессии.

Не путай файл с промптом для магии. Он не превращает Claude в автономного разработчика и не заставляет его безошибочно выполнить каждую строку. Файл только добавляет инструкции и контекст в рабочую сессию.

Anthropic описывает похожий сценарий так: Claude читает файлы `CLAUDE.md`, находит подходящие и разбирается в зависимостях незнакомой кодовой базы. Задача файла состоит в том, чтобы быстрее ввести Claude в правила проекта.

Я вывел простое практическое правило: добавляй строку, если без неё Claude уже ошибался или не способен понять важную особенность проекта. Правило должно появляться из конкретной потребности, а не только потому, что звучит разумно.

## Где лежит CLAUDE.md и какой файл видит Claude

Claude ищет `CLAUDE.md` по дереву папок от текущей рабочей директории вверх. Найденные инструкции объединяются, а не заменяют друг друга. Файл может лежать в корне проекта, в дочерней папке, в домашней директории пользователя или в скрытой папке `.claude`. Перед запуском проверь, что находишься в корне проекта - иначе часть инструкций не попадёт в сессию.

![Кот прикрывает морду у схемы расположения файлов CLAUDE.md по папкам.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-md-udalit-ili-perepisat/kadr-1.webp)

На практике встречаются такие уровни:

- корневой `CLAUDE.md` в папке проекта;
- `CLAUDE.md` в родительской папке;
- `CLAUDE.md` в дочерней папке;
- пользовательский файл `~/.claude/CLAUDE.md`;
- локальный `CLAUDE.local.md`;
- проектный файл `.claude/CLAUDE.md`.

Если запустить Claude из вложенной папки, он начинает поиск от неё и поднимается вверх по дереву. Инструкции из дочерних папок подгружаются по мере работы с файлами внутри этих папок.

Найденные файлы объединяются в общий контекст. Поэтому одно и то же правило в нескольких местах может запутать Claude, а противоречие между уровнями нельзя автоматически считать решённым по простому правилу приоритета.

Если текущая директория не совпадает с корнем проекта, часть инструкций может не попасть в сессию. Сначала проверь путь, затем запускай Claude Code из корня.

Для дополнительных материалов есть импорт через `@путь/к/файлу`:

```md
@README.md
@docs/testing.md
```

Импорт появился в Claude Code версии `0.2.107`. Импортированные файлы тоже могут подключать другие файлы. Документация указывает максимальную глубину в четыре перехода.

## Что положить в CLAUDE.md, а что оставить за пределами файла

клади в файл непредсказуемые команды, нестандартный стиль, тестовые инструкции, архитектурные решения и частые ловушки. Полную документацию и очевидные вещи оставляй в коде, README или отдельных файлах. Я проверяю каждую строку через простой фильтр: без неё Claude с высокой вероятностью ошибётся? Если ответ «нет» - строка не попадает в файл.

Я проверяю каждую строку через вопрос: без неё Claude с высокой вероятностью ошибётся?

Подходящее содержимое:

- команды, которые Claude не угадает;
- команда запуска проекта;
- команда тестирования и линтинга;
- нестандартные правила стиля;
- архитектурные решения;
- расположение главного кода;
- рабочие правила перед редактированием;
- частые ошибки Claude;
- запрет трогать сгенерированные файлы;
- правило остановиться и спросить при неоднозначности.

Не добавляй:

- полную API-документацию;
- длинный учебник;
- changelog;
- описание каждого файла;
- очевидные правила вроде «пиши чистый код»;
- то, что уже понятно из дерева проекта;
- длинную многошаговую процедуру;
- правило, которого команда сама не придерживается.

Например, строка «используй существующие зависимости» может быть полезна, если Claude уже добавлял новые пакеты без причины. А строка «соблюдай качество кода» слишком общая: по ней нельзя проверить конкретный результат.

Хорошее правило описывает действие:

```md
- Read the file before editing it.
- Search for existing functionality before writing new code.
- Run the smallest relevant test after changes.
- Ask before deleting or significantly restructuring existing code.
```

Плохое правило оставляет всё на усмотрение модели:

```md
- Always write perfect code.
- Follow best practices.
- Make the project maintainable.
```

Официальная документация предлагает добавлять команды Bash, стиль кода и рабочие правила. Подробную документацию API она рекомендует держать за пределами файла.

Команды Bash, которые Claude не может угадать.

Если материал длинный, вынеси его в отдельный Markdown-файл и подключи через `@`. Не превращай `CLAUDE.md` в оглавление всей кодовой базы.

## Когда правило держать в CLAUDE.md, а когда вынести в skills

постоянные правила держи в `CLAUDE.md`, а знания, справочные материалы и многошаговые процессы выноси в skills. Skills работают как сценарии ИИ-агента: они запускаются только по запросу и не висят в контексте каждой сессии. Разделение простое: правило для любой задачи идёт в CLAUDE.md, редкий сценарий - в skill. Разделение простое: если правило относится к любой работе в проекте, ему место в CLAUDE.md; если сценарий нужен раз в неделю - выноси в skill, чтобы не загружать контекст каждой сессии.

`CLAUDE.md` загружается в каждую сессию. Поэтому он подходит для короткого постоянного контекста:

- где лежит основной код;
- какой командой запускать проект;
- какую проверку выполнять после изменения;
- какие папки нельзя менять;
- какое архитектурное решение нельзя нарушать.

Skills нужны для сценариев, которые происходят не всегда. Например, для отдельного процесса, состоящего из нескольких действий, или для справочного материала, который не нужен при каждой задаче.

Разделение можно проверить так:

1. Правило относится к любой работе в проекте. Оставь его в `CLAUDE.md`.
2. Процесс запускается только по конкретному запросу. Вынеси его в skill.
3. Материал длинный и нужен редко. Вынеси его в skill или отдельный файл.
4. Процесс требует нескольких последовательных действий. Подходит skill.
5. После добавления текста каждая сессия стала перегруженной. Убери редкий сценарий из `CLAUDE.md`.

Документация разделяет эти роли прямо: `CLAUDE.md` добавляет постоянный контекст, а skills дают повторно используемые знания и вызываемые рабочие процессы.

Подробную процедуру не стоит класть в `CLAUDE.md` только ради того, чтобы Claude «всегда её помнил». Если процедура нужна для одной задачи, постоянная загрузка будет занимать место и смешивать контекст.

## Удалить старый CLAUDE.md или переписать его с нуля

если `CLAUDE.md` разросся до тысяч токенов, удали его и собери заново. Верни только инструкции, которые нужны после реальных ошибок Claude. Не храни в файле ответы на каждую старую ошибку, дублирующиеся формулировки и правила, потерявшие актуальность. Я через это проходил: в старом файле оседают запреты без проверки, длинные объяснения и инструкции, относящиеся только к одной папке.

Создатель Claude Code Борис Черни описывает рабочий цикл своей команды: общий файл хранится в Git, а команда дополняет его несколько раз в неделю. Ошибка Claude превращается в короткое правило. Такой файл не служит архивом всех мыслей о проекте.

Борис Черни рекомендует при разрастании файла до тысяч токенов удалить его, начать заново и вернуть только инструкции, которые нужны, когда модель сбивается с пути (пересказ, оригинал на английском). Источник: [Inside Claude Code with its creator Boris Cherny](https://ulisten.ai/channels/y-combinator/inside-claude-code-with-its-creator-boris-cherny_PQU9o_5rHC4/faq).

Есть два разных действия:

| Действие | Что происходит | Когда применять |
|---|---|---|
| Переписать | Отредактировать существующий текст | Файл в целом адекватен, но есть устаревшие строки |
| Пересобрать | Удалить старый набор и написать короткую версию на основе проверенных ошибок | Файл раздут, содержит дубли, устаревшие и бесполезные правила |

Пересборка нужна, когда файл превратился в свод правил на все случаи жизни. В моей практике в такой файл постепенно попадают:

- ответы на каждую старую ошибку;
- дублирующиеся формулировки;
- длинные объяснения;
- правила, которые больше не нужны;
- запреты без технической проверки;
- инструкции, относящиеся только к одной папке или задаче.

Перед удалением сохрани старую версию в истории Git. Затем создай короткий файл и проверь его на небольшой задаче. Не возвращай строку просто потому, что она была в старой версии.

Общий ориентир для короткого файла - до 200 строк. В рекомендациях Бориса Черни фигурирует размер примерно до 2 000 токенов: Токен, единица измерения контекста, накапливается быстро, и каждая лишняя строка отнимает место у полезных инструкций. Это не закон и не гарантия качества. Смысл в другом: каждая строка должна оправдывать постоянное присутствие в контексте.

## Как проверить, что Claude действительно видит CLAUDE.md

запускай Claude Code из корня проекта и проверяй `/context`. Ищи `CLAUDE.md` среди `Memory files`, а не верь одной фразе модели о том, что файл прочитан. Модель может сказать «я прочитал файл», но `/context` покажет правду. Я проверяю загрузку файла перед каждой важной задачей - это занимает меньше минуты и спасает от работы вслепую.

Порядок проверки:

1. Открой терминал.
2. Перейди в корневую папку проекта.
3. Запусти Claude Code из этой папки.
4. Выполни команду `/context`.
5. Найди в выводе раздел `Memory files`.
6. Проверь, что там указан нужный `CLAUDE.md`.
7. Если файла нет, проверь имя, путь и текущую папку.

Команда для перехода зависит от расположения проекта:

```bash
cd path/to/project
claude
```

Внутри Claude Code введи:

```text
/context
```

Проверка через `/context` важнее ответа «я прочитал файл» (подробнее о том, [как Claude Code теряет контекст](/guides/kontekst-v-claude-code-zabyvaet-proekt) и [чем отличается от Cursor](/guides/claude-code-ili-cursor)). Модель может неверно описать состояние контекста. `/context` показывает, какие memory-файлы Claude Code загрузил в сессию.

Если файл найден, это ещё не означает, что каждое правило будет выполнено. Проверка отвечает только на вопрос «файл загружен или нет». Поведение нужно проверять отдельной небольшой задачей.

## Как сделать CLAUDE.md для проекта: от пустого файла до первой проверки

создай файл в корне проекта, запиши реальные команды и стабильные правила, затем проверь загрузку через `/context` и выполни небольшую задачу. Не начинай с большой переделки - сначала измени один понятный элемент и убедись, что Claude следует правилам. Я добавляю новую строку в CLAUDE.md только после того, как Claude ошибся конкретным образом, и правило предотвращает именно эту ошибку.

![Сиба-ину одобряет три шага создания и проверки файла CLAUDE.md.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-md-udalit-ili-perepisat/kadr-2.webp)

Перейди в папку, из которой обычно запускаешь Claude Code. Проверь, что рядом лежит код проекта и файлы зависимостей.

Имя должно быть именно `CLAUDE.md`. Не добавляй второе расширение вроде `.txt`.

```bash
touch CLAUDE.md
```

Укажи команды запуска, тестирования, линтинга и сборки только после проверки, что они действительно работают в этом проекте.

```md
## Commands
Коротко: здесь указаны проверенные команды для установки, запуска, тестирования, линтинга и сборки проекта.

- Install: `npm install`
- Run locally: `npm run dev`
- Test: `npm test`
- Lint: `npm run lint`
- Build: `npm run build`
```

Запиши расположение основного кода, порядок перед редактированием и границы изменений. Не добавляй общие пожелания без конкретного действия.

Это нужно для корректного поиска файлов по дереву папок.

```bash
cd path/to/project
claude
```

Внутри сессии введи команду и найди `CLAUDE.md` среди `Memory files`.

```text
/context
```

Не начинай с большой переделки. Попроси изменить один понятный элемент и проверить результат.

```prompt Проверка рабочего правила
Найди существующий код, связанный с главной страницей. Сначала прочитай файл, который собираешься менять. Измени только текст кнопки. После изменения выполни подходящую проверку и сообщи, какие файлы изменены.
```

Посмотри изменённый файл и результат работы приложения. Убедись, что Claude не изменил несвязанные файлы.

Если Claude сделал конкретную нежелательную вещь, запиши короткое правило, которое предотвращает именно её. Не добавляй пять новых запретов «на всякий случай».

Снова запусти задачу с тем же типом изменения и посмотри, помогло ли правило.

Для подключения отдельного файла используй импорт:

```md
@docs/testing.md
```

Так можно не перегружать основной файл длинным, но нужным материалом. Импортируй только то, что действительно нужно рабочему процессу.

Большой файл не заменяет проверку результата. Сначала запиши несколько фактов о проекте, выполни маленькую задачу, найди ошибку и только потом уточняй правила.

## Пример короткого CLAUDE.md для первого проекта

начни с команд, расположения кода, порядка редактирования, границ изменений и проверки результата. Остальные строки добавляй после конкретных ошибок. В моём шаблоне ниже всего 17 строк - этого хватает для первой итерации. Длинные инструкции для редких процессов держи за пределами файла, чтобы не раздувать контекст.

Ниже - мой claude md examples: заготовка на 17 строк. Команды показаны для проекта с npm. Замени их на реальные команды своего проекта.

```md Проектный шаблон CLAUDE.md
# Project instructions

## What this is
Коротко: это небольшое веб-приложение с основным кодом в `src/` и тестами в `tests/`.

- This is a small web application.
- Main code lives in `src/`.
- Tests live in `tests/`.

## Commands
Коротко: эти команды устанавливают зависимости, запускают, проверяют и собирают проект.

- Install: `npm install`
- Run locally: `npm run dev`
- Test: `npm test`
- Lint: `npm run lint`
- Build: `npm run build`

## Rules
Коротко: эти правила требуют искать существующий код, читать файлы перед изменением и проверять результат.

- Search for existing code before writing new code.
- Read a file before editing it.
- Do not change unrelated files.
- Ask before making an ambiguous choice.
- Check the result after every change.
```

Что здесь нужно заменить:

- описание проекта;
- `src/`, если основной код лежит в другой папке;
- `tests/`, если тесты лежат иначе;
- команды npm на команды своего проекта;
- формулировки правил под реальные ошибки.

Строка «Search for existing code before writing new code» нужна, чтобы Claude не создавал вторую реализацию той же функции. Строка «Read a file before editing it» задаёт порядок работы. Запрет несвязанных изменений ограничивает масштаб задачи. Вопрос при неоднозначности не даёт молча додумывать требования.

Не добавляй в этот шаблон полную структуру проекта, описание каждого компонента и длинные инструкции для редких процессов. Для них подойдут README, отдельные rules-файлы или skills.

## Почему Claude нарушает правило, даже если оно написано в файле

`CLAUDE.md` содержит advisory-инструкции, а не технические запреты. Короткий файл помогает задать направление, но не гарантирует выполнение каждой строки. Я убедился на практике: текстовое правило «не коммить ключи» не остановит модель. Для реальной защиты нужны permissions в settings.json и автоматические проверки - линтер, тесты или hook.

Показательный пример описан в проверке компактного `CLAUDE.md` со skills и preflight-проверками. Скрипт нашёл 104 нарушения уже записанных правил:

- хардкод вместо enum;
- дублирующиеся helper-функции;
- логика в контроллерах вместо сервисов.

Проверка заняла меньше секунды и не имела зависимостей.

Она нашла 104 нарушения. Каждое из них нарушало правило, которое уже было записано простым английским языком в моём CLAUDE.md.

Из этого следует граница файла:

1. Инструкция подсказывает модели, как работать.
2. Модель может решить, что правило не относится к текущей задаче.
3. Модель может неверно применить правило.
4. Техническая проверка видит результат, а не намерение.
5. Линтер, тест или hook способен остановить процесс или показать ошибку.

Короткий `CLAUDE.md` не гарантирует TDD. Он не гарантирует, что Claude не сделает commit. Он не гарантирует отсутствие секретов в изменениях. Он не гарантирует архитектурную дисциплину.

Поэтому правило «после изменения запусти тесты» полезно как напоминание. Для обязательного запуска нужна автоматическая проверка. Если нужно дать Claude доступ к внешним инструментам, разберись с [MCP-сервером](/guides/mcp-podklyuchit-pervyj-instrument) - он связывает Claude Code с файлами, базами и сервисами. Правило «не коммить ключи» полезно как подсказка. Для защиты нужны permissions и проверка секретов.

## Что делать с секретами, опасными командами и обязательными проверками

контекст и рекомендации оставь в `CLAUDE.md`, запреты доступа настрой в `.claude/settings.json`, а обязательные действия оформи hooks. Текстовый запрет в Markdown не остановит модель: для реальной защиты нужны permissions и автоматические проверки, а не строчка в файле. CLAUDE.md отвечает на вопрос «как работать», settings.json - на вопрос «что нельзя», а hooks - на вопрос «что запускать при каждом изменении». CLAUDE.md отвечает на вопрос «как работать», settings.json - на вопрос «что нельзя», а hooks - на вопрос «что запускать при каждом изменении».

![Мужчина с ладонью на лице смотрит на настройки защиты секретов и красные кресты.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-md-udalit-ili-perepisat/kadr-3.webp)

Разделяй задачи по механизму:

- объяснить Claude команды и правила проекта - `CLAUDE.md`;
- запретить чтение `.env` и `secrets/**` - `permissions.deny` в `.claude/settings.json`;
- настроить permissions, переменные окружения, плагины и поведение инструментов - `settings.json`;
- запускать действие каждый раз - hook в `.claude/settings.json`;
- описать редкий рабочий процесс - skill.

Пример запрета доступа оформляется настройками, текстом в Markdown его не заменить:

```json
{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(secrets/**)"
    ]
  }
}
```

Не считай этот фрагмент готовой конфигурацией для любого проекта. Проверь синтаксис и действующие правила Claude Code для своей версии.

Проблема текстового запрета подтверждена issue Claude Code: автор описал случай, когда правило не коммитить API-ключи было в `CLAUDE.md`, но реальные credentials всё равно попали в конфигурационные файлы и публичный репозиторий. GitGuardian обнаружил три секрета. Ключи пришлось отозвать и выпустить заново.

Ассистент Claude Code систематически не соблюдает явные инструкции по безопасности в файлах CLAUDE.md.

`CLAUDE.md` можно оставить с пояснением:

```md
## Safety
Коротко: эти правила напоминают не читать и не коммитить секреты, а также спрашивать перед изменением схемы базы данных.

- Never read `.env` files.
- Never commit secrets.
- Ask before changing database schema.
```

Но эти строки не должны быть единственной защитой. Для доступа используй settings. Для действий, которые должны происходить всегда, используй hooks. Для проверки кода используй тесты, линтер или другую автоматическую проверку.

## Чем CLAUDE.md отличается от README.md, AGENTS.md и rules

README объясняет проект человеку, `CLAUDE.md` задаёт Claude команды и правила, `AGENTS.md` подходит для общих инструкций нескольких AI-инструментов, а `.claude/rules/*.md` хранит правила для отдельных путей. Если используешь только Claude Code, одного CLAUDE.md достаточно. Не дублируй README внутрь CLAUDE.md - при необходимости подключи его ссылкой через `@README.md`.

| Задача | Файл или механизм |
|---|---|
| Объяснить человеку назначение проекта и запуск | `README.md` |
| Передать Claude команды, ограничения и рабочие правила | `CLAUDE.md` |
| Дать общие правила нескольким AI-инструментам | `AGENTS.md` |
| Ограничить правило конкретной папкой или путём | `.claude/rules/*.md` |
| Запретить чтение `.env` и secrets | `.claude/settings.json` |
| Запускать проверку после каждого изменения | hook в `.claude/settings.json` |

`README.md` обычно содержит установку, запуск и обзор проекта. Весь README в `CLAUDE.md` дублировать не нужно. При необходимости подключи его ссылкой:

```md
@README.md
```

`AGENTS.md` используют как общий источник для нескольких инструментов. Если в проекте работают Claude Code и Codex, общие правила можно держать в `AGENTS.md`, а Claude-специфичные дополнения оставить в `CLAUDE.md`.

Если используется только Claude Code, одного `CLAUDE.md` достаточно как прямого файла инструкций для этого инструмента.

`.claude/rules/*.md` подходит для path-scoped правил. Например, правило может относиться только к `src/api/**`, а не ко всему проекту. Точное сравнение старого `.clauderules` с современными rules здесь не приводится: в фактуре нет актуального подтверждённого источника для такого сравнения.

## Короткие ответы на вопросы о CLAUDE.md

`CLAUDE.md` - Markdown-файл с постоянным контекстом и рабочими правилами для Claude Code. Создай его в корне проекта, проверь через `/context` и держи коротким. Каждая строка должна предотвращать конкретную ошибку Claude, а не описывать проект в целом. Длинные процедуры и редкие сценарии выноси в skills или отдельные файлы.

## Вопросы и ответы

ответы ниже объясняют, что означает `CLAUDE.md`, где его найти, как создать и чем дополнить. Я собрал частые вопросы, которые появляются после первых экспериментов с файлом: от базового «что это» до связки со skills и настройки под конкретный проект вроде Telegram-бота.

Это обычный Markdown-файл с постоянными инструкциями для Claude. Claude Code читает его в начале сессии и использует как контекст проекта.

Ищи файл в корне репозитория, в папке `.claude` или в одной из родительских и дочерних папок проекта. Claude Code ищет такие файлы по дереву директорий от текущей рабочей папки.

Открой корень проекта и создай файл с точным именем `CLAUDE.md`. Запиши реальные команды и стабильные правила, затем запусти Claude Code из этой папки и проверь загрузку через `/context`.

Claude md management сводится к простому правилу: добавляй строку после конкретной ошибки Claude или при наличии важного правила, которое нельзя надёжно вывести из кода. Удаляй дубли и всё, что стало очевидно из проекта.

Постоянный контекст оставь в `CLAUDE.md`. Редкие сценарии, справочные материалы и многошаговые рабочие процессы вынеси в skills.

Файл `CLAUDE.md` обычно лежит в корне проекта рядом с основными файлами репозитория и веткой `main`. Для общих инструкций нескольких AI-инструментов используй `AGENTS.md`.

Настрой его через короткие разделы с командами, расположением кода, правилами редактирования и проверкой результата. Запреты доступа и hooks настраиваются через `.claude/settings.json`, без текстовых формулировок в Markdown.

В `CLAUDE.md` можно указать постоянные правила поведения и сказать Claude, где искать нужный skill. Сам редкий многошаговый процесс лучше хранить в skill, чтобы не загружать его целиком в каждую сессию.

Сначала определи реальные команды, структуру и проверки конкретного Telegram-бота. В фактуре нет подтверждённого примера со стеком, командами и правилами именно для Telegram-бота, поэтому универсальный шаблон без этих данных будет выдумкой.

Можно создать отдельный файл на уровне папки бота, если Claude работает с этой папкой и должен получить её локальные инструкции. Команды, расположение кода и правила нужно взять из реального проекта, а не копировать из общего шаблона.

- [How Claude remembers your project](https://code.claude.com/docs/en/memory)
- [Best practices for Claude Code](https://code.claude.com/docs/en/best-practices)
- [How Anthropic teams use Claude Code](https://www.anthropic.com/news/how-anthropic-teams-use-claude-code?trk=article-ssr-frontend-pulse_little-text-block)
- [Inside Claude Code with its creator Boris Cherny](https://ulisten.ai/channels/y-combinator/inside-claude-code-with-its-creator-boris-cherny_PQU9o_5rHC4/faq)
- [Boris Cherny on X](https://x.com/bcherny/status/2007179861115511237)
- [Why Claude Code Ignores CLAUDE.md](https://launchwithben.com/learn/claude-code/why-claude-code-ignores-claude-md)
- [Claude Code issue #2142](https://github.com/anthropics/claude-code/issues/2142)
- [Give Claude context: CLAUDE.md and better prompts](https://support.claude.com/en/articles/14553240-give-claude-context-claude-md-and-better-prompts)
- [Extend Claude Code](https://code.claude.com/docs/en/features-overview)
- [Claude Code settings](https://code.claude.com/docs/en/settings)
- [Claude Code Changelog](https://code.claude.com/docs/en/changelog)
- [Andrew's CLAUDE.md](https://gist.github.com/andrewedunn/0c4e6ee4a4b2e8a1955238a9540e4eb9)
- [0x6a68/claude.md](https://gist.github.com/0x6a68/0e7811c1ec8a7f3613acfb29c71e7e7b)
- [AGENTS.md vs CLAUDE.md](https://blink.new/blog/agents-md-vs-claude-md)