Что даёт готовая конфигурация Claude Code: тест на реальном репозитории

Уровень: средний · Время чтения: около 12 минут · Обновлено: 8 октября 2026

Готовые наборы для Claude Code обещают многое: десятки субагентов, библиотеку skills, hooks, которые сами гоняют линтер, и подробный CLAUDE.md с правилами команды. Установка занимает минуты. А вот ответить на вопрос «стало ли лучше?» гораздо сложнее. Агент может начать работать аккуратнее. А может тратить половину контекста на чтение инструкций, которые к вашей задаче не относятся.

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

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

Из чего состоит конфигурация

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

• Общие правила — файл CLAUDE.md в корне репозитория. Он загружается в контекст в начале сессии. Сюда пишут команды сборки, соглашения о стиле и запреты.
• Субагенты — файлы в .claude/agents/. У каждого свой системный промпт, набор инструментов и отдельное окно контекста. Основная сессия передаёт им подзадачи.
• Skills — каталоги .claude/skills/<имя>/SKILL.md. Сначала в контекст попадает только их краткое описание, а полное содержимое подгружается, когда skill понадобился.
• Hooks — команды оболочки из .claude/settings.json. Они запускаются на событиях вроде PreToolUse, PostToolUse или Stop и выполняются детерминированно, без решения модели.

Главное различие такое. Hooks срабатывают гарантированно, но расходуют время и не всегда к месту. Правила, агенты и skills — это текст, который модель может учесть или проигнорировать, и платите вы за него токенами контекста.

Шаг 1. Выберите задачу и критерий готовости

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

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

Запишите формулировку задачи в файл. Оба прогона получают её дословно:

mkdir -p ../ab-test
cat > ../ab-test/task.md <<'EOF'
Добавь в модуль экспорта поддержку формата CSV с разделителем ";".
Критерий готовости: существующие тесты зелёные, есть новый тест
на экранирование кавычек, линтер без ошибок. Не меняй публичный API.
EOF

Содержимое задачи здесь только пример. Подставьте свою.

Шаг 2. Подготовьте два изолированных окружения

Оба прогона должны стартовать с одного коммита и не влиять друг на друга. Удобнее всего использовать два git worktree:

# базовая точка — текущий чистый коммит
git status --short        # должно быть пусто
BASE=$(git rev-parse HEAD)

git worktree add ../ab-baseline "$BASE" -b ab/baseline
git worktree add ../ab-config   "$BASE" -b ab/config

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

Проверьте ещё и пользовательский уровень. Настройки, агенты и skills из ~/.claude/ действуют в обоих окружениях, и это может смазать разницу. Посмотрите, что там лежит, и не меняйте эти файлы между прогонами:

ls -la ~/.claude/ 2>/dev/null
ls ~/.claude/agents ~/.claude/skills 2>/dev/null

Шаг 3. Установите конфигурацию только в одну ветку

Прежде чем копировать набор, прочитайте его, особенно hooks. Hook — это произвольная команда оболочки, и выполняется она с вашими правами. Не ставьте набор, в котором есть непонятные вам команды, сетевые вызовы или обращения к файлам за пределами репозитория.

cd ../ab-config

# пример: набор лежит в локальной папке после ручной проверки
cp -r /path/to/reviewed-config/.claude ./
cp /path/to/reviewed-config/CLAUDE.md ./   # если он входит в набор

# проверяем, что именно появилось
find .claude -type f | sort
cat .claude/settings.json

Ниже пример минимального hook, который после каждого изменения файла запускает тесты. В .claude/settings.json он выглядит так:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "npm test --silent" }
        ]
      }
    ]
  }
}

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

Зафиксируйте конфигурацию отдельным коммитом. Так всегда будет видно, с какой именно версией шёл прогон:

git add .claude CLAUDE.md
git commit -m "ab-test: add Claude Code config under test"

Шаг 4. Запустите задачу в обоих окружениях

Подходов два. Выберите один и используйте его для обоих прогонов.

Вариант А: неинтерактивный запуск

В режиме -p Claude Code выполняет задачу без диалога. С флагом --output-format json он возвращает итоговый объект, где есть длительность, число ходов и статистика токенов. Этот вариант лучше воспроизводится, зато вмешательства пользователя в нём фактически сводятся к отказам в разрешениях.

cd ../ab-baseline
claude -p "$(cat ../ab-test/task.md)" --output-format json \
  > ../ab-test/baseline-run1.json

cd ../ab-config
claude -p "$(cat ../ab-test/task.md)" --output-format json \
  > ../ab-test/config-run1.json

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

Вариант Б: интерактивная сессия

Этот вариант ближе к реальной работе. Запустите claude в каждом worktree и вставьте задачу из файла. Затем действуйте по протоколу:

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

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

Шаг 5. Проверьте результат одинаковым способом

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

for dir in ../ab-baseline ../ab-config; do
  echo "== $dir"
  (cd "$dir" && git diff --stat "$BASE" -- . ':!.claude' ':!CLAUDE.md' \
     && npm test --silent; echo "tests exit: $?")
done

Подставьте команды вашего проекта: pytest, go test ./..., cargo test. Отдельно проверьте пункты критерия готовости, которые тестами не ловятся: не поменялся ли публичный API, нет ли лишних файлов, не отключён ли какой-нибудь тест.

Из JSON-вывода варианта А основные поля удобно достать через jq. Набор полей зависит от версии Claude Code, поэтому сначала посмотрите на файл целиком:

jq 'keys' ../ab-test/baseline-run1.json
jq '{duration_ms, num_turns, usage}' ../ab-test/*-run1.json

Шаг 6. Соберите сравнительный отчёт

Ниже шаблон. Ячейки пустые намеренно: цифры заполняются только по вашим замерам.

Особенно полезна строка «контекст в начале сессии». Она показывает, сколько стоит конфигурация ещё до первой строчки работы. Если правила и описания skills занимают заметную часть окна, длинные задачи будут чаще упираться в сжатие контекста.

Под таблицей коротко ответьте на три вопроса:

1. Какой элемент конфигурации реально сработал в этой задаче? В журнале видно, какой субагент вызывался, какой skill подгружался, какой hook сработал.
2. Что мешало: лишние вызовы, конфликт правил, медленные hooks?
3. Решение: оставить целиком, оставить часть (какую) или убрать.

Как разложить эффект по слоям

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

• только CLAUDE.md из набора;
• правила плюс hooks;
• правила, hooks и субагенты, но без skills.

Часто выясняется, что весь выигрыш дают два-три пункта в правилах и один hook с тестами, а остальное только расходует контекст. Тогда полезную часть стоит перенести в свою минимальную конфигурацию.

Типовые ошибки

• Один прогон на вариант. Модель недетерминирована. Один прогон говорит только о том, что исход возможен, а не о том, насколько он типичен. Если времени хватает, сделайте хотя бы по три прогона на вариант и сравнивайте разброс, а не одно значение.
• Разные стартовые условия. Не тот коммит, грязное рабочее дерево, изменённые между прогонами настройки в ~/.claude/.
• Задача под конфигурацию. Если задачу выбрали, глядя на список skills из набора, тест покажет, что набор хорош именно для неё, и ничего больше.
• Вера отчёту агента. «Тесты проходят» в ответе модели — не результат проверки. Запускайте их сами.
• Непрочитанные hooks. Hook выполняет команду без участия модели и без отдельного подтверждения. Набор из непроверенного источника — это непроверенный исполняемый код.
• Дифф с конфигурацией. Сравнивая объём изменений, исключайте .claude/ и CLAUDE.md, иначе ветка с конфигурацией выглядит «тяжелее».

Ограничения методики

• Одна задача — это выборка из одного элемента. Результат относится к этому типу задач в этом репозитории, а не к конфигурации вообще.
• Счёт вмешательств в интерактивном режиме субъективен: экспериментатор после первого прогона уже знает решение.
• Поля JSON-вывода и вывод /context могут меняться от версии к версии Claude Code. Укажите в отчёте версию (claude --version) и модель.
• Польза от правил и skills копится со временем. Если набор описывает соглашения команды, его эффект лучше заметен на серии задач, чем на одной.
• Методика не оценивает читаемость и сопровождаемость кода. Для этого нужно ревью человеком, и лучше вслепую, не говоря ревьюеру, какой вариант откуда.

Уборка после теста

git worktree remove ../ab-baseline
git worktree remove ../ab-config
git branch -D ab/baseline   # только если результат не нужен
# ветку ab/config оставьте, если решили переносить часть конфигурации

Журналы и отчёт из ../ab-test/ сохраните рядом с решением о конфигурации. Через несколько месяцев, когда выйдет новая версия набора или модели, тест можно будет повторить на той же задаче.

Что дальше

Другие практические методики по настройке и проверке агентов собраны в разделе руководств. Термины, которые встретились в статье, — субагент, hook, skill, окно контекста — объяснены в глоссарии.