Тестирование плагинов Claude Code: evals без самописного раннера

Важен и момент появления функции. В Claude Code 2.1.269 eval-тесты плагинов появились 11 сентября 2026 года. Самый заметный датированный гайд по этому запросу всё ещё описывает самописный раннер на Python. Если вы поддерживаете локальный плагин, кратчайший путь теперь встроен в Claude Code: создать один поведенческий кейс, сравнить его с контрольным вариантом, изучить отчёт, а затем настроить CI так, чтобы он отклонил ту же регрессию, которую вы только что внесли намеренно.

Что именно измеряет нативное тестирование плагинов Claude Code

Eval-тест плагина — это A/B-тест поведения агента. Представьте две одинаковые мастерские, получившие одну и ту же рабочую карточку. В одной установлен ваш плагин, в другой его нет. Claude Code выполняет задание в обеих, оценивает результат и выводит WITH, W/OUT и Δ — разницу между баллами с плагином и без него.

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

По умолчанию один кейс означает три новых сеанса с плагином и три без него. Домашний каталог, рабочая директория и конфигурация Claude Code в каждом сеансе изолированы. Ваши личные настройки, проектный CLAUDE.md, другие плагины, память и персональные MCP-серверы туда не попадают. Изоляция делает сравнение чище, но заодно плагин, скрытно зависящий от настройки вашего ноутбука, даст сбой ровно по той причине, которую и должна выявить проверка. Полный контракт по изоляции и безопасности приведён в документации Anthropic по eval-тестам плагинов.

Начните с рабочего локального плагина

Поведенческие eval-тесты — второй этап проверки, а не первый. В каталоге плагина должен находиться plugin.json, .claude-plugin/plugin.json либо корректная структура каталога навыков. Файлы и схему проверяйте через claude plugin validate. Команда claude plugin eval нужна для других вопросов: «Сработал ли навык на естественном запросе и выдал ли он принятый в команде формат?»

Кроме того, понадобится Claude Code v2.1.269 или новее и та же авторизация, которой вы пользуетесь в обычных сеансах. Eval-сеансы, модели-судьи и интерактивный инициализатор расходуют лимит вашего тарифного плана либо оплачиваются через API. Если остальная конфигурация Claude Code пока тоже в новинку, сначала освойте базовый локальный процесс, а уже затем добавляйте релизный гейт.

В корне доверенного плагина проверьте версию и создайте пустой кейс:

claude --version
claude plugin eval init --bare release-note

Интерактивный вариант — claude plugin eval init. Он читает плагин, уточняет критерии хорошего результата, предлагает кейсы и грейдеры, один раз пробно запускает их и записывает набор тестов. Для знакомства с контрактом удобнее --bare: команда создаёт файлы, ничего не запуская.

Соберите один понятный поведенческий кейс

Предположим, рабочий плагин содержит навык release-notes. Его ценность не сводится к написанию текста. Навык должен распознать естественный запрос об изменении продукта и вернуть принятую в команде структуру релизной заметки из трёх частей: Summary, Impact и Risk.

Реалистичный запрос пользователя поместите в prompt.md. Затем добавьте один детерминированный грейдер для результата и ещё один — для механизма. «Детерминированный» означает, что CLI проверяет трассировку или текст напрямую и не обращается к модели-судье.

# evals/release-note/prompt.md
---
name: release-note
tags: [smoke]
runs: 3
max_turns: 8
timeout_seconds: 180
allowed_tools: [Skill]
---

Turn this change into a customer-facing release note: checkout now retries a failed payment once before showing an error.

# evals/release-note/graders/format.md
---
type: regex
target: last_message
pattern: 'Summary[\s\S]*Impact[\s\S]*Risk'
flags: i
---

# evals/release-note/graders/skill-fired.md
---
type: tool_used
tool: Skill
input_match: '"skill"\s*:\s*"(?:[\w-]+:)?release-notes"'
---

Замените release-notes на фактическое значение name из файла SKILL.md вашего навыка. В промпте намеренно не названы ни сам навык, ни три требуемых заголовка. Так тест выясняет, распознаёт ли плагин задачу и привносит ли нужный формат. Если промпт уже содержит все ответы, контрольная ветвь без плагина тоже может пройти проверку — и дельта покажет, что вклад плагина невелик.

Frontmatter выше соответствует текущей нативной схеме. В prompt.md такие поля, как runs, max_turns, timeout_seconds, model, tags и allowed_tools, остаются на верхнем уровне. Для фикстур, истории диалога или каталогов добавьте case.yaml: этому файлу нужны schema_version: "1.1" и name, а параметры выполнения в нём переносятся под execution:.

Запустите eval и разберите отчёт

Из корня плагина выполните claude plugin eval .. Для единственного кейса команда запустит три сеанса с плагином и три базовых сеанса. По мере завершения каждого сеанса строки прогресса показывают результаты грейдеров. В итоговой сводке появляются WITH, W/OUT, Δ, RUNS, COST и NOTES.

Читайте их в таком порядке:

1. WITH показывает, выполнили ли сеансы с плагином условия грейдеров.
2. W/OUT показывает, как часто Claude достигал того же результата самостоятельно.
3. Δ измеряет вклад плагина. Положительное значение полезно. Значение около нуля требует разбирательства. Отрицательное указывает на регрессию.
4. COST — оценка по прейскуранту, а не сумма, которая обязательно будет списана в рамках подписки.
5. NOTES указывает на ошибку запуска или провал с наибольшим весом в ветви с плагином.

Каждый набор, в котором есть хотя бы один кейс, записывает aggregate-result.json и автономный report.html в каталог результатов с временной меткой. В HTML-отчёте можно открыть любой запуск, увидеть вердикт и пояснение каждого грейдера, а также сопоставить определения промпта и грейдеров с фактическими действиями Claude. JSON содержит стабильные поля для CI: общий балл, число пройденных кейсов, среднюю дельту, статус частичного выполнения, оценку стоимости, длительность и версию Claude Code.

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

Теперь докажите, что тест способен упасть. Временно замените описание навыка release-notes расплывчатым текстом, в котором больше не названа задача, распознаваемая этим навыком. Сам eval-кейс не меняйте. Снова запустите ту же команду, изучите новый отчёт, а затем верните настоящее описание.

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

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

Рассчитайте бюджет цикла до добавления новых кейсов

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

Для трёх разных решений нужны три разных бюджета:

Цикл с одним запуском заведомо шумный. Он годится для выявления очевидных ошибок при редактировании, но перед принятием изменения проведите подтверждение на трёх запусках по умолчанию. Для частых проверок предпочитайте regex, tool_used, tool_order и file_exists: они не требуют дополнительных обращений к модели-судье. Оставьте LLM-грейдер для короткого результата, качество которого нельзя выразить устойчивым правилом.

У лимита стоимости есть важная оговорка. --max-cost-usd перед началом каждого запуска сверяется с оценкой CLI по прейскуранту. Уже выполняющиеся запуски завершаются, поэтому итоговая оценка может превысить потолок. При достижении лимита остаются частичные результаты, а процесс завершается с кодом 2. Это ограничитель, а не предоплаченный кошелёк.

Передайте проверку на регрессию в CI

Когда намеренная регрессия проявилась, а восстановленный плагин снова проходит тест, перенесите этот же набор в систему контроля версий. В примере CI от Anthropic зафиксированы модели агента и судьи, результат записывается в results.json, задан порог 0.8, отчёт остаётся локальным, а потолок оценочной стоимости составляет $20. Там также используется --trust-plugin, что уместно лишь в том случае, если извлечённые из репозитория плагин и набор тестов вы готовы запустить самостоятельно.

Точная команда для передачи проверки: claude plugin eval . --trust-plugin --json results.json --threshold 0.8 --model claude-sonnet-5 --judge-model claude-haiku-4-5 --no-publish --max-cost-usd 20. Добавьте её в задачу после установки и авторизации Claude Code, а затем архивируйте два файла с результатами.

Кода завершения команды достаточно, чтобы поставить гейт на сборку. Код 0 означает, что все кейсы загрузились и достигли порога. Код 1 охватывает результат ниже порога и ряд ошибок настройки. Код 2 означает частичный запуск из-за потолка расходов или отклонения учётных данных в самом начале. Архивируйте results.json и report.html даже при сбое, чтобы автор мог отличить регрессию плагина от тайм-аута запуска или остановки по бюджету.

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

Семь типов поведения плагина, которые стоит проверить первыми

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

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

Два продукта, которые стоит построить вокруг нативных eval-тестов плагинов

1. Гейт по дельте для pull request — самая сильная возможность

Можно создать тонкий CI-продукт, который запускает нативную команду, читает aggregate-result.json и публикует единый результат ревью с изменением балла, дельтой, стоимостью, непройденным грейдером и ссылками на архивный отчёт. Команды плагинов и авторы решений для маркетплейсов готовы платить за слой принятия решений, а не за ещё один оценщик.

Спрос пока только формируется, но коммерческий сигнал уже заметен. Запрос claude code evals набирает около 50 поисков в месяц в США, его годовой рост составляет 600%, а CPC — $17.61. Более широкие платформы оценки тоже показывают наличие бюджетов на качество: месячный тариф Braintrust Pro стоит $249. Это ориентир по категории, а не рекомендация цены для обёртки над плагинами.

Минимальная продаваемая версия — GitHub Action и комментарий к PR. Она принимает путь к плагину, порог, зафиксированные модели и потолок оценочной стоимости; загружает нативные JSON и HTML; различает код выхода 1 и частичный выход 2. Но есть платформенный риск: Anthropic может добавить собственную отчётность для PR. Устойчивое преимущество здесь создают единые политики для нескольких репозиториев, исторические сравнения и правила согласования, а не более красивая копия нативного отчёта.

2. Подборки eval-кейсов для авторов навыков

Можно продавать поддерживаемые наборы кейсов для типовых задач плагинов: ревью кода, подготовка changelog, разбор инцидентов и безопасный выбор инструментов. Такой набор представляет собой обычный каталог evals/ с реалистичными положительными и отрицательными промптами и детерминированными грейдерами. Команда сможет адаптировать его, вместо того чтобы придумывать критерии качества с нуля.

Прямой запрос claude code skill evals получает около 10 поисков в месяц в США. Это очень мало, поэтому речь скорее о точечном дополнении, чем о самостоятельном венчурном рынке. MVP — один безупречный набор для одной ценной категории плагинов, версии которого синхронизируются с выпусками Claude Code; к нему прилагается краткое руководство по калибровке. Ограничение столь же очевидно: claude plugin eval init уже предлагает и пробно запускает кейсы. Наборы выиграют лишь тогда, когда их отраслевые сценарии и критерии сбоя окажутся лучше универсальной генерации.

Чего эта команда не решает

Нативные eval-тесты не доказывают, что плагин хорош при любых условиях. Они показывают его поведение только на выбранных вами промптах, в заданном окружении, с выбранной моделью, заданными разрешениями на инструменты и конкретными грейдерами. Слабые промпты дают лестные оценки. Регулярное выражение может засчитать правильный заголовок при неверном содержании. Оценки LLM-судьи могут варьироваться, а сам судья добавляет три голоса на каждый грейдер в каждом запуске.

Изоляция — ещё одно полезное ограничение. Каждый запуск начинается с чистого окружения, поэтому проектные файлы, пользовательские настройки, хуки и персональные серверы отсутствуют. Это отлично для воспроизводимости, но плохо для кейса, автор которого забыл объявить фикстуры. Инструментам за пределами набора только для чтения требуется явное разрешение в командной строке. Настоящие MCP-серверы плагина требуют дополнительного согласия и разрешений, а хуки и реальные серверы стоит запускать в изолированном раннере, поскольку они могут действовать за пределами песочницы агента.

Наконец, не урезайте max_turns или timeout_seconds до уровня, при котором нормальная работа начинает упираться в лимит. Запуск, превысивший время или число ходов, фиксируется как ошибка и обычно снижает балл. Оставьте достаточно места для целевой задачи, а общие расходы набора контролируйте потолком оценочной стоимости.

В понедельник одному автору плагина стоит добавить один кейс на срабатывание, намеренно заставить его упасть, восстановить плагин и поставить на эту же проверку лимит в CI. Если такой релизный контур нужен всем плагинам вашей команды, я помогу спроектировать production-гейт.