Как настроить CLAUDE.md в 2026 году: шаблон и 6 правил

Читайте материалы о вайб-кодинге, инструментах, практических примерах и ошибках в руководствах Ailoot.

Для чего нужен CLAUDE.md и почему Claude не помнит проект?#

Во вторник открываешь Claude Code и рассказываешь: «Я веду такой-то проект, использую такие инструменты, вот чего делать не нужно». Это помогает в текущей работе.

В четверг сессия уже завершена, и объяснение приходится повторять. В субботу — снова, а затем ещё раз в понедельник.

Без CLAUDE.md каждое новое окно похоже на первый рабочий день стажёра: приходится заново сообщать одни и те же сведения. На такое вступление у меня уходило по 5–10 минут в каждой сессии. Запросы разрастались, потому что контекст нужно было добавлять вручную, а ответы всё равно оставались слишком общими: агент не знал мою аудиторию, экономику и принципы работы.

Если поддерживать CLAUDE.md в актуальном состоянии, не приходится каждый раз заново перечислять правила: файл добавляется к контексту сессии. Вместо длинного вступления достаточно попросить выполнить задачу — например, «сделай X».

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

Так постепенно формируется набор правил проекта, который помогает не повторять знакомые ошибки.

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

Что такое CLAUDE.md и как Claude Code загружает такие файлы?#

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

Уровни расположения файлов, от общих к относящимся к конкретному проекту:

Если инструкции из разных файлов противоречат друг другу, результат может быть непредсказуемым. Поэтому критически важные правила лучше собрать в проектном CLAUDE.md и не дублировать без необходимости.

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

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

Как за пять минут подготовить CLAUDE.md по шаблону?#

Ниже — структура для адаптации к проекту. Оставляйте полезные инструкции и стремитесь к рекомендованному Anthropic объёму менее 200 строк. Это рекомендация компактности, а не технический предел.

# [НАЗВАНИЕ ПРОЕКТА] - навигация по проекту

Этот документ - карта проекта. Читай его в начале каждой сессии,
чтобы понимать, где что лежит и как с этим работать.

## Что это за проект

**[НАЗВАНИЕ]** - [одно предложение: что это и для кого].
[1-2 предложения: какую задачу решает, как именно].

Подробности - в `business/INDEX.md`.

## Порядок чтения в начале любой сессии

1. `about-me/INDEX.md` - кто я и как думаю
2. `business/INDEX.md` - что мы делаем (продукт, аудитория, экономика)
3. `CLAUDE.md` (этот файл) - правила репо, инструменты, навигация
4. Зона задачи: нужный файл из `business/`, `plans/<актуальный план>`,
   `mastery/<область>` или папка фичи в коде

Принцип: слой 1 (about me) - раньше слоя 2 (бизнес) не случайно.
Сначала **кто** думает, потом **о чём**.

## Структура репозитория

[НАЗВАНИЕ]/
├── CLAUDE.md            ← этот файл, навигация
├── about-me/            ← цифровая проекция тебя (как думаешь, что ценишь)
│   └── INDEX.md
├── business/            ← второй мозг бизнеса
│   ├── INDEX.md
│   ├── audience/        ← портрет клиента
│   ├── products/        ← продукты, цены
│   ├── goals/           ← цели, метрики
│   └── economics/       ← unit-экономика, выручка
├── plans/               ← технические планы (один план = одна функция)
├── retrospectives/      ← рефлексии после каждой сессии
└── (код проекта)

### Где что искать

| Что нужно | Куда смотреть |
|---|---|
| Зачем делаем проект, для кого | `business/INDEX.md` |
| Целевой клиент, боли, желания | `business/audience/` |
| Продукт, тарифы, цены | `business/products/` |
| Цели и метрики | `business/goals/` |
| Экономика | `business/economics/` |
| Технические планы | `plans/` |

## Инструменты

[ВСТАВЬ ИНСТРУМЕНТЫ - например: Next.js 14, TypeScript, Tailwind CSS, Prisma + PostgreSQL].

## Правила репо

1. Никогда не хардкодить динамические данные (цены, даты, цифры) -
   всё через файлы `business/` и маркер LIVE.
2. Не публиковать без явной команды от меня.
3. Перед `git push` - запускать `npm run build` и проверять, что
   собирается без ошибок и предупреждений.
4. `git add` поимённо. Никогда `git add .` или `git add -A`.
5. `.env` не читать целиком. Для проверки переменной -
   `grep "^VAR=" .env`.

## Большая фича = план в `plans/`

Любая задача дольше часа оформляется планом в папке `plans/`:
1. Имя файла: `YYYY-MM-DD-название-функции.md`.
2. План делится на фазы. У каждой фазы статус `[ ]` или `[x]`.
3. В конце плана - итог: реализован целиком или нет, что осталось.

## Цикл в конце каждой фичи

После завершения каждой фичи прогони 5 ходов:
1. Найди ошибки → докажи примером → исправь.
2. Что упустили (граничные случаи, проверка входных данных, обработка ошибок).
3. Это реальная проблема нашего проекта? Сверь с `business/` и `plans/`.
4. Свежий взгляд - перечитай diff, как будто видишь впервые.
5. Security review. Особенно: персональные данные + материалы третьих лиц.

## Рефлексия в конце сессии

В `retrospectives/YYYY-MM-DD_краткое-название.md` запиши:
1. Какая задача была.
2. Как решали.
3. Решили - да / нет / частично.
4. Что можно было лучше.
5. Что узнал нового о пользователе или проекте.

## Язык

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

Чтобы Claude адаптировал шаблон, попросите его прочитать контекст проекта и заполнить пропуски:

Создай в корне проекта файл CLAUDE.md по этому шаблону:

[ВСТАВЬ ШАБЛОН ЦЕЛИКОМ ИЗ ТЕКСТА ВЫШЕ]

Действуй так:

Прочитай about-me/INDEX.md и business/INDEX.md, чтобы понять контекст проекта и меня как автора.

Заполни в шаблоне все поля в квадратных скобках на основе того, что найдёшь в этих папках.

Если каких-то данных не хватает - задай мне уточняющие вопросы по одному, с 3-4 вариантами ответа.

Стремись оставить CLAUDE.md короче 200 строк. Если больше, убери повторы и вынеси подробные процедуры в связанные файлы. Сохрани необходимые правила планирования, рефлексии и репозитория, затем проверь их на характерных задачах.

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

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

Если папок about-me/ и business/ пока нет, Claude может задать уточняющие вопросы и подготовить начальную версию файла на основе доступных сведений. Добавить папки можно позже.

Какие шесть правил помогут поддерживать CLAUDE.md в рабочем состоянии?#

Правило 1. Старайтесь уложиться в 200 строк

Документация рекомендует стремиться к объёму менее 200 строк для экономии контекста и лучшего соблюдения правил. Она не устанавливает резкую границу отказа на строке 201. Перед переносом материалов проверьте актуальность, противоречия, загружаемые токены и результат настоящих задач.

Большой CLAUDE.md расходует контекст каждой сессии. Например, файл на 800 строк добавляет множество инструкций при каждом запуске. Кроме того, среди большого количества правил модели сложнее выделять важные.

После достижения рекомендованного объёма Anthropic советует пересмотреть файл и вынести подробности в отдельные документы.

Правило 2. Завершайте сессию краткой записью

В CLAUDE.md можно попросить подводить итоги каждой сессии и сохранять их, например, в retrospectives/YYYY-MM-DD_*.md. Тогда по записям проще восстановить ход работы и принятые решения.

Такая практика помогает:

• Через две недели вспомнить, почему выбрали конкретный подход.
• При возвращении к проекту через месяц быстро увидеть недавние решения.
• Передать коллеге краткое описание текущего состояния без отдельного созвона.

Правило 3. Фиксируйте завершённые задачи коммитами

Если это соответствует процессу проекта, задайте правило создавать git-коммит после завершения задачи и давать ему понятное сообщение. Так изменения удобно разделять и находить в истории.

При проблеме можно вернуться к предыдущему состоянию, а журнал коммитов покажет, что и в каком порядке менялось.

Правило 4. Указывайте, где находится контекст бизнеса

Для задач о клиентах, продуктах и текстах задайте порядок чтения: сначала business/INDEX.md, затем нужный документ. Например, для интерфейса или публикаций может пригодиться business/audience/avatar.md и business/assets/brand-guidelines.md.

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

Правило 5. Добавляйте правило после обнаруженной ошибки

Если агент допустил ошибку, проверьте, поможет ли конкретная инструкция избежать её повторения. При необходимости внесите короткое и однозначное правило в CLAUDE.md.

Примеры возможных инструкций:

• «Не включай чужие незавершённые файлы в коммит через git add .; добавляй файлы по именам».
• «Перед отправкой в main проверь git log origin/main..main --oneline; при наличии коммитов не отправляй изменения».
• «Не придумывай значения: проверяй их в .env или коде. Не выдумывай URL, имена пользователей и токены».

Содержание правила должно соответствовать реальному процессу и причине ошибки, которую оно предотвращает.

Правило 6. Настраивайте ограничения безопасности отдельно

Текст в CLAUDE.md сообщает агенту, как следует работать, но сам по себе не блокирует команду. Для ограничений используйте подходящие настройки и механизмы Claude Code, например .claude/settings.json, если требуемое ограничение поддерживается этой конфигурацией.

Примеры команд и действий, которые команда проекта может ограничить:

• rm -rf (рекурсивное удаление файлов).
• Чтение файла .env целиком.
• Совместный запуск export и curl в одной команде.
• git push --force без явного согласования.

Для дополнительных материалов о Claude Code и других инструментах загляните в руководства Ailoot.

Из каких частей состоит CLAUDE.md в действующем проекте?#

Многие общедоступные примеры CLAUDE.md посвящены разработке: настройкам TypeScript, тестам и другим техническим правилам. Для бизнеса может потребоваться также описать аудиторию, продукты и рабочие процессы.

Вот примерный каркас такого файла. Конкретные инструкции необходимо подстроить под свой проект.

1. Краткое описание проекта (15 строк). Что делает проект, кто его аудитория и какие продукты он предлагает. Это краткая справка для агента, а не рекламное описание.

2. О себе (10 строк). Ссылка на about-me/, где можно описать стиль, ценности, принципы и нежелательные формулировки. Если Claude готовит текст от имени автора, эти сведения помогут учесть нужную тональность.

3. Структура репозитория (20 строк). Дерево папок с пояснениями: где находятся код, контекст бизнеса, планы и заметки о сессиях. Такая схема упрощает поиск нужных материалов.

4. Таблица «Где что искать» (25 строк). Подсказки по схеме «вопрос → файл». Например: «нужны условия ипотеки → business/products/mortgage.md» или «нужен стиль публикаций → business/assets/voice.md». Замените примеры реальными путями проекта.

5. Основные принципы проекта (40 строк, 10–15 пунктов). В этот раздел можно заносить конкретные требования, которые предотвращают ошибки. Например, интернет-магазину может быть полезно запретить задавать цены и сроки доставки вручную, публиковать товар без команды или игнорировать бренд-словарь.

6. Операционное планирование (20 строк). Опишите, какие действия связаны с конкретными запросами. Например, на фразу «план на неделю» можно указать открыть ops/monthly.md и подготовить файл плана.

7. Инструменты (5 строк). Краткий перечень используемых технологий.

8. Публикация (15 строк). Порядок подготовки и выпуска изменений: команды, очередность и необходимые проверки.

9–12. Безопасность (35 строк). Несколько подразделов о работе с .env, доступе к производственной базе, демонстрационных материалах и смене секретов.

13. Папка plans/ (10 строк). Требования к именам и структуре планов, а также к итоговому разделу.

14. Папка retrospectives/ (5 строк). Шаблон заметки об итогах сессии, её имя и обязательное содержание.

15. Актуальные данные из базы (15 строк). Укажите, когда нужно обращаться к источнику за свежими значениями, а не полагаться на старую запись.

16. Язык (3 строки). Например: «Отвечай на языке, предпочитаемом пользователем. Используй дефис вместо длинного тире».

В примере около 280 строк. Это выше ориентира компактности, но не делает файл недействительным. Решение сохранить его зависит от измеренного расхода контекста и проверок характерных задач. Таблицы не обязательно дешевле прозы по токенам.

Что делает команда /init и чего от неё ждать не стоит?#

По документации Anthropic, команда /init анализирует кодовую базу и формирует стартовый файл с командами сборки и тестирования, а также обнаруженными соглашениями проекта.

Команда может:

• Определять инструменты по package.json, Cargo.toml и pyproject.toml.
• Добавлять команды сборки и запуска тестов.
• Учитывать настройки из имеющихся файлов, например .eslintrc и .prettierrc.
• Замечать правила Cursor (.cursorrules, .cursor/rules/) и Copilot; AGENTS.md считывается в режиме CLAUDE_CODE_NEW_INIT=1.

Но /init не определит самостоятельно:

• Кто является клиентом проекта.
• Какие слова нельзя использовать в текстах.
• Какие инструкции понадобятся после ещё не встречавшихся ошибок.
• Где искать бизнес-контекст в структуре конкретного проекта.

Практический порядок действий:

1. Запустите /init в Claude Code

   Получите начальную версию CLAUDE.md с техническими сведениями и командами проекта.

2. Дополните её шаблоном из этой статьи

   Возьмите раздел «Минимальный CLAUDE.md за пять минут» и добавьте подходящие инструкции о навигации, правилах и бизнес-контексте.

3. Заполните пропуски

   Попросите Claude изучить проект и заполнить поля шаблона. Если папок business/ и about-me/ нет, он может задать уточняющие вопросы.

4. Проведите проверку на неоднозначность

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

5. Обновляйте файл по ходу работы

   При необходимости добавляйте инструкции после выявленных ошибок. Через некоторое время CLAUDE.md будет учитывать особенности проекта.

Для четвёртого шага можно использовать такой запрос:

У меня есть CLAUDE.md. Завтра я буду собирать по нему фичу.

Твоя задача - стресс-тест. Найди 10 причин, из-за которых мы потенциально облажаемся:

где в CLAUDE.md двусмысленности, которые ты как агент можешь понять неправильно

где есть пробелы, из-за которых решения придётся выдумывать

где правила противоречат сами себе

где я переоцениваю объём одного дня

где недооцениваю (это даже хуже)

Не стесняйся. Критикуй жёстко. Я хочу найти эти причины сейчас, а не в проде.
В конце дай список конкретных правок: что и как поменять, чтобы этих причин не было.

CLAUDE.md, AGENTS.md и MEMORY.md: в чём разница в 2026 году?#

Важный вопрос — читает ли Claude Code файл AGENTS.md. Согласно статье, начиная с версии 2.1.277, выпущенной 18 сентября 2026 года, Claude Code может читать его напрямую, если в рабочей папке и выше нет CLAUDE.md, .claude/CLAUDE.md или CLAUDE.local.md.

Anthropic указывает, что Claude Code умеет использовать AGENTS.md как инструкции проекта. Поэтому репозитории, подготовленные для других агентов, могут работать без отдельного CLAUDE.md, импорта или дополнительной настройки — при соблюдении условий документации.

Если в проекте есть CLAUDE.md, поведение зависит от настроек. В /config, в параметре Project instructions, можно выбрать вариант claude-md-and-agents-md, чтобы читать оба файла. Другой вариант — добавить импорт в CLAUDE.md:

@AGENTS.md

## Claude Code

Дополнительные правила для Claude Code, которые не нужны другим агентам.

Запись @filename импортирует другой файл, чтобы Claude загрузил его содержимое вместе с CLAUDE.md. Сверьте поведение с документацией для используемой версии.

Когда полезен AGENTS.md. Если один проект используется с несколькими агентами, можно вести общие инструкции в AGENTS.md, а в CLAUDE.md импортировать его и добавить особенности Claude Code. Если отдельные правила Claude не нужны и версия поддерживает чтение AGENTS.md, возможно, достаточно этого файла. Если используется только Claude Code, можно ограничиться CLAUDE.md. Подробности приведены в руководстве о совместном использовании AGENTS.md и CLAUDE.md.

Что такое MEMORY.md. Claude Code может сохранять заметки о повторяющихся предпочтениях и рабочем контексте в ~/.claude/projects/<имя-проекта>/memory/MEMORY.md.

Это отдельный механизм, не замена CLAUDE.md. Если заметка должна стать постоянной инструкцией, перенесите её в подходящий файл правил. Ошибочные или ненужные заметки можно исправить либо удалить.

Какой объём CLAUDE.md выбрать и чем опасен слишком длинный файл?#

В контекст сессии могут входить системные инструкции Anthropic, CLAUDE.md, импортированные через @ файлы, MEMORY.md, история чата и содержимое открываемых файлов. Всё это использует доступное окно контекста модели: в статье указаны 200K токенов у Sonnet и 1M у Opus.

Чем больше постоянных инструкций, тем меньше места остаётся для материалов текущей задачи. Файл на 1000 строк может занимать значительный объём контекста при каждой загрузке.

Большое количество правил также затрудняет выбор приоритетов. Anthropic предупреждает, что раздутые CLAUDE.md могут мешать Claude следовать важным инструкциям.

Рекомендация по объёму:

• 80–120 строк — удобный начальный диапазон краткой карты проекта, а не гарантия процента соблюдения.
• 150–200 строк — повод проверить актуальность и вынести подробные процедуры в связанные файлы.
• 200–300 строк — изучите токены, повторы и результаты задач: пример на 280 строк выше может оставаться полезным.
• 400 строк и больше — серьёзный повод для пересмотра, но не доказательство непригодности. Сохраняйте ключевые ограничения, а после переноса проверяйте ссылки и правила.

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

В рекомендациях Anthropic предлагается проверять каждую строку вопросом: «Начнёт ли Claude ошибаться, если убрать это правило?» Если инструкция ничего не меняет, её можно удалить.

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

Какие семь ошибок превращают CLAUDE.md в бесполезный файл?#

Ошибка 1. «Будь хорошим инженером»

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

Такие формулировки не дают проверяемого критерия и занимают место. Замените их конкретными требованиями: например, «используй два пробела для отступов», «не применяй any в TypeScript» или «ограничивай длину функций 30 строками».

Ошибка 2. Повторение того, что Claude уже знает

Необязательно объяснять общие свойства JavaScript и TypeScript или описывать основы npm, git и Docker, если они не имеют особого значения для проекта.

Оставляйте только сведения, которые помогают в конкретной работе. Общие объяснения занимают контекст, но не обязательно улучшают результат.

Ошибка 3. Подробные пошаговые руководства в CLAUDE.md

Длинные инструкции по развёртыванию проекта, миграциям базы данных или созданию компонентов быстро раздувают основной файл.

Подробные процедуры можно вынести в skills/ или docs/, а в CLAUDE.md оставить краткую ссылку: «Перед созданием миграции прочитай docs/migrations.md».

Ошибка 4. Повтор правил, которые проверяют инструменты

Требования вроде точек с запятой, удаления неиспользуемых импортов и отказа от var могут проверяться ESLint, Prettier или Biome.

Автоматическая проверка надёжнее текстового напоминания, если инструмент настроен на нужное правило. Настройте анализатор кода, а в CLAUDE.md оставьте только инструкции, которые не покрывает автоматическая проверка.

Ошибка 5. Секреты в CLAUDE.md

Не помещайте в файл пароли, токены API и ссылки с данными авторизации. Если CLAUDE.md хранится в git, такие сведения могут попасть в репозиторий и контекст модели.

Храните секреты в предназначенном для них хранилище, например в .env, который исключён из git. В CLAUDE.md можно указать, как безопасно работать с такими файлами.

Ошибка 6. Накопление инструкций без регулярной очистки

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

Проверьте файл, если в нём больше 300 строк, повторяются одни и те же правила или сохранились устаревшие пути и заметки. Регулярно удаляйте то, что больше не относится к текущей работе.

Ошибка 7. Файл создали, но перестали обновлять

Если проект изменился, а CLAUDE.md остался прежним, его инструкции могут устареть. Дополняйте файл, когда обнаруживаете повторяющуюся ошибку или меняются инструменты и структура проекта.

Если в нескольких сессиях приходится повторять одно и то же замечание, проверьте, можно ли оформить его как короткое правило.

Как организовать обновление инструкций после сессии?#

Пример такого раздела:

## Самообучение

В конце каждой сессии проверь:
- узнал ли я что-то новое о пользователе или о работе с ним?
- нарушил ли я какое-то правило, которое теперь надо зафиксировать?

Если да - создай или обнови файл в `about-me/feedback/` по формату:
Rule (правило одной строкой) → Why (почему появилось)
→ How to apply (когда срабатывает).

Я не пишу правила руками - я говорю «не так, потому что вот так»,
а ты оформляешь это в файл.

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

За два месяца работы в about-me/feedback/ может накопиться несколько десятков записей о предпочтениях и ошибках. Удобный формат отдельной заметки: Rule → Why → How.

Каждая проверенная ошибка может стать правилом, а новые правила — дополнить существующий набор инструкций. При этом полезно периодически пересматривать записи, чтобы они оставались точными и актуальными.

Как добавить в CLAUDE.md юридические, маркетинговые и операционные правила?#

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

Вот три возможных направления.

Юридические требования для регулируемых рынков

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

Пример ниже показывает только формат внутренней инструкции. Его нельзя считать универсальной юридической рекомендацией или разрешением использовать перечисленные формулировки:

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

Правило проекта: в клиентских материалах исключаются слова «вклад», «депозит», «гарантированная доходность» и «инвестиционный продукт». Вместо них используются формулировки «накопительный счёт», «ожидаемая доходность» и «продукт с переменной ставкой». Причина указана в правилах проекта и относится к рекламе финансовых услуг.

Такая инструкция напоминает агенту о заданных ограничениях при подготовке клиентского текста. Сами правила необходимо сверять с действующими требованиями для конкретного проекта.

Аналогичным образом можно фиксировать применимые ограничения для:

• Медицинских материалов, в которых нельзя обещать, что продукт «лечит» или «вылечивает».
• Рекламы лекарств, где могут действовать запреты на утверждения вроде «самый эффективный» и требования к предупреждениям.
• Других регулируемых отраслей с особыми требованиями к рекламе.

Маркетинговый стиль и формат публикаций

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

При подготовке публикаций для канала сверяйтесь с style/posts.md. Используйте допустимую разметку и избегайте запрещённых спецсимволов. В конце добавляйте UTM-метку по шаблону utm_source=<канал>&utm_medium=<тип>&utm_campaign=<слаг>.

Конкретные правила помогают придерживаться выбранного оформления и применять нужные UTM-метки.

Операционные привычки

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

Команда «План на неделю»: откройте ops/monthly.md, создайте рядом файл YYYY-WNN.md и распределите задачи из ops/backlog.md по дням. Команда «Что в бэклоге?»: покажите список из ops/backlog.md. Команда «Закрой неделю»: заполните раздел «Итог недели» в файле текущей недели.

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

Как проверить CLAUDE.md по списку из 12 пунктов?#

1. Размер. Файл краток, а примерно 200 строк используются как повод для пересмотра, не потолок прохождения проверки?
2. Имя. Он называется CLAUDE.md с заглавными буквами?
3. Расположение. Файл находится в корне проекта или в ./.claude/CLAUDE.md?
4. Описание проекта. Понятно ли по первым пяти строкам, что это за проект и для кого он предназначен?
5. Инструменты. Перечислены ли технологии явно и кратко?
6. Структура. Есть ли схема репозитория с пояснениями?
7. Навигация. Указано ли, какой файл открывать для ответа на конкретный вопрос?
8. Принципы. Есть ли конкретные правила работы?
9. Проверяемость. Можно ли объективно определить, выполнено ли каждое правило?
10. Обновление. Есть ли инструкция проверять в конце сессии, нужно ли внести изменения?
11. Итоги. Указано ли, где записывать результат сессии, например в retrospectives/?
12. Безопасность. Настроены ли критичные ограничения, например для .env и rm -rf, средствами конфигурации?

Если более чем в пяти пунктах ответ «нет», можно попросить Claude провести такой аудит:

Прочитай мой CLAUDE.md и сверь его с чек-листом ниже. По каждому пункту скажи: да / нет / частично, и что конкретно поправить.

Чек-лист:

Файл достаточно краток для задачи; пересмотр около 200 строк без жёсткого потолка

Описание проекта в первых 5 строках

Инструменты перечислены явно

Есть схема структуры репозитория

Есть таблица «вопрос → файл»

Есть раздел принципов с правилами

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

Прописано правило «обнови в конце сессии»

Прописано правило «рефлексия в конце сессии»

Критичные запреты есть в .claude/settings.json

Нет дублей одного правила в разных секциях

Нет «висящих» ссылок на файлы, которых уже нет

После аудита - дай список конкретных правок, которые сделают файл живым.

Что делать после CLAUDE.md: Plan Mode, Skills и субагенты?#

Когда основные инструкции настроены, можно подключить другие возможности Claude Code.

Plan Mode. В этом режиме Claude сначала готовит план и ждёт подтверждения, прежде чем менять файлы. В статье указаны сочетание Shift+Tab и команда /plan для включения. Предварительный просмотр плана помогает оценить предполагаемый объём изменений.

Skills. Это отдельные файлы .md в .claude/skills/ с инструкциями для конкретных типов задач. Например, там можно описать процедуру создания миграции базы данных. Claude загружает такие сведения по мере необходимости, поэтому их не обязательно целиком помещать в CLAUDE.md.

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

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

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

Если вы хотите дополнить CLAUDE.md бизнес-контекстом, правилами работы и ссылками на материалы проекта, используйте подходящие примеры из этого руководства. Другие материалы доступны в руководствах Ailoot.

Продолжайте изучать инструменты и практики вместе с Ailoot.