За 6 месяцев ежедневной работы с Claude Code я выработал 10 конфигов. Без них теряю по 10-15 часов в месяц на исправление того, что агент сделал не так. С ними ощутимо меньше. Это не туториал «что такое Claude Code». Это конфиги для тех, кто уже работает с инструментом и хочет выжать из него больше. Готовые конфиги в конце каждого раздела, копируйте сразу.

---

1. CLAUDE.md до 8к символов, остальное в отдельные файлы

Главная ошибка первых месяцев: пихать в CLAUDE.md всё подряд. К марту у меня был файл на 40к символов. Архитектурные решения, стайл-гайд, правила тестирования, примеры промптов, доменная модель, онбординг, история изменений. Казалось, чем больше контекста, тем лучше результат.

Это не так. Проблема в attention механизме: трансформер хуже удерживает информацию из середины длинного документа. При 40к символах Claude начал «забывать» правила которые были в середине файла. Не игнорировать. Буквально не замечать. Проверил экспериментально: попросил агента воспроизвести правило из строки 300 своего CLAUDE.md. Не смог.

Жёсткий лимит: 8к символов на главный файл. Остальное выносится в отдельные файлы по запросу.

Структура которая работает у меня:

.claude/
├── CLAUDE.md              # постоянный контекст, до 8к символов
├── skills/
│   ├── nestjs.md          # правила для NestJS сессий
│   ├── migration.md       # правила для TS-миграций
│   ├── review.md          # правила для code review
│   └── testing.md         # стратегия тестирования
└── specs/
    ├── domain-model.md    # доменная модель проекта
    ├── api-contracts.md   # API контракты
    └── infra.md           # инфраструктура и деплой

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

После рефакторинга: главный файл 6к символов, ответы заметно точнее, контекст не теряется в середине длинных сессий. Расход токенов на инициализацию сессии упал примерно на 35%.

---

2. .claude/settings.json — три настройки которые меняют процесс

Большинство разработчиков вообще не открывают settings.json. Дефолт работает, и ладно. Три настройки которые я добавил сразу после первого месяца работы:

Разрешения на чтение и тесты без подтверждения:

{
  "permissions": {
    "allow": [
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(git status:*)",
      "Bash(git show:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(npm run typecheck:*)",
      "Bash(cat:*)",
      "Bash(grep:*)",
      "Bash(find:*)"
    ],
    "deny": [
      "Bash(git push:*)",
      "Bash(git reset --hard:*)",
      "Bash(rm -rf:*)"
    ]
  }
}

Всё что читает и проверяет, проходит без паузы. Всё что пишет в git или удаляет, требует подтверждения. Количество прерываний за сессию упало с 15-20 до 2-3. Субъективно сессии стали в полтора раза комфортнее.

Логирование через Stop hook (подробнее в разделе 4):

{
  "hooks": {
    "Stop": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "echo \"$(date '+%Y-%m-%d %H:%M') session ended\" >> ~/.claude/log.txt"
      }]
    }]
  }
}

Предупреждение перед деструктивными операциями:

{
  "permissions": {
    "deny": [
      "Bash(drop table:*)",
      "Bash(truncate:*)",
      "Bash(delete from * where 1:*)"
    ]
  }
}

Всё это живёт в .claude/settings.json в корне проекта и коммитится в репозиторий. Каждый разработчик в команде получает те же ограждения.

---

3. acceptEdits — включать выборочно, не глобально

acceptEdits убирает запрос подтверждения перед каждым изменением файла. Звучит как экономия времени. Работает только для конкретного класса задач.

Включаю при:

• Миграции типов: JS → TS, исправление any, обновление интерфейсов

• Механических правках: переименование, замена импортов, форматирование

• Генерации тестов для уже написанной логики

• Обновлении документации и комментариев

Не включаю при:

• Новой функциональности

• Рефакторинге архитектуры любой сложности

• Правках в auth, payment, data layer

• Задачах где я не могу сформулировать критерий «готово» за 10 секунд

Кейс из практики. Включил acceptEdits для задачи «почисти неиспользуемые импорты». Агент почистил импорты, потом решил что раз уж смотрит на файлы, стоит переработать несколько сервисов. Формально правильно, но его решение было хуже нашего паттерна. Полчаса ревью которые не планировались.

Правило которое ввёл: acceptEdits только если есть автоматический тест который поймает ошибку. Нет теста, ручное подтверждение.

---

4. Hooks как guardrails — три которые работают

Hooks — самая недооценённая функция Claude Code. Это shell-скрипты которые запускаются до или после инструментов агента. Три которые изменили мой рабочий процесс:

Stop hook — журнал каждой сессии

#!/bin/bash
# ~/.claude/hooks/stop.sh
TASK=$(cat /tmp/claude_current_task 2>/dev/null || echo "no task recorded")
echo "$(date '+%Y-%m-%d %H:%M') | $TASK" >> ~/.claude/session_history.log

После каждой сессии в лог падает время и задача. Через месяц у меня был честный отчёт: в среднем 2ч15мин с агентом в день, 4-5 сессий. До этого думал что работаю с Claude Code «иногда». Данные показали другое.

PreToolUse hook — блокировка опасных команд

#!/bin/bash
# ~/.claude/hooks/pre_tool.sh
COMMAND="$1"
DANGEROUS="(rm -rf|DROP TABLE|truncate|DELETE FROM.*WHERE 1=1|git reset --hard|kubectl delete)"

if echo "$COMMAND" | grep -qiE "$DANGEROUS"; then
  echo "BLOCKED: potentially dangerous command" >&2
  echo "Command: $COMMAND" >&2
  exit 1
fi

За первые три месяца этот hook сработал 7 раз. 5 из них агент предлагал разумную операцию которую я в итоге выполнил вручную после проверки. 2 раза был рад что hook остановил.

Notification hook — уведомление когда готово

#!/bin/bash
# macOS
osascript -e 'display notification "Claude Code завершил задачу" with title "Claude Code"'

# Linux
notify-send "Claude Code" "Задача завершена"

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

Подключение в settings.json:

{
  "hooks": {
    "Stop": [{
      "matcher": "",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/stop.sh"
      }]
    }],
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/pre_tool.sh \"$TOOL_INPUT\""
      }]
    }]
  }
}

---

5. Multi-model council для архитектурных решений

У Claude Code можно запускать параллельные сессии с разными моделями на одну задачу, потом синтезировать результаты. Звучит как трата времени. На деле заменяет 3-4 часа командного обсуждения.

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

Три запроса к разным моделям:

Opus:   «Спроектируй [X]. Приоритет: надёжность и явность контрактов»
Sonnet: «Спроектируй [X]. Приоритет: скорость разработки»
Haiku:  «Спроектируй [X]. Минимальная сложность, минимум абстракций»

Три разных предложения с разными компромиссами. Потом открываю четвёртую сессию с Opus и прошу синтезировать лучшие части всех трёх с учётом нашего контекста.

Занимает 20-25 минут. На последнем крупном рефакторинге (переработка event-driven части системы) это заменило недельную дискуссию в команде. Пришли к более чистому решению чем если бы обсуждали вдвоём-втроём.

Особенно хорошо работает когда в команде нет второго сеньора для технического ревью решения.

---

6. Параметры усилий — глубина под задачу

Глубина проработки агента зависит от того насколько подробно вы описываете задачу и ожидаемый процесс. Я формализовал это в skill с четырьмя уровнями:

# skill: effort-levels

/effort low
Быстрый черновик. Без объяснений, без плана. Просто написать код.
Использовать для: небольшие утилиты, скрипты, разовые задачи.

/effort medium  
Обычная задача. Краткий план, потом реализация.
Использовать для: стандартные фичи, исправления, рефакторинг.

/effort high
Сложная задача. Развёрнутый план, потом реализация.
Использовать для: новые компоненты, изменения публичных API.

/effort max
Критическая задача. Анализ, план, одобрение, реализация, отчёт.
Агент останавливается после каждого шага и ждёт явного ок.
Использовать для: изменения в ядре системы, auth, schema migrations.

На /effort max у меня за полгода ноль случаев когда пришлось полностью откатываться. На задачах без явного уровня было 3-4 раза когда агент уходил не туда и я обнаруживал это только в конце.

Дополнительный бонус: когда пишешь /effort max и видишь что для этой задачи кажется overshoot, это сигнал что задача проще чем казалась. И наоборот.

---

7. Context Rot — распознать и перезапустить вовремя

Context Rot: деградация качества ответов по мере накопления контекста в длинной сессии. Агент начинает противоречить сам себе, «забывать» принятые решения, предлагать то что уже было отклонено.

Три признака:

• Агент предлагает подход который вы уже обсуждали и отклонили в этой же сессии

• Советует изменить код который только что написал

• Отвечает «давайте уточним контекст» на задачу которую вы дали 10 сообщений назад

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

Мой шаблон передачи контекста в новую сессию:

# Контекст для продолжения

**Задача:** [1 предложение что хотим сделать]

**Что уже сделано:**
- [файл/функция]: [что именно сделали]
- [файл/функция]: [что именно сделали]

**Что НЕ делать (уже обсуждали):**
- [подход X]: [причина]
- [подход Y]: [причина]

**Следующий шаг:** [конкретно, один пункт]

Заполнение этого шаблона занимает 3-5 минут. В 5-10 раз быстрее чем продолжать деградирующую сессию.

Мой личный триггер: если три сообщения подряд не двигают задачу вперёд, перезапуск без вопросов.

---

8. Правило двух коррекций

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

До этого правила я тратил по 1.5-2 часа на «упрямые» задачи. Давал уточнения, агент переделывал, всё равно не то, давал ещё уточнения. Замкнутый круг.

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

1. Разбить на меньшие части. Если агент не может сделать X правильно дважды, возможно X слишком большое. Разбить на X1 и X2, решать по очереди.

2. Дать пример ожидаемого результата. Вместо «сделай правильно», показываю «вот как должно выглядеть в итоге» с конкретным примером. Разница в точности результата огромная.

3. Написать заготовку. Я набрасываю структуру или сигнатуры, агент наполняет. Это особенно хорошо работает на архитектурных задачах. «Вот интерфейс сервиса, напиши реализацию» и агент работает значительно точнее чем просто «напиши сервис для X».

За полгода правило двух коррекций сэкономило мне по моей оценке 15-20 часов которые раньше уходили в никуда.

---

9. Sandbox mode — разные настройки для разных окружений

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

В settings.json можно написать правила на обычном английском:

{
  "yoloClassifier": {
    "rules": [
      "Allow docker operations in development",
      "Block any operations on production database",
      "Allow dropping tables only in test schema"
    ]
  }
}

Я пошёл дальше и создал отдельные settings для разных окружений:

.claude/
├── settings.json          # правила для продакшен-разработки
├── settings.staging.json  # правила для стейджинга
└── settings.local.json    # правила для локальной разработки

settings.json (строгий):

{
  "permissions": {
    "deny": [
      "Bash(kubectl delete:*)",
      "Bash(terraform destroy:*)",
      "Bash(DROP TABLE:*)"
    ]
  }
}

settings.local.json (свободный):

{
  "permissions": {
    "allow": [
      "Bash(docker compose down:*)",
      "Bash(docker compose up --build:*)",
      "Bash(npm run db:reset:*)"
    ]
  }
}

Переключение:

# локальная разработка
CLAUDE_CONFIG=.claude/settings.local.json claude code

# алиас в .bashrc
alias cc-local='CLAUDE_CONFIG=.claude/settings.local.json claude code'
alias cc='claude code'

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

---

10. Skills для lazy-loading специфичного контекста

Skills — это markdown-файлы в .claude/skills/ которые подгружаются через /skills/название. Агент получает содержимое файла как дополнительный контекст.

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

Моя структура:

.claude/skills/
├── nestjs-conventions.md    # наши соглашения по NestJS модулям
├── clean-arch.md            # принципы CA в нашем проекте с примерами
├── typescript-strict.md     # правила TypeScript strict которые используем
├── git-workflow.md          # наш git flow и правила коммитов
├── testing-strategy.md      # стратегия и паттерны тестирования
├── migration-playbook.md    # плейбук для TS-миграций
└── code-review-checklist.md # чеклист для code review сессий

Каждый skill: контекст для конкретного типа задач:

• Пишу новый NestJS модуль → /skills/nestjs-conventions

• Рефакторю архитектуру → /skills/clean-arch

• Делаю code review → /skills/code-review-checklist

Пример части nestjs-conventions.md:

# NestJS соглашения в нашем проекте

## Структура модуля
Каждый модуль содержит: domain/, application/, infrastructure/, presentation/
Запрещено: прямые зависимости между модулями в слое domain

## Что запрещено
- class-validator НЕ используется для бизнес-валидации, только для DTO на входе
- Repository pattern ОБЯЗАТЕЛЕН для всех операций с БД
- NestJS Lifecycle hooks использовать только в Application layer

## Примеры
[реальные примеры из кодовой базы]

Результаты после перехода на skills:

• Главный CLAUDE.md с 40к символов сократился до 6к символов

• Специфичный контекст загружается по запросу

• Расход токенов на стандартную сессию упал на 30-40%

• Агент перестал путать правила из разных доменов

---

Итог

Эти 10 настроек: результат 6 месяцев итерации. Часть из них не очевидна из документации, часть пришла через прямую боль когда что-то шло не так.

Главное что понял за это время: Claude Code это не инструмент который хорошо работает из коробки. Это платформа для настройки рабочего процесса. Дефолты работают на уровне «достаточно». Правильная конфигурация выводит на уровень «серьёзно ускоряет».

По моей оценке, эти 10 настроек сэкономили мне в общей сложности 50-60 часов за первые полгода. Примерно неделя рабочего времени.

Если у вас есть свои конфиги которые не попали в этот список, пишите в комментарии. Особенно интересно про hooks: там явно есть паттерны которые я ещё не нашёл.

Подробнее о структуре CLAUDE.md и Skills пишу в Telegram-канале AI-усиленный разработчик. Там же выкладываю готовые шаблоны конфигов.