Вот полный текст исследования (в нормальной кодировке, можно копировать как UTF‑8‑markdown):

***

# Лучшие практики работы с Claude Code (февраль 2026)

Это исследование собирает актуальные best practices по использованию Claude Code для разработки приложений на февраль 2026 года: как настраивать среду, как организовать работу с проектом, какие инструкции давать, и какая структура планирования и реализации наиболее эффективна.

***

## 1. Философия Claude Code

### 1.1. Ключевая идея

Claude Code построен по принципу «дать ИИ полноценный компьютер»:

- доступ к файловой системе проекта;
- возможность читать, создавать и изменять файлы;
- запускать команды терминала и тесты;
- работать с Git (ветки, коммиты, PR и т.д.);
- подключать внешние инструменты через MCP, плагины и LSP.

Это отличает Claude Code от «подсказчиков кода»: он действует как полноценный агент‑разработчик, а не просто генератор сниппетов.

### 1.2. Иерархия инструкций

Важная иерархия, с которой нужно работать осознанно:

1. **CLAUDE.md** – «системный контракт» проекта. Самый приоритетный источник правил.
2. **Skills / плагины / hooks** – специализация и автоматизация поведения.
3. **Промпты пользователя** – тактические инструкции в рамках CLAUDE.md.

Вывод: вместо длинных промптов из раза в раз вкладывайте усилия в грамотный CLAUDE.md и skills.

***

## 2. Базовая настройка Claude Code

### 2.1. Минимально необходимый набор

**1) Language Server (LSP) под ваш стек**

- Даёт Claude структурированное понимание кода (типы, символы, ошибки).
- Существенно повышает качество рефакторинга и навигации.

Примеры (зависят от конкретного хоста/IDE, но общий принцип такой):

- Python: `pyright`, `pylsp` или аналог.
- TypeScript/JS: `typescript-language-server`.
- Go: `gopls`.
- Java: `jdtls`.

**2) Базовые плагины (если доступны в вашей сборке Claude Code)**

Плагин/набор для:

- запуска тестов и форматирования;
- работы с Git (коммиты, ветки, PR);
- доступа к документации/справке.

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

### 2.2. Общие рекомендации по конфигурации

- Включите **Plan / разрешённый режим по умолчанию** (plan‑mode) для сложных задач.
- Настройте отображение текущего контекста (команда вида `/context`), чтобы понимать, какие файлы и правила Claude учитывает.
- Стандартизируйте расположение конфигурации: `.claude/`, `.claude-plugin/`, `.mcp.json`, `.lsp.json` и т.п.

***

## 3. CLAUDE.md – основной рычаг управления

### 3.1. Назначение CLAUDE.md

CLAUDE.md – это «паспорт» проекта для Claude:

- объясняет архитектуру и структуру кода;
- фиксирует правила стиля и качества;
- задаёт ограничения (что нельзя трогать);
- описывает команды сборки/тестов и workflow команды;
- вводит доменную терминологию.

Claude **автоматически** ищет этот файл в корне проекта и следует ему гораздо строже, чем одноразовым промптам.

### 3.2. Как создать начальный CLAUDE.md

Типичный подход:

1. Запустите Claude Code в корне проекта.
2. Дайте команду вроде `/init` или явный промпт:  
   «Проанализируй структуру проекта и сгенерируй базовый CLAUDE.md».
3. Полученный черновик **обязательно отредактируйте вручную**.

Не относитесь к автогенерации как к финальному варианту – это всего лишь старт.

### 3.3. Рекомендуемая структура CLAUDE.md

Пример логической структуры, которая хорошо масштабируется:

1. **Project Overview**
   - назначение проекта;
   - техстек;
   - общая архитектура.
2. **Build & Test**
   - команды сборки, тестов, линтеров;
   - что должно выполняться перед коммитом/деплоем.
3. **Project Structure**
   - карта директорий и их назначения;
   - важные entry‑points.
4. **Code Style & Patterns**
   - форматирование (Prettier/Black, длина строки, отступы);
   - соглашения по именованию;
   - рекомендуемые паттерны (React Query, Zod, CQRS и т.п.).
5. **Protected Paths (Do not touch)**
   - миграции БД;
   - CI/CD пайплайны;
   - конфигурация продакшена.
6. **Dependencies & Impact Map**
   - какие модули критичны и кого они затрагивают.
7. **Workflow & Rules**
   - требования к тестам и покрытию;
   - правила коммитов и PR;
   - требования к документации.
8. **Domain Glossary**
   - термины предметной области;
   - где они реализованы в коде.

Важно держать CLAUDE.md компактным (желательно < 2–3k токенов) и переносить узкоспециализированные вещи в **skills**.

### 3.4. Эволюция CLAUDE.md

Лучшая практика – относиться к CLAUDE.md как к живому документу:

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

***

## 4. Режимы работы: Plan, Auto‑accept и проверки

### 4.1. Plan Mode (режим планирования)

Используется когда:

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

Поведение в Plan Mode:

- Claude читает файлы, анализирует, задаёт уточняющие вопросы;
- строит детальный план шагов (с перечнем файлов и изменений);
- **не вносит изменения**, пока вы явно не согласитесь.

Рекомендация: для любой нетривиальной задачи начинать с Plan Mode и добиться хорошего, понятного плана, а только потом переходить к модификации кода.

### 4.2. Auto‑accept / execution mode

Когда план согласован, можно:

- переключить режим на автоматическое принятие изменений (auto‑accept), чтобы не подтверждать каждое редактирование;
- либо разрешать только отдельные группы изменений.

Практика от команды Claude Code: при хорошем плане часто удаётся сделать «one‑shot» реализацию фичи.

### 4.3. Новая стратегия 2026: Block‑at‑Submit, а не Block‑at‑Write

Вместо того чтобы блокировать каждую запись файла hooks’ами:

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

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

***

## 5. Skills, Slash Commands и Hooks

### 5.1. Skills

**Skills** – это модули экспертизы, описанные в отдельных `SKILL.md`:

- Claude читает их метаданные при старте (экономно по токенам);
- подгружает полный контент только при необходимости (когда задача релевантна описанию).

Использование:

- выделять повторяющиеся типы задач (security review, performance audit, API design review);
- описывать там:
  - когда skill применять;
  - пошаговый процесс;
  - чеклисты и примеры кода «хорошо/плохо».

Рекомендация: заводить skill всякий раз, когда определённую проверку/процедуру приходится повторять регулярно.

### 5.2. Slash Commands (`/command`)

Slash‑команды – способ «зашить» часто используемые промпты и последовательности действий в компактные команды:

- `/commit-push-pr` – подготовить коммит, протестировать, запушить и создать PR согласно стандарту;
- `/test-all` – прогнать типизацию, линтер и все тесты;
- `/refactor-fn` – стандартный сценарий безопасного рефакторинга функции.

Хороший стиль:

- описывать в команде процесс (шаги) и ожидаемый формат вывода;
- использовать примеры ввода/вывода;
- минимизировать необходимость «болтать» с агентом по мелочам.

### 5.3. Hooks

Hooks запускают скрипты/проверки на определённых событиях, например:

- `PreToolUse` – перед вызовом инструмента записи/запуска кода;
- `Stop` – при завершении сессии;
- `UserPromptSubmit` – при отправке промпта.

Лучшие практики:

- вместо жёсткого блокирования корректировать входные данные (input modification);
- автоматизировать форматирование/линтинг перед записью файлов;
- использовать hooks для синхронизации документации, обновления README/CHANGELOG, лёгких метрик.

***

## 6. Структура планирования и реализация (Spec‑Driven Development)

### 6.1. Spec / PRD сначала

Эффективный современный подход (особенно с AI‑агентом):

1. Сначала – **спецификация** (PRD), а не сразу код.
2. Затем – разбиение на фазы/итерации.
3. И только потом – реализация с помощью Claude Code по этой спецификации.

PRD обычно включает:

- описание проблемы и цели;
- user stories и задачи;
- ограничения (performance, security);
- критерии приёмки;
- риски и зависимости.

### 6.2. Работа с фазами

Шаги:

1. Попросить Claude разбить PRD на независимые фазы с явными зависимостями.
2. В Plan Mode построить детальный план для фазы 1.
3. Реализовать фазу 1 и прогнать тесты.
4. Актуализировать план следующей фазы с учётом опыта и результатов.

Это уменьшает риск «раздутой» сессии и даёт точки контроля качества.

***

## 7. Параллельная разработка: Git worktrees и несколько сессий

### 7.1. Зачем параллелить

LLM‑модели по природе недетерминированы: один и тот же промпт может дать разные решения. Этим можно воспользоваться:

- запускать несколько сессий Claude Code параллельно на разных ветках/worktree;
- получать несколько независимых реализаций одной задачи;
- сравнивать и собирать из них лучший вариант.

### 7.2. Практика с Git worktrees

Подход:

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

Это особенно полезно для сложных архитектурных изменений или креативных задач (дизайн API, UI и т.д.).

***

## 8. Управление затратами и токенами

### 8.1. Понимание стоимости

Расход токенов складывается из:

- ваших промптов;
- ответов Claude;
- контекста (истории диалога);
- прочитанных файлов;
- CLAUDE.md и других системных подсказок.

Так как модель статична между запросами, **каждый новый запрос повторно включает весь релевантный контекст**, пока вы его не сократите (через `/compact`, новый чат, ограничение истории и т.п.).

### 8.2. Практики экономии

1. **Один чат – одна задача.** Не мешать несколько больших тем в один диалог.
2. **Регулярная компактизация.** По мере накопления истории просить Claude сжать её в краткое резюме и начать новую сессию с этим резюме.
3. **Краткие, точные промпты.** Не дублировать в промптах то, что уже описано в CLAUDE.md.
4. **Подбор модели под задачу:**
   - простые правки/документация – дешёвая модель;
   - основная разработка – средняя модель (Sonnet‑класс);
   - сложная архитектура, безопасность – самая мощная (Opus‑класс).
5. **Контроль стоимости.** Регулярно просматривать отчёт по стоимости/токенам (если платформа предоставляет `/cost` или аналог).

***

## 9. Практики от команды Claude Code и сообщества

### 9.1. От создателей Claude Code

Из публичных докладов и интервью (конец 2025 – начало 2026):

- акцент на **планировании**: хороший план + auto‑accept режим часто дают мгновенную реализацию фичи «с первого выстрела»;
- активное использование **параллельных сессий** в отдельных worktree;
- CLAUDE.md ведётся как журнал best practices, отражающий эволюцию проекта;
- команда фокусируется на **code review и курсе развития системы**, а не на ручном написании каждой строки.

### 9.2. От опытных пользователей (open‑source и Reddit)

Часто повторяющиеся советы:

- не пытаться «настроить всё и сразу» – начинать с минимального CLAUDE.md и пары команд, затем обрастание по мере реальных нужд;
- выделять время раз в неделю на ревизию CLAUDE.md, skills и slash‑команд;
- для больших монорепо выносить knowledge в набор skills, а в CLAUDE.md оставлять только каркас и правила;
- при миграции/рефакторинге legacy‑систем сначала строить карту модулей и зависимости (Claude отлично в этом помогает в Plan Mode).

***

## 10. Рекомендуемый поэтапный путь внедрения

### Этап 1 (1–2 недели): Базовое использование

- Установить Claude Code и LSP под ваш стек.
- Создать минимальный CLAUDE.md: tech‑stack, команды сборки/тестов, структура директорий.
- Использовать Claude для локальных задач: генерация кода, простые рефакторинги, написание тестов.

### Этап 2 (3–4 недели): Структурирование

- Перевести основные правила и паттерны в CLAUDE.md.
- Создать 3–5 slash‑команд для частых действий: коммит, прогон тестов, подготовка PR, стандартный рефакторинг функции.
- Ввести spec‑first подход: для каждой новой фичи сначала короткий PRD или хотя бы структурированный план.

### Этап 3 (2+ месяца): Продвинутое использование

- Завести skills под повторяющиеся виды анализа (security, performance, API‑дизайн, UX‑ревью).
- Настроить hooks для автоматизации форматирования, базовой валидации и обновления документации.
- Освоить работу с несколькими worktree и параллельными сессиями для сложных задач.
- Регулярно анализировать затраты токенов и подстраивать стратегии.

***

## 11. Краткое резюме лучших практик

1. **Инвестируйте в CLAUDE.md.** Это главный рычаг качества и предсказуемости работы Claude.
2. **Планируйте перед реализацией.** Используйте Plan Mode и PRD‑подход.
3. **Выносите знания в skills и команды.** Повторяемые сценарии должны жить не в голове, а в конфигурации.
4. **Разделяйте задачи по сессиям.** Один чат – одна цель.
5. **Контролируйте контекст и стоимость.** `/compact`, короткие промпты, правильный выбор модели.
6. **Экспериментируйте с параллельными реализациями.** Git worktrees + несколько сессий часто дают лучшие решения.
7. **Постепенно эволюционируйте настройку.** Не пытайтесь сразу построить «идеальный» CLAUDE.md – он вырастет из практики.

***

Если хочешь, дальше можно сделать второй шаг: на основе этого исследования собрать именно твой кастомный `CLAUDE.md` под текущий стек/проект (React, backend, монорепа и т.п.) — просто опиши свой проект и требования, и будет конкретный файл под тебя.

