CLAUDE.md и скиллы: как настроить Claude Code под себя

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

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

Почему агент вас «не слушается»

Никакой мистики. Агент видит только то, что попало в текущий разговор. Вчерашние объяснения для него не существуют — как для официанта в другом городе не существует ваших вкусов 🙂

Отсюда правило, на котором держится всё дальнейшее:

Знание должно жить в файлах, а не в переписке.

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

Это четыре разных инструмента, и путать их дорого.

Сделайте прямо сейчас. Откройте новую сессию и попросите агента повторить вчерашнюю задачу — ничего не объясняя. Всё, что он сделает не так, и есть ваш список того, что пора вынести в файлы. Это и будет черновиком вашего CLAUDE.md, причём написанным не из головы, а по факту граблей.

Четыре слоя управления агентом

Все способы «объяснить агенту, как надо» делятся на четыре слоя — от самого мягкого к самому жёсткому.

1. Разовый промпт. Обычное сообщение в чате: «сделай сводку по этим выгрузкам, суммы округляй до рубля». Работает здесь и сейчас, живёт до конца сессии. Отличный инструмент для разовой задачи и худший — для регулярной.

2. Файл проектных инструкций CLAUDE.md. Текстовый файл в папке проекта. Агент подхватывает его сам при каждом запуске — напоминать не нужно. Но это по-прежнему просьба: может выполнить, а может и упустить. Модель недетерминирована — на один и тот же вопрос дважды отвечает по-разному. Не баг, а природа.

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

4. Файл настроек программы settings.json. Это уже не про модель. Это настройки самой программы, которая запускает агента. Здесь вы решаете, какие действия ей вообще будут доступны. Закрыли доступ к файлу с ключами — такого действия у агента просто не появится в списке возможных. Не «он постарается не читать», а не сможет.

Как выбрать слой — правило на четыре строки:

• задача разовая → промпт;
• повторяется в этом проекте → строка в CLAUDE.md;
• это процедура на пять и больше шагов → скилл;
• слово «нельзя» → только settings.json.

Главную мысль я бы вытатуировал на клавиатуре: просить и запрещать — разные инструменты.

Секреты вежливой просьбой не защищают. Строчка «пожалуйста, не заглядывай в файл с паролями» в CLAUDE.md — это не защита, это записка на холодильнике. Работает, пока никто не голоден 🙂 Настоящий запрет живёт только в настройках программы.

Настройка Claude Code: анатомия рабочего CLAUDE.md

CLAUDE.md — обычный текстовый файл в корне папки с проектом. Агент читает его сам, каждый раз. Что туда класть:

• Что за проект и зачем. Первая строка объясняет суть. Не «Проект по контенту», а «Блог студии по ремонту квартир, пишем для собственников 35+, цель — заявки на замер».
• Для кого и в каком тоне. Аудитория, tone of voice, стоп-слова. Без этого агент честно выдаёт «синергию» и «инновационные решения».
• Команды. Как запустить обработку, как проверить результат. Про команду, которой нет в инструкции, агент попросту не знает — а значит, и не воспользуется ею. Самая недооценённая строчка файла.
• Структура папок. Где выгрузки, где шаблоны, куда складывать готовое.
• Ссылки на подробные документы. Не пересказ методики, а адрес: подробности — в отдельном файле.
• Правила оформления. Формат дат, разделители тысяч, единицы измерения, обязательные разделы отчёта.

Чего в файле быть не должно:

• Ключей, паролей, токенов, доступов к рекламным кабинетам. Никогда. Файл может уехать в общее хранилище, в архив, в переписку — и уедет.
• Простыней текста. Пятиэкранное описание вашей методологии — в отдельный документ, а в CLAUDE.md — ссылка на него.
• Повторяющихся процессов. Расписали процедуру на 30 строк — это уже не инструкция проекта, это скилл. В CLAUDE.md от неё останется одна строка: «для проверки текстов используй скилл text-review».

Claude md: примеры того, как это выглядит

Мини-пример для проекта «ежемесячные отчёты по контексту» — специально куцый, чтобы было видно жанр:

# Отчёты по Директу

Проект: ежемесячные отчёты по контекстной рекламе для 6 клиентов.
Читатель отчёта — собственник бизнеса, не маркетолог. Пишем без жаргона.

## Структура
- data/   — выгрузки из Директа (csv, по одной на клиента)
- reports/— готовые отчёты (docx)
- docs/   — методика и шаблоны

## Правила
- Суммы — в рублях, без копеек, с пробелом между тысячами.
- CPL и ДРР считаем по методике из docs/metrics.md — читай её перед расчётом.
- Никаких выводов «трафик вырос» без сравнения с прошлым периодом.

## Процессы
- Сборка отчёта — скилл report-builder.
- Проверка текста отчёта — скилл text-review.

IMPORTANT IF: в выгрузке меньше 30 дней — не считай динамику,
напиши прямо, что данных недостаточно, и спроси меня.

По-человечески здесь сказано: что за проект, кто его читатель, где что лежит, по каким правилам считать, куда идти за деталями и как вести себя в скользкой ситуации. Двадцать строк — и половина будущих споров снята заранее.

Размер решает

Держите файл коротким. Разумный ориентир — несколько десятков строк, край — сотня-полторы; жёсткого лимита нет, это вопрос гигиены, а не правил. Причина простая: файл всегда попадает в контекст. Он не подгружается по требованию, он там при каждом запуске, и каждая лишняя строка съедает место, которое могло бы уйти на вашу задачу. Как расходуется этот бюджет и почему он не бесконечный — я подробно разбирал в статье про лимиты.

И теперь неприятное: инструкция с противоречиями хуже, чем никакой. Если внутри файла в одном месте «пиши коротко», а в другом «раскрывай каждый тезис на абзац» — доверие модели падает не к спорному пункту, а к документу целиком. Как у сотрудника, которому вручили регламент, где пункт 4 отменяет пункт 2 🙂

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

Два приёма, чтобы агент реально читал инструкцию

Приём первый: адрес вместо простыни. Не вываливайте методику расчёта в основной файл — оставьте условие и адрес:

Правишь оформление отчёта — сначала прочитай docs/style.md
Считаешь ДРР и окупаемость — сначала прочитай docs/metrics.md
Готовишь коммерческое — сначала прочитай docs/offer-template.md

Агент сходит и откроет — но только тот файл, который нужен под текущую задачу. Инструкция остаётся тощей, знания — полными.

Приём второй: условные блоки. Формулируйте важное через «важно, если…»: сначала ситуация, потом действие. Такая связка считывается заметно надёжнее, чем ровный абзац с правилами, — вы даёте не абстрактную норму, а триггер.

IMPORTANT IF: клиент из медицины —
не пиши гарантий результата и проверь формулировки по docs/med-restrictions.md

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

Иерархия настроек Claude Code: глобальные, командные, личные

Настройки и инструкции живут на трёх уровнях:

Уровень	Где лежит	Для чего
Глобальный	в системной папке пользователя	То, что верно всегда и во всех проектах: на каком языке с вами общаться, как вы любите работать
Командный проектный	в папке проекта, уезжает вместе с ним	Правила конкретного проекта, общие для всех, кто в нём работает
Личный	в папке проекта, но помечен как личный и не уезжает к коллегам	Ваши эксперименты и предпочтения, которые никого не касаются

Два факта, которые надо усвоить намертво.

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

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

А вот главный грех — противоречия между уровнями. Живой пример: глобально у вас записано «обращайся к читателю на „ты“, мы пишем неформально», а в проекте банковского клиента — «только „вы“, тон строгий». Формально конфликта нет: победит проектное правило. Но модель всё равно получает два указания разом и начинает подмешивать панибратские обороты в текст для банка. Лечится разделением: в глобальный файл — только то, что не меняется от проекта к проекту, в проектный — только то, что специфично именно для него. Дублировать одно в другом не надо: это не подстраховка, а способ получить конфликт на ровном месте.

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

Настройка Claude Code на уровне прав: settings json permissions

Теперь про жёсткий слой. Файл настроек программы — не промпт, модель его не читает вообще. Его читает программа, которая решает, что агенту позволено делать.

Права бывают трёх состояний:

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

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

Классический набор для человека, который работает с клиентскими данными:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(secrets/**)",
      "Read(clients/**/passwords.txt)"
    ],
    "ask": [
      "Bash(git push:*)"
    ]
  }
}

Словами: агенту закрыт файл с переменными окружения (там обычно и лежат ключи от рекламных кабинетов и аналитики), папка secrets целиком и любые файлы паролей внутри клиентских папок. И он обязан спросить, прежде чем отправлять изменения наружу — туда, где их увидят другие.

Синтаксис — на момент написания статьи; конкретные имена правил в таких инструментах меняются от версии к версии, поэтому сверяйтесь с актуальной документацией, а не с моим примером годовой давности.

Руками этот файл писать не обязательно. Скажите агенту: «добавь в настройки запрет на чтение папки secrets» — допишет сам. Результат всё равно откройте глазами: доверяй, но читай 🙂

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

Claude code скиллы: чем они отличаются от промпта и от инструкции

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

Отличия по существу:

	Промпт	CLAUDE.md	Скилл
Живёт	до конца сессии	всегда в контексте	подгружается по надобности
Статус	пожелание	рекомендация	инструкция к исполнению
Место	чат	один файл	папка с материалами
Может содержать скрипты	нет	нет	да

Ключевое: скилл подтягивается только когда нужен — по смыслу задачи или по прямому имени. Он не отъедает контекст просто так, в отличие от вечно присутствующего CLAUDE.md. И к его содержимому агент относится как к рабочему регламенту, а не как к одному из мнений в интернете.

Пять рабочих паттернов — на примерах из жизни маркетолога

1. Обёртка над документацией или регламентом. Вы упаковываете правила инструмента или свой внутренний свод норм. Пример: скилл «правила рекламных текстов» — что можно и нельзя писать в объявлениях по вашим тематикам, какие формулировки завернёт модерация. Увидев задачу про объявления, агент разворачивает эти правила и следует им, а не своим представлениям о прекрасном.

2. Генератор по шаблону и стилю. Скилл читает образцы вашего стиля и шаблон документа, спрашивает тему и вводные — и выдаёт готовое. Отчёт клиенту, коммерческое предложение, пост в блог. Работает тем лучше, чем больше эталонных образцов вы в него положите. Хотите, чтобы писал как вы, — покажите, как пишете вы.

3. Ревьюер по чек-листу. Вы формулируете чек-лист, агент обязан пройти по нему пункт за пунктом и отчитаться структурно. Пример: проверка брифа от клиента — есть ли бюджет, сроки, ЛПР, критерий успеха, доступы к аналитике. Или вычитка текста: нет ли обещаний результата, нет ли канцелярита, все ли цифры подтверждены.

4. Интервьюер. Скилл сначала опрашивает вас, а уже потом работает. Незаменим там, где качество результата зависит от вводных, а вводные вы вечно забываете дать. Пример: генерация посадочной — сначала пятнадцать вопросов про продукт, аудиторию, возражения и конкурентов, потом текст. Без опроса вы получите лендинг «для всех» 🙂

5. Пайплайн с подтверждениями. Многошаговый процесс, где после каждого шага агент показывает промежуточный результат и ждёт вашего «ок». Пример: свести 40 выгрузок → показать сводную таблицу → подтвердили → посчитать метрики → показать → подтвердили → собрать отчёт. Скажете «нет» на третьем шаге — переделывается третий шаг, а не всё с начала.

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

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

Как собрать первый скилл за вечер

Не садитесь писать скилл с нуля руками. Это как писать бриф за клиента, ни разу его не спросив.

Порядок такой:

1. Покажите эталон. Возьмите задачу, которую делаете хорошо и регулярно. Приложите исходники (три-четыре реальные выгрузки, три-четыре брифа) и результат, сделанный человеком — то есть вами. Эталон — половина успеха.
2. Попросите агента собрать скилл по этому эталону. Он разложит вашу работу на шаги и упакует в папку. Для этого есть официальный скилл-конструктор (skill-creator) — на момент написания он поставляется в комплекте; им и пользуйтесь, руками писать не надо.
3. Придумайте проверочные тесты. Самая человеческая и самая важная часть. Тест — это «вот такой вход, вот такой правильный выход». Пять-шесть штук, и обязательно один заведомо кривой вход: пустая выгрузка, битая кодировка, отсутствующий столбец.
4. Прогоните тесты. Сравните, что выдал скилл, с тем, что должно было получиться.
5. Доработайте скилл по результатам и прогоните снова.
6. Повторяйте, пока результат не подберётся к вашему эталону. Совпадёт стопроцентно не всегда — это нормально.

Мысль, которую стоит подчеркнуть жирным: тесты качества важнее самого скилла. Без них вы не отличите «стало лучше» от «звучит убедительнее», а это очень разные вещи. Текст, который уверенно врёт в трёх цифрах, — худший из возможных результатов.

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

Правило трёх повторов

Простой критерий, когда пора переставать объяснять и начинать упаковывать:

Делаете задачу третий раз одинаково — пора делать скилл.

Первый раз — вы разбираетесь. Второй — думаете «надо бы записать». Третий — процедура вам уже ясна, и она точно повторится ещё десять раз. Дальше вы просто платите налог собственным временем.

Прикиньте порядок величин на своих цифрах. Сборка скилла с тестами — вечер. Объяснение агенту с нуля — условно полчаса каждый раз, плюс правка того, что он понял по-своему. Точные значения у всех свои, но точка окупаемости обычно оказывается ближе, чем кажется, — где-то на третьем-четвёртом повторе, а дальше разрыв только растёт, и не в вашу пользу.

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

Коротко

• Знание должно жить в файлах, а не в переписке: чат кончился — договорённости испарились.
• Четыре слоя управления: разовый промпт → CLAUDE.md → скилл → настройки программы. Первые три просят, последний запрещает.
• Просить и запрещать — разные инструменты. Секреты защищаются только настройками, а не вежливой просьбой в инструкции.
• CLAUDE.md — короткий (ориентировочно десятки строк), с командами, структурой и ссылками на подробные документы. Ключей и паролей там быть не должно никогда.
• Инструкция с противоречиями хуже отсутствующей: она всегда в контексте, а конфликт внутри обесценивает весь файл.
• Уровни настроек складываются; в споре выигрывает более конкретный. Главный грех — противоречия между глобальным и проектным.
• Права доступа: запрещено / спросить / можно. Запрет сильнее всего. Минимум — закрыть файлы с ключами и спрашивать перед отправкой изменений наружу.
• Скилл — упакованная процедура, которую агент выполняет как инструкцию. Пять паттернов: обёртка над регламентом, генератор по шаблону, ревьюер по чек-листу, интервьюер, пайплайн с подтверждениями.
• Собирайте скилл от эталона и обязательно с тестами, включая заведомо кривые входы: без них непонятно, стало лучше или просто красивее.
• Третий одинаковый повтор задачи — сигнал: пора делать скилл.