Сложность:

Как правильно организовывать работу в Claude Code и подобных

Автор: Михаил Шумовский

Обновлено: 31.03.2026

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

Claude Code решает эту проблему. Это инструмент, который работает прямо в терминале, внутри вашего проекта. Он умеет читать файлы, запускать команды, редактировать код. Но главное — он умеет читать инструкции, которые вы заранее подготовили.

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

Присоединяйтесь
к Нейроцеху в Telegram

Гайды, курсы, вебинары — и еще куча всего, чтобы нейросети работали на вас

Вступить

Можно думать об этом так: .claude/ — это памятка, которую вы оставляете помощнику перед началом рабочего дня. Чем точнее памятка, тем меньше вопросов и ошибок.

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

CLAUDE.md — главный файл инструкций

Это первый файл, который Claude Code ищет при запуске. Он лежит в корне проекта, рядом с папкой .claude/, и содержит основные инструкции: кто вы, что за проект, как Claude должен себя вести, что ему запрещено.

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

# Проект
Веб-приложение для управления задачами.
Фронтенд: React. Бэкенд: FastAPI. База данных: PostgreSQL.
## Правила
- Пиши на TypeScript, не на JavaScript.
- Используй функциональные компоненты, не классовые.
- Не меняй файлы в папке /migrations/ без подтверждения.
- Не удаляй существующие тесты.
## Стиль
- Отвечай коротко и по делу.
- Если не уверен — спроси, а не додумывай.

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

Когда файл начинает расти. На старте десяти строк достаточно. Но со временем появляются новые правила, описания модулей, инструкции по работе с API. Файл разбухает до 200–300 строк, и Claude тратит на его чтение все больше контекстного окна — того объема информации, который он может удерживать «в голове» одновременно.

Рекомендация — держать CLAUDE.md в пределах 100 строк. Но куда девать все остальное?

Claude Code поддерживает подключение внешних файлов. Работает это так: вы создаете отдельный файл — например, docs/architecture.md — и описываете в нем архитектуру подробно, на сколько угодно строк. А в CLAUDE.md вместо этого описания ставите одну строку со знаком @ и путем к файлу:

@docs/architecture.md

Когда Claude Code запускается и читает CLAUDE.md, он встречает эту строку, идет по указанному пути, открывает файл и подтягивает его содержимое. Вы не копируете текст вручную — Claude делает это сам.

Таких ссылок может быть несколько. Например, итоговый CLAUDE.md может выглядеть так:

# Проект
Веб-приложение для управления задачами.
@docs/architecture.md
@docs/api-guidelines.md
@~/.claude/CLAUDE.md

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

Персональные настройки. Обратите внимание на последнюю строку в примере — @~/.claude/CLAUDE.md. Она отличается от остальных: путь начинается с ~/, что означает вашу домашнюю директорию. Этот файл не лежит внутри проекта. Он хранится на вашем компьютере отдельно и содержит ваши личные предпочтения — то, что не зависит от конкретного проекта.

Например, вы хотите, чтобы Claude всегда отвечал на русском, показывал полный стек ошибок при отладке и использовал определенный порт. Вы один раз прописываете это в ~/.claude/CLAUDE.md:

# Личные настройки
- Отвечай на русском языке.
- При отладке показывай полный стек ошибки.
- Используй порт 3001 для локального сервера.

И подключаете этот файл через @ в любом проекте. Теперь эти настройки путешествуют с вами — не нужно дублировать их в каждом репозитории.

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

Можно настроить CLAUDE.md еще точнее — для отдельных папок внутри проекта. Например, если в папке src/auth/ лежит свой CLAUDE.md, Claude будет применять его правила при работе с файлами авторизации. Чем конкретнее файл, тем выше его приоритет.

Правила для отдельных частей проекта — .claude/rules/

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

Для этого существует папка .claude/rules/. Внутри нее вы создаете отдельные файлы с правилами, и каждый файл привязывается к определенным папкам или типам файлов. Claude загружает только те правила, которые относятся к файлам, с которыми он сейчас работает. Остальные не попадают в контекст и не расходуют место.

Допустим, в вашем проекте есть фронтенд в папке src/frontend/ и бэкенд в src/backend/. Вы создаете два файла:

.claude/rules/frontend.md:
---
files: ["src/frontend/**", "components/**"]
---
# Фронтенд
- Используй функциональные компоненты React.
- Стили — через CSS Modules, не через inline-стили.
- Состояние — через Zustand, не через Redux.

.claude/rules/backend.md:
---
files: ["src/backend/**", "api/**"]
---
# Бэкенд
- Все эндпоинты возвращают JSON.
- Обязательна валидация входных данных.
- Ошибки — через стандартные HTTP-коды, не через кастомные.

Блок между — в начале файла — это так называемый фронтматтер. В нем указано поле files — шаблон путей, к которым применяются правила. Запись src/frontend/** означает «все файлы внутри src/frontend/ и всех вложенных папок». Когда Claude работает с файлом из src/frontend/, он подгружает frontend.md. Когда работает с бэкендом — backend.md. Если работает с файлом, который не попадает ни под один шаблон, ни одно из этих правил не загружается.

Когда правила лучше, чем один CLAUDE.md. Если проект небольшой и правила умещаются в 50–70 строк, отдельная папка rules/ не нужна — все прекрасно живет в CLAUDE.md. Но как только появляются разные домены (фронтенд, бэкенд, мобильное приложение, тесты, инфраструктура), имеет смысл разнести правила по файлам. Claude будет загружать меньше текста за раз, а вам и коллегам будет проще находить и обновлять нужный раздел.

Навыки — .claude/skills/

В предыдущем блоке мы разобрали правила — файлы, которые говорят Claude, как себя вести при работе с определенной частью проекта. Навыки устроены иначе. Если правило — это ограничение или соглашение («пиши так, не пиши эдак»), то навык — это инструкция к конкретному действию.

Представьте, что вы наняли помощника. Правила — это то, что вы говорите ему в первый день: «У нас принято отвечать клиентам в течение часа, письма пишем на “вы”, в документах используем этот шаблон». А навык — это пошаговая инструкция для конкретной задачи: «Когда приходит новый заказ, сделай вот это, потом вот это, потом проверь вот так».

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

Как выглядит навык. Каждый навык — это папка внутри .claude/skills/ с файлом SKILL.md:

.claude/skills/
└── explain-code/
    └── SKILL.md

Вот пример простого навыка. Допустим, вы часто просите Claude объяснить, как работает тот или иной фрагмент кода. Каждый раз приходится уточнять: «Объясни простым языком, приведи аналогию, дай схему». Вместо этого можно создать навык:

---
name: explain-code
description: Объясняет код через аналогии и визуальные схемы
---
Когда пользователь просит объяснить фрагмент кода:
1. Прочитай указанный файл или фрагмент.
2. Объясни логику простым языком, используя аналогию из повседневной жизни.
3. Если код содержит сложную структуру, нарисуй текстовую схему.
4. В конце — краткое резюме в одном предложении.

Блок между — в начале файла — фронтматтер, мы уже встречали его в правилах. Здесь два поля: name — имя навыка, и description — короткое описание. По этому описанию Claude понимает, когда навык уместен. Если вы спросите «объясни, как работает эта функция», Claude увидит, что описание навыка совпадает с вашим запросом, загрузит инструкции и будет следовать им.

Можно и не ждать, пока Claude догадается — вызовите навык напрямую, набрав /explain-code, как команду.

Где хранить навыки. Здесь та же логика, что и с CLAUDE.md. Если навык нужен только в одном проекте, положите его в .claude/skills/ внутри этого проекта. Если навык полезен вам везде — например, вы всегда хотите объяснения через аналогии — положите его в ~/.claude/skills/ в домашней директории. Он будет работать в любом проекте.

Когда навык не должен запускаться сам. Некоторые действия слишком серьезны, чтобы Claude выполнял их по собственной инициативе. Например, публикация приложения на сервер (деплой) или отправка сообщения клиенту. Вы ведь не хотите, чтобы Claude сам решил: «Похоже, код готов — задеплою-ка я его».

Для таких случаев в фронтматтер добавляется строка disable-model-invocation: true. Она означает: «Этот навык запускается только когда я явно попрошу через /имя-навыка». Claude не будет запускать его автоматически, даже если контекст разговора подходит:

---
name: deploy
description: Публикация приложения на сервер
disable-model-invocation: true
---

Выполни деплой:
1. Запусти тесты.
2. Собери приложение.
3. Отправь на сервер.
4. Проверь, что все работает.

Навыки с параметрами. Иногда навыку нужна дополнительная информация — например, номер задачи. Чтобы не создавать отдельный навык под каждый номер, можно использовать подстановку. Для этого в тексте SKILL.md нужно прописать $ARGUMENTS, и при вызове Claude заменит это на то, что вы напишете после имени навыка.

Допустим, вы хотите, чтобы Claude исправлял задачи из трекера по номеру:

---
name: fix-issue
description: Исправляет задачу из GitHub по номеру
disable-model-invocation: true
---
Исправь задачу $ARGUMENTS:
1. Прочитай описание задачи.
2. Разберись в требованиях.
3. Внеси исправления.
4. Напиши тесты.
5. Сделай коммит.

После этого вы сможете написать, например, /fix-issue 123 — и Claude получит инструкцию «Исправь задачу 123», после чего выполнит шаги по порядку.

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

.claude/skills/explain-code/
├── SKILL.md              # Основные инструкции
├── template.md           # Шаблон ответа
├── examples/
│   └── sample.md         # Пример готового объяснения
└── scripts/
    └── validate.sh       # Скрипт для проверки

Claude не будет загружать эти файлы сразу при старте — только когда они понадобятся по ходу работы. Чтобы Claude знал об их существовании, достаточно упомянуть их в SKILL.md:

## Дополнительные материалы
- Шаблон ответа: [template.md](template.md)
- Пример: [examples/sample.md](examples/sample.md)

Когда Claude дойдет до шага, где нужен шаблон, он откроет файл и подтянет содержимое. Это удобно для сложных навыков — основная инструкция останется компактной, а детали будут подгружаться по мере необходимости.

Встроенные навыки. Claude Code поставляется с несколькими готовыми навыками. Их не нужно создавать — они доступны сразу:

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

/debug — помогает разобраться, почему текущая сессия ведет себя странно. Claude анализирует логи и объясняет, что пошло не так.

/simplify — проверяет файлы, которые вы недавно меняли, на повторы и проблемы с качеством. Находит проблемы и сразу предлагает исправления.

/loop — повторяет действие через заданный интервал. Например, /loop 5m check if the deploy finished будет каждые пять минут проверять, завершился ли деплой.

Субагенты — .claude/agents/

До сих пор мы говорили о том, как настроить одного помощника — дать ему правила, научить навыкам, объяснить проект. Но некоторые задачи удобнее поручить не основному помощнику, а отдельному специалисту.

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

Субагенты в Claude Code работают по тому же принципу. Это отдельные агенты с собственным контекстом, собственными инструкциями и ограничениями. Основной агент передает субагенту задачу, тот выполняет ее изолированно и возвращает результат. Основной агент при этом не тратит свое контекстное окно на промежуточные шаги — он получит только итог.

Встроенные субагенты. Claude Code поставляется с несколькими готовыми субагентами, которые будут использоваться автоматически, когда ситуация подходит:

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

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

General-purpose — универсальный субагент для сложных задач, которые требуют и чтения, и изменений. Claude будет делегировать ему многоступенчатые операции, где нужно сначала разобраться в проблеме, потом исправить код, потом проверить результат.

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

Субагенты хранятся в папке .claude/agents/. Каждый субагент — это файл в формате Markdown. К примеру, вот как может выглядеть агент для проверки кода:

---
name: code-reviewer
description: Проверяет код на качество, безопасность и читаемость. Ничего не меняет, только анализирует.
tools: Read, Grep, Glob, Bash
model: sonnet
---
Ты — ревьюер кода. Когда получаешь задачу:
1. Посмотри последние изменения через git diff.
2. Сосредоточься на измененных файлах.
3. Проверь по списку:
   - Код понятен и читаем.
   - Нет дублирования.
   - Ошибки обрабатываются корректно.
   - Нет открытых секретов или ключей.
   - Тесты покрывают изменения.
4. Сгруппируй замечания по приоритету:
   - Критичные (нужно исправить обязательно).
   - Предупреждения (стоит исправить).
   - Рекомендации (можно улучшить).

Разберем фронтматтер. Поле name — имя субагента. description — описание, по которому Claude будет решать, когда делегировать задачу этому агенту. Поле tools ограничивает набор инструментов: здесь указаны только инструменты для чтения и поиска, без возможности редактирования. Поле model задает модель — sonnet работает быстрее и дешевле, чем Opus, и для ревью этого достаточно.

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

Как Claude будет использовать субагента. После того как вы создадите файл, Claude узнает о новом субагенте при следующем запуске. Когда вы попросите что-то, что совпадает с описанием — например, «проверь мои последние изменения» — Claude делегирует задачу ревьюеру. Тот выполнит работу в своем изолированном контексте и вернет отчет. Вы также сможете вызвать субагента явно, упомянув его через @:

@code-reviewer посмотри изменения в модуле авторизации

Выбор модели. Не каждому субагенту нужна самая мощная модель. Для простых задач вроде поиска файлов или форматирования подойдет Haiku — быстрая и дешевая. Для анализа и ревью — Sonnet. Для сложных архитектурных задач — Opus. Это позволит экономить ресурсы: вместо того чтобы тратить дорогую модель на поиск файлов, Claude отправит эту работу легкому субагенту.

В поле model можно указать haiku, sonnet, opus или inherit (субагент будет использовать ту же модель, что и основной агент).

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

---
name: code-reviewer
description: Проверяет код на качество и безопасность
memory: project
---

Значение project означает, что субагент будет хранить заметки внутри проекта, в папке .claude/agent-memory/code-reviewer/. После каждой проверки он сможет записать, какие паттерны встретил, какие ошибки типичны для этого проекта, — и в следующий раз будет учитывать накопленный опыт.

Фоновая работа. По умолчанию, когда Claude делегирует задачу субагенту, основной разговор приостанавливается до получения результата. Но можно запустить субагента в фоне — тогда вы продолжите работать с основным Claude, пока субагент выполняет свою задачу параллельно. Для этого достаточно попросить: «запусти это в фоне», или добавить в фронтматтер background: true.

Хуки — .claude/hooks/

До сих пор все, что мы настраивали, работало по одной схеме: вы заранее описываете инструкции, а Claude следует им, когда считает нужным (или когда вы попросите). Хуки устроены иначе. Хук — это действие, которое выполнится автоматически, когда произойдет определенное событие.

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

Хуки настраиваются в файле .claude/settings.json (который мы подробнее разберем в блоке про разрешения) или в фронтматтере навыков и субагентов. Вот как выглядит базовый пример:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint:fix"
          }
        ]
      }
    ]
  }
}

Разберем по частям. PostToolUse — это событие. Оно означает «после того, как Claude использовал какой-либо инструмент». Поле matcher уточняет, после какого именно инструмента сработает хук: здесь указано Write|Edit, то есть после записи или редактирования файла. Поле command — это команда, которая выполнится: npm run lint:fix запустит линтер с автоматическим исправлением.

Итого: Claude отредактирует файл → сработает хук → линтер проверит и поправит оформление → вы получите уже чистый результат.

Какие события бывают. Claude Code поддерживает несколько типов событий, к которым можно привязать хуки:

PreToolUse — срабатывает до того, как Claude выполнит действие. Это полезно для проверки: например, вы хотите убедиться, что Claude не выполнит опасную SQL-команду. Хук проверит команду до выполнения и, если она окажется небезопасной, заблокирует ее.

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

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

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

Хуки для защиты. Одно из самых полезных применений хуков — не автоматизация, а защита. Допустим, у вас есть субагент, который работает с базой данных. Вы хотите быть уверены, что он сможет только читать данные, но не изменять их. Хук с событием PreToolUse будет проверять каждую команду перед выполнением:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "./scripts/validate-readonly-query.sh"
          }
        ]
      }
    ]
  }
}

Скрипт validate-readonly-query.sh получит команду, которую Claude собирается выполнить. Если в ней окажется DELETE, UPDATE или DROP, скрипт вернет ошибку и Claude увидит, что действие заблокировано. Если команда безопасная — скрипт пропустит ее, и Claude выполнит запрос как обычно.

Когда хуки нужны, а когда нет. Если вы только начинаете работать с Claude Code, хуки вам пока не понадобятся. Они становятся полезны, когда вы выстроите рабочий процесс и захотите автоматизировать повторяющиеся проверки — линтер после каждого изменения, тесты перед каждым коммитом, валидация перед опасными операциями. До этого момента правил, навыков и субагентов будет достаточно.

Подключение внешних сервисов — .mcp.json

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

Для этого существует протокол MCP — Model Context Protocol. Если упростить, MCP — это способ подключить Claude к внешнему инструменту через стандартный интерфейс. Вы описываете подключение один раз, и дальше Claude сможет использовать этот инструмент так же естественно, как он читает файлы или запускает команды в терминале.

Настройки подключений хранятся в файле .claude/.mcp.json внутри проекта. 

Что это дает на практике. После подключения Claude сможет работать с GitHub напрямую: просматривать открытые задачи, читать комментарии к pull request-ам, оставлять свои комментарии. Вам не придется копировать текст задачи вручную и вставлять его в чат — достаточно будет сказать «посмотри задачу #42 в GitHub и предложи решение».

Помимо GitHub, существуют готовые MCP-серверы для многих популярных инструментов: Slack (для сообщений), PostgreSQL (для работы с базой данных), файловые системы, API различных сервисов. Сообщество постоянно создает новые.

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

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "slack": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_BOT_TOKEN": "${SLACK_TOKEN}"
      }
    }
  }
}

Каждое подключение загружается при старте сессии. Здесь стоит помнить о контекстном окне: каждый MCP-сервер добавляет описание своих инструментов в контекст Claude. Если подключений много, они начнут занимать заметную часть окна. Поэтому подключайте только те сервисы, которые действительно нужны в проекте.

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

---
name: browser-tester
description: Тестирует интерфейс в браузере
mcpServers:
  - playwright:
      type: stdio
      command: npx
      args: ["-y", "@playwright/mcp@latest"]
---
Используй инструменты Playwright для навигации по страницам, создания скриншотов и проверки интерфейса.

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

Разрешения — settings.json и settings.local.json

Claude Code умеет многое: читать файлы, редактировать их, запускать команды в терминале, обращаться к внешним сервисам. Но не всегда вы хотите, чтобы он делал все это без спроса. Некоторые действия безопасны — прочитать файл или найти текст по проекту. Другие — потенциально рискованны: удалить файл, выполнить команду, изменить конфигурацию.

Файл settings.json позволяет заранее определить, что Claude сможет делать самостоятельно, а на что ему понадобится ваше подтверждение.

Вот простой пример:

{
  "permissions": {
    "allow": ["Read", "Grep", "Glob"],
    "deny": ["Write", "Edit"]
  }
}

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

Файл settings.json лежит в папке .claude/ и является частью проекта. Если вы закоммитите его в репозиторий, вся команда будет работать с одинаковыми ограничениями. Это удобно для общих правил безопасности — например, запретить всем участникам автоматическое выполнение определенных команд.

Личные настройки. Иногда ограничения нужны только вам. Допустим, вы работаете на продакшн-сервере и хотите дополнительную страховку — запретить Claude выполнять любые команды в терминале. Но ваши коллеги работают на тестовых серверах, и им это ограничение не нужно.

Для таких случаев существует settings.local.json. Он лежит в той же папке .claude/, но Claude Code автоматически добавит его в .gitignore — файл останется только на вашем компьютере и не попадет в репозиторий.

{
  "permissions": {
    "allow": ["Read", "Grep", "Glob", "Bash"],
    "deny": []
  }
}

Если в settings.json и settings.local.json есть противоречия, Claude будет следовать более строгому ограничению. Если командный файл запрещает что-то, личный файл не сможет это разрешить.

Ограничения для субагентов и навыков. Разрешения позволяют контролировать не только инструменты, но и доступ к субагентам и навыкам. Допустим, у вас есть субагент для деплоя, и вы не хотите, чтобы Claude мог запустить его автоматически:

{
  "permissions": {
    "deny": ["Agent(deploy-agent)"]
  }
}

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

Что настраивать в первую очередь. Если вы только начинаете, файл разрешений можно не создавать — Claude Code будет спрашивать подтверждение перед потенциально опасными действиями по умолчанию. Настройка settings.json становится полезной, когда вы хотите либо ускорить работу (разрешить рутинные операции без подтверждения), либо усилить защиту (запретить определенные действия даже с подтверждением).

Собираем все вместе

Мы прошли все элементы папки .claude/ по отдельности. Теперь посмотрим на картину целиком — как они соотносятся друг с другом и в каком порядке имеет смысл их настраивать.

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

your-project/
├── CLAUDE.md                          # Главный файл инструкций
├── .claude/
│   ├── rules/                         # Правила для отдельных частей проекта
│   │   ├── frontend.md
│   │   └── backend.md
│   ├── skills/                        # Навыки
│   │   ├── explain-code/
│   │   │   └── SKILL.md
│   │   └── deploy/
│   │       └── SKILL.md
│   ├── agents/                        # Субагенты
│   │   ├── code-reviewer.md
│   │   └── debugger.md
│   ├── hooks/                         # Автоматизация по событиям
│   ├── settings.json                  # Командные разрешения
│   ├── settings.local.json            # Личные разрешения
│   └── .mcp.json                      # Подключение внешних сервисов
└── docs/
    ├── architecture.md                # Файлы, подключаемые через @
    └── api-guidelines.md

А в домашней директории — то, что относится лично к вам и действует во всех проектах:

~/.claude/
├── CLAUDE.md                          # Персональные инструкции
├── skills/                            # Личные навыки
│   └── my-skill/
│       └── SKILL.md
└── agents/                            # Личные субагенты
    └── my-agent.md

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

Правило простое: все, что описывает проект и общие правила работы, идет в репозиторий. Все, что касается лично вас, остается локально.

• CLAUDE.md — в репозиторий. Это общие правила проекта, они должны быть одинаковы для всей команды.
• .claude/rules/ — в репозиторий. Правила для частей проекта — тоже общее знание.
• .claude/skills/ — в репозиторий. Навыки, полезные всей команде.
• .claude/agents/ — в репозиторий. Субагенты, доступные всей команде.
• .claude/hooks/ — в репозиторий. Автоматические проверки — часть рабочего процесса проекта.
• .claude/settings.json — в репозиторий. Командные разрешения.
• .claude/.mcp.json — в репозиторий. Подключения к сервисам общие, а секреты хранятся в переменных окружения, а не в самом файле.
• .claude/settings.local.json — только локально. Личные разрешения. Claude Code автоматически добавит этот файл в .gitignore.
• ~/.claude/ — только локально. Все, что лежит в домашней директории, по определению принадлежит только вам.

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

Вам нужно задать стандарт или ограничение — например, «используй TypeScript», «не трогай миграции», «ошибки возвращай в формате JSON». Это правило. Если оно общее для всего проекта — пишите в CLAUDE.md. Если только для определенных файлов — создавайте файл в .claude/rules/.

Вам нужно описать пошаговое действие — например, «как делать деплой», «как объяснять код», «как готовить релиз». Это навык. Создавайте папку в .claude/skills/ с файлом SKILL.md.

Вам нужен отдельный специалист с ограниченным набором инструментов — например, ревьюер, который только читает код, или дебаггер, который ищет и исправляет ошибки. Это субагент. Создавайте файл в .claude/agents/.

Вам нужно, чтобы что-то происходило автоматически при определенном событии — линтер после редактирования, тесты перед коммитом, проверка команды перед выполнением. Это хук.

Вам нужно подключить внешний сервис — GitHub, Slack, базу данных. Это настройка MCP в файле .mcp.json.

С чего начать. Если вы только приступаете к настройке Claude Code, не нужно создавать все сразу. Вот порядок, который имеет смысл:

Первым делом — CLAUDE.md. Опишите проект, основные правила и ограничения. Даже 10 строк заметно изменят качество работы Claude. Это единственный файл, который нужен с самого начала.

Когда CLAUDE.md начнет разрастаться — вынесите часть правил в .claude/rules/. Разделите по доменам: фронтенд, бэкенд, тесты.

Когда заметите, что часто повторяете одни и те же инструкции — оформите их как навыки в .claude/skills/.

Когда задачи станут сложнее и захочется делегировать часть работы — создайте субагентов в .claude/agents/.

Когда выстроите рабочий процесс и захотите автоматизировать проверки — добавьте хуки.

Когда понадобится интеграция с внешними сервисами — настройте .mcp.json.

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

Присоединяйтесь
к Нейроцеху в Telegram

Гайды, курсы, вебинары — и еще куча всего, чтобы нейросети работали на вас

Вступить

Ссылки на документацию. Если вы захотите углубиться в какую-то тему, вот официальные материалы:

• Общий обзор Claude Code — code.claude.com/docs/en/overview
• Навыки — code.claude.com/docs/en/skills
• Субагенты — code.claude.com/docs/en/sub-agents
• Хуки — code.claude.com/docs/en/hooks
• Память и CLAUDE.md — code.claude.com/docs/en/memory
• Разрешения — code.claude.com/docs/en/permissions
• Стандарт AGENTS.md — agentskills.io
• Каталог навыков и конфигураций — dotclaude.com