Тестирование скиллов Claude Code: eval-driven подход

Разработчик пишет скилл для Claude Code. Markdown-файл с YAML-frontmatter, двести строк инструкций, поле description на полтора абзаца. Скилл запускается, делает что-то похожее на ожидаемое, разработчик коммитит. Через неделю Anthropic обновляет модель, и скилл перестаёт триггериться на те запросы, которые работали ещё вчера. Или начинает триггериться на всём подряд. Или триггерится правильно, но генерирует ответ, который не имеет отношения к инструкциям.

Это не гипотетическая ситуация. В марте-апреле 2026 года три изменения на продуктовом слое Claude Code наложились друг на друга незаметно: понижение уровня рассуждений, ошибка кэширования, ограничение многословности вывода. Шесть недель качество агента деградировало, при этом прямой доступ к API работал штатно. Anthropic позже подтвердила и разобрала все три причины в официальном постмортеме от 23 апреля 2026 года, а независимый аудит 6852 сессий, проведённый Стеллой Лауренцо (Senior Director of AI, AMD), показал: отношение «чтений к правкам» рухнуло на 70% (с 6,6 до 2,0 прочтений на одну правку), глубина рассуждений упала на 67%, расходы на API взлетели со $12 до $1 504 в день. Ни один юнит-тест это не поймал, потому что юнит-тест тестирует детерминированный код, а скилл Claude Code, наоборот, — вероятностная инструкция для языковой модели.

Тестирование скиллов, хуков и плагинов — это отдельная инженерная дисциплина, которая к весне 2026 года уже обзавелась методологией и инструментами. Эта статья описывает текущую ситуацию с тестированием скиллов и плагинов Claude Code: что даёт Anthropic из коробки, что построило сообщество, какие подходы работают, а какие выглядят убедительно только на слайдах.

Что вообще нужно тестировать

Какие свойства у скилла, хука и плагина подлежат проверке? Вопрос не тривиальный: классическая модель «вход → обработка → выход» работает только для нижнего слоя стека.

Скилл проверяется по двум ортогональным осям. Первая ось — это триггер: активируется ли скилл на правильных запросах и молчит ли на нерелевантных? Вторая — это качество: если скилл активировался, делает ли он то, что предполагается дизайном? Эти оси полностью независимы. Скилл может идеально триггериться, но выдавать мусор. Или давать блестящие результаты, когда его вызывают руками, но не активироваться автоматически ни на одном реальном запросе. Тестировать нужно обе оси, и инструменты для них разные.

Хук проверяется просто: это детерминированная команда с контрактом на коды возврата. Код 0 означает успех, код 2 — блокировку, любой другой ненулевой код — это просто предупреждение без последствий. Здесь работает классическое тестирование: подать JSON на stdin, проверить код возврата, проверить stdout/stderr. Подвох в другом: хук встроен в цикл обратной связи с моделью, и тестировать нужно не только сам скрипт, но и то, как модель реагирует на его вывод.

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

MCP-сервер является внешним процессом с типизированным протоколом. Тестируется ближе всего к классическим API-тестам: валидация схемы, обработка ошибок, конкурентные запросы. Но добавляется специфика: MCP-сервер работает не с HTTP-клиентом, а с языковой моделью, которая интерпретирует ответы нечётко.

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

Eval-Driven Development: TDD для вероятностного мира

В феврале 2026 года на хакатоне Cerebral Valley × Anthropic («Built with Opus 4.6», 10–16 февраля) был создан проект Everything Claude Code, включивший методологию Eval-Driven Development (EDD). EDD сформулировал Grey Newell, ML-инженер, опубликовавший десять принципов на evaldriven.org, главный из которых: «Фокус должен сместиться с того, что мы можем построить, на то, что мы можем доказать».

EDD — это TDD, адаптированный для недетерминированных систем. В классическом TDD тест имеет бинарный результат: прошёл или упал. В EDD тест задаёт порог на распределении: «скилл должен корректно триггериться в 90% случаев из eval-набора» или «качество ответа выше 4 из 5 по оценочной шкале в 80% запусков». Вместо единичного ассерта идёт статистика по множеству прогонов.

Три ключевые метрики, которые EDD привнёс в тестирование скиллов:

pass@k — вероятность получить хотя бы один успешный результат за k попыток. Если доля успеха за одну попытку — 75%, то pass@10 приближается к 100%. Метрика отвечает на вопрос: «Можно ли добиться результата, если дать агенту несколько попыток?»

pass^k — вероятность того, что все k попыток окажутся успешными. При тех же 75% за попытку pass^3 составляет всего 42%. Метрика отвечает на вопрос: «Можно ли на это положиться?» Разница между pass@k и pass^k — это разница между демонстрацией и продакшеном.

Cost-Normalized Accuracy (CNA) — результат, делённый на потраченные токены. Скилл, добивающийся 95% качества за $0,50 за сессию, бьёт скилл с 97% качества за $5,00 — если разница в точности не критична для задачи.

Anthropic поддержал методологию на уровне документации. Каноничный пост «Demystifying Evals for AI Agents» рекомендует начинать с 20–50 задач из реальных сбоев, разделять оценщиков на кодовые (детерминированные), модельные (LLM-судья) и человеческие (экспертная оценка), и строить два типа eval-наборов: eval-ы возможностей (что агент может) и регрессионные eval-ы (что агент всё ещё может после обновления).

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

Арсенал Anthropic

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

Валидация плагинов

claude plugin validate ./my-plugin проверяет манифест, frontmatter скиллов и агентов, синтаксис hooks.json. Флаг --strict превращает предупреждения в ошибки — рекомендован для CI. Это структурная проверка: «плагин собран правильно», не «плагин работает правильно». Аналог tsc --noEmit — полезно, но недостаточно.

Параллельно существует проект сообщества Claude Plugins Validation (CPV): 20 специализированных валидаторов, 190 правил, 2 336 тестовых кейсов, нулевой расход токенов. Ловит пять классов тихих сбоев, которые claude plugin validate пропускает. Запускается через uvx без установки. Удобно для CI.

Разработка и отладка

--plugin-dir ./my-plugin загружает плагин из локальной директории без установки. /reload-plugins перезагружает все компоненты без перезапуска сессии. --debug показывает, какие плагины загрузились и какие компоненты обнаружены. --plugin-url загружает плагин из удалённого .zip — для CI-артефактов. Локальная копия имеет приоритет над установленным плагином из маркетплейса с тем же именем.

Anthropic также поставляет плагин plugin-dev в репозитории anthropics/claude-code, у него два ключевых компонента. Первый, hook-development skill, даёт утилиты для прямого тестирования хук-скриптов: validate-hook-schema.sh, test-hook.sh, hook-linter.sh. Второй, plugin-validator agent, выполняет десятишаговую валидацию: от структуры манифеста до проверок безопасности (жёстко прописанные секреты, принудительный HTTPS).

Skill-Creator 2.0

Самый полный официальный инструмент для тестирования скиллов — Skill-Creator, обновлённый в марте 2026 до версии 2.0 с четырьмя ключевыми возможностями: Eval, Improve, Benchmark и A/B-тестирование.

Eval-режим прогоняет скилл через тестовые промпты и оценивает результат по заданным критериям с помощью параллельных независимых агентов. A/B-тестирование использует отдельного Comparator-агента, который оценивает выходы вслепую, получая два ответа без пометок, какой от какой версии. Improve итеративно переписывает описание скилла на основе выявленных провалов, а Benchmark перезапускает eval-ы после обновления модели или правок скилла для ловли регрессий.

Отдельный конвейер оптимизирует описание скилла — то самое поле description, от которого зависит автоматическая активация. Генерируется 20 триггерных eval-запросов (10 должны срабатывать, 10 — нет), запускается итеративная оптимизация с разбиением 60/40 на обучающую/тестовую выборки для защиты от переобучения. По данным Anthropic, оптимизация улучшила триггеринг у 5 из 6 публичных скиллов.

agentskills.io

Открытый стандарт, принятый более чем тридцатью продуктами (Cursor, Codex CLI, Gemini CLI, GitHub Copilot, VS Code и другие), включает утилиту skills-ref validate для структурной валидации frontmatter и соглашений об именовании. Реализации есть на Python, Go и Rust. Но есть принципиальное ограничение: стандарт не включает ни соглашений об eval-ах, ни формата тестовых кейсов, ни стандартов бенчмарков. Поведенческое тестирование оставлено за пределами спецификации.

Тестирование триггеров: первый приоритет

Если скилл не триггерится на правильных запросах, eval-ы качества бессмысленны, их просто некому запускать. Поэтому тестирование триггеров — это первое, что нужно покрывать.

Механика триггера: Claude видит только описания скиллов (суммарно description + when_to_use, обрезанные до 1 536 символов), сопоставляет их с запросом пользователя и решает, какой скилл подгрузить. Решение принимает модель, и это источник проблем.

Формат eval-набора

Стандартный формат — eval-set.json, массив объектов с тремя полями:

[
  {"query": "Спроектируй card component для музыкального приложения", "should_trigger": true, "note": "UI design task"},
  {"query": "Исправь ошибку синтаксиса Python", "should_trigger": false, "note": "Не относится к UI"}
]

Каждый запрос прогоняется через Claude 3+ раза, чтобы учесть недетерминированность; результат — trigger rate, который показывает долю успешных активаций от общего числа прогонов. Скрипт run_eval.py от Anthropic из репозитория anthropics/skills автоматизирует процесс.

Автоматическая оптимизация описаний

run_loop.py --eval-set triggers.json --skill-path ./my-skill --max-iterations 5 --holdout 0.4 запускает итеративный цикл: Claude анализирует провалы, переписывает описание, чтобы «обобщить на более широкие категории пользовательских намерений», проверяет на отложенном наборе. В одном документированном кейсе trigger rate вырос с 9/13 до 5/5 на отложенных тестах.

Подводные камни

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

Изолированный eval: 100% точность за $5,59

Практик из сообщества продемонстрировал подход на изолированных песочницах Daytona: claude -p "$QUERY" --output-format stream-json --max-turns 1 --allowedTools Skill с двадцатисекундным таймаутом. Парсинг JSONL-потока на события tool_use типа Skill(). Два варианта проверки: LLM-eval дал 100% активаций, но лишь 20% истинно отрицательных. Forced-eval hook (UserPromptSubmit хук, заставляющий Claude оценить каждый скилл перед действием) дал 100% точность по обоим направлениям. Стоимость ~250 вызовов: $5,59.

Eval-ы качества: действительно ли скилл делает то, что обещает

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

Три измерения качества

Philipp Schmid предложил оценивать качество по трём измерениям:

Функциональная корректность: код компилируется, API отвечает, результат действительно решает задачу.
Соответствие стилю: результат следует конвенциям и директивам скилла.
Эффективность: расход токенов, число повторов, итоговая стоимость.

На практике для одного скилла достаточно 10–20 тестовых кейсов с явными критериями успеха, положительными и отрицательными примерами; каждый прогоняют по 3–5 раз, чтобы учесть разброс ответов.

Promptfoo как рабочая лошадка

Promptfoo, CLI с открытым исходным кодом для eval-ов промптов, приобретённый OpenAI в марте 2026, стал де-факто стандартом для eval-ов качества скиллов. YAML-конфигурация, поддержка нескольких провайдеров, набор типов проверок: contains-json для структурной проверки, JavaScript-выражения для собственной логики, cost и latency для бюджетных ограничений, llm-rubric для семантической оценки, trajectory:step-count для проверки пути выполнения.

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

MLflow: трассировка вместо проверки ответа

MLflow предложил другой подход: проверять не итоговый ответ, а «трассу выполнения», пошаговую запись того, что агент реально делал, где каждый вызов инструмента сохраняется как отдельное событие. Команда mlflow autolog claude /path/to/project фиксирует «не то, что Claude сказал, что сделал, а то, что он сделал на самом деле». Получившиеся трассы проверяют «автоматические оценщики» двух видов: на базе LLM они анализируют поведение и порядок шагов, на жёстких правилах выполняют детерминированные проверки созданных файлов. Трассы с ошибками система автоматически возвращает в Claude Code, чтобы он сам починил скилл.

Слепое пятно: LLM пишет проверки на своё поведение

Критическое предупреждение из исследования ICST 2025 (Konstantinou et al.): когда LLM пишет проверки для тестового набора, эти проверки отражают текущее, возможно, ошибочное, поведение, а не желаемое. Ошибки фиксируются как «ожидаемые». Человек должен валидировать эталонные регрессионные наборы. Это прямой аналог проблемы «snapshot-тесты, которые всегда обновляются» в классической разработке — только здесь обновление происходит неявно, внутри головы модели.

Тестирование хуков: детерминизм с подвохом

Хуки — единственный слой расширения, тестируемый почти классически. Shell-скрипт получает JSON на stdin, возвращает код возврата и опционально JSON на stdout. Детерминированная логика, чётко определённый контракт.

Базовый паттерн

echo '{"tool_input":{"command":"git commit -m test"}}' | bash your-hook.sh
echo $?  # 0=allow, 2=block

Валидация JSON-выхода:

output=$(./your-hook.sh < test-input.json)
echo "$output" | jq .

Критическая ошибка: код 1 вместо кода 2

Самая частая ошибка в тестах хуков: разработчик пишет хук безопасности, проверяет, что «код выхода ненулевой», и считает, что хук блокирует действие. На самом деле код 1, как и любой ненулевой кроме 2, — лишь предупреждение, которое ничего не блокирует. Сообщение об ошибке покажется в стенограмме сессии, но действие всё равно выполнится: запрет есть, а последствий нет — чистая иллюзия безопасности. Блокирует только код 2: он отменяет вызов инструмента на этапе PreToolUse и отклоняет запрос пользователя на этапе UserPromptSubmit. Поэтому проверять нужно именно код 2, а не «любой ненулевой».

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

Петля обратной связи «хук — модель»

Хук в изоляции — лишь половина картины. Вторая половина — то, как модель реагирует на вывод хука. Когда PreToolUse-хук блокирует действие (exit 2), stderr возвращается Claude как сообщение об ошибке, и модель корректирует план. Когда PostToolUse-хук сообщает об ошибке линтера через additionalContext, модель исправляет код в следующем действии без вмешательства пользователя.

Тестирование полного цикла: хук срабатывает → модель получает обратную связь → модель корректирует поведение → скорректированное действие проходит хук. Это уже не юнит-тест хука, а интеграционный тест петли обратной связи. Инструментарий для такого тестирования на май 2026 года — ручной: запустить сессию, спровоцировать блокировку, проверить, что модель адаптировалась. Автоматизация есть только в зачаточном состоянии — через MLflow-трассировку и хуки наблюдаемости.

Валидация плагинов: три уровня уверенности

Плагин — это контейнер, и его тестирование складывается из тестирования содержимого плюс проверки упаковки.

Уровень 1: Структурная валидация

claude plugin validate --strict проверяет формат манифеста, YAML-frontmatter скиллов и агентов, JSON-схему хуков. Альтернатива от сообщества CPV добавляет 190 правил и ловит пять классов тихих сбоев, которые claude plugin validate пропускает. Несколько характерных примеров.

Поле agents с путями к папкам — агенты молча выпадают на этапе выполнения.
Каскад hooks — переопределение авто-обнаруженного файла вызывает ошибку «Duplicate hooks file detected» и отключает MCP-серверы.
Коллизии имён MCP- и LSP-серверов между источниками — одно имя тихо подменяет другое.
Избыточное указание mcpServers.

CI-интеграция тривиальна:

steps:
  - run: claude plugin validate ./my-plugin --strict

Уровень 2: Тестирование компонентов

Каждый компонент плагина тестируется отдельно: скиллы через триггерные eval-ы и eval-ы качества, хуки через подаваемый на вход JSON и проверки кода возврата, MCP-серверы через MCP Inspector и юнит-тесты, агенты через ручной вызов. Порядок: структура → триггеры → качество → хуки → интеграция.

Уровень 3: Интеграционное тестирование

Полный тест плагина в рабочей среде. claude --plugin-dir ./my-plugin загружает плагин, headless-режим (claude -p "задача") прогоняет сценарий, парсер JSONL-вывода проверяет вызовы инструментов и результат. Это самый дорогой уровень: каждый прогон стоит API-токенов.

cc-plugin-eval — фреймворк сообщества, специально построенный для этого: четыре стадии (Анализ → Генерация → Выполнение → Оценка), пакетирование сессий со сбросами /clear между прогонами (снижает накладные расходы на ~80%), программная детекция + LLM-оценка.

MCP-серверы: ближе всего к классическому тестированию

MCP-серверы — единственный слой, который тестируется почти как обычный API. Три уровня:

Юнит-тесты — привязка в памяти без подпроцессов. FastMCP Client для Python, @modelcontextprotocol/sdk для TypeScript. Прямой вызов tool-функций, проверка ответов.

async def test_tool_execution(mcp_server):
    async with Client(mcp_server) as client:
        result = await client.call_tool("calculate", {"x": 5, "y": 3})
        assert result[0].text == "8"

Интеграционные тесты — соответствие протоколу, целостность рабочего процесса, устойчивость к ошибкам. MCP Inspector (npx @modelcontextprotocol/inspector) — официальный инструмент: браузерный интерфейс для ручного тестирования, CLI-режим для автоматизации.

E2E-тесты — имитация реального MCP-клиента. Стресс-тест из 5 000 вызовов с заведомо нарушенной схемой дал ноль успешных выполнений при включённой валидации — типизированный контракт действительно работает как заявлено.

Песочница и изоляция: три уровня безопасности

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

Уровень 1: Git Worktrees — самая лёгкая изоляция. Каждый тест получает собственное рабочее дерево на отдельной ветке. Фреймворк Sandcastle оборачивает это в Docker-контейнер с автоматическим обратным слиянием. Цена: минимальные накладные расходы, но нет сетевой изоляции.

Уровень 2: Docker-контейнеры — Docker Sandboxes даёт microVM-окружение с отдельным Docker-демоном и файловой системой на каждую песочницу. Три режима сетевой политики: Open, Balanced, Locked Down. Поддерживает Claude Code, Codex CLI, Gemini CLI, GitHub Copilot CLI.

Уровень 3: MicroVMs — максимальная изоляция. Firecracker загружается за ~125 мс с накладными расходами менее 5 MiB, поддерживает до 150 VM/секунду/хост. gVisor перехватывает системные вызовы в пользовательском пространстве с 10–30% накладных расходов на ввод-вывод. Стандартные Docker-контейнеры разделяют ядро хоста, для тестирования недоверенного кода агента этого недостаточно.

Регрессионное тестирование: находить поломки до пользователя

Мартовско-апрельский инцидент 2026 года показал, что изменения на продуктовом слое способны «молча» деградировать качество агента, а юнит-тесты бессильны. Нужны специфические сигналы.

Опережающие индикаторы

Отношение чтений к правкам, то есть число прочтений файла на одну правку, упало на 70% во время инцидента. Это метрика «тщательности» агента: когда модель начинает править файлы, не читая их, качество падает.

Глубина рассуждений, то есть объём генерируемых рассуждений, упала на 67%. Измеряется через --output-format stream-json и анализ thinking-блоков в JSONL.

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

Преждевременная победа: агент врёт, что закончил

Отдельная и недооценённая проблема: агент систематически объявляет задачу выполненной раньше, чем она действительно готова. Исследование Walking Labs зафиксировало три точки потери информации: реализация (спецификация → код), тестирование (неполное покрытие), верификация (пропуск интеграционных и E2E-проверок).

Паттерн решения: отделить «работника» от «проверяющего». Один агент реализует задачу, а независимый её верифицирует. Данные показательны: один агент — это 20 минут, $9 и неработающая функциональность. Три агента (планировщик + генератор + оценщик) — это 6 часов, $200 и полностью работающий результат. Независимый проверяющий не видит контекст реализации и не заражается «настроем преждевременной победы», не верит на слово, что «всё работает», а проверяет сам.

Skill-Creator 2.0 от Anthropic встроил этот принцип через Comparator-агента: получает два выхода «без указания, какой от какой конфигурации» (слепое сравнение). Skills 2.0 добавляет ещё один механизм: определяет, когда базовая модель проходит eval-ы без загруженного скилла, сигнализируя, что скилл устарел и его можно списать — паттерн, который в сообществе называют «outgrowth detection».

Запись и воспроизведение: воспроизводимость для недетерминированного мира

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

Архитектура Sakura Sky предлагает решение из семи примитивов:
— структурированная трасса выполнения (append-only JSONL),
— стабильные метаданные (идентификатор модели, параметры декодирования, версии инструментов),
— движок воспроизведения (доступ к событиям по курсору),
— детерминированные заглушки (ReplayLLMClient подставляет записанные ответы),
— детерминированная обвязка (запись/воспроизведение без изменений кода),
— интеграция управления (журналы аудита, аварийные выключатели),
— регрессионное тестирование (исторические трассы как эталонные файлы).

На практике всё это пока остаётся на уровне экспериментов — готового инструмента воспроизведения промышленного уровня не существует. Ближе всего к нему подошли два инструмента. Promptfoo с флагом --repeat 3 повторяет один и тот же запрос и так проверяет стабильность ответа. Codex CLI с флагом --json записывает события сессии в формате JSONL. Но и это не настоящее воспроизведение, а лишь повторный прогон того же промпта — восстановить конкретную прошлую сессию по шагам они не умеют.

Тестирование с учётом стоимости: не сжечь бюджет на проверки

Тестирование скиллов стоит денег: каждый прогон через Claude API потребляет токены. При pass@1 50% для надёжной оценки нужны сотни прогонов. Стратегии оптимизации:

Маршрутизация моделей по уровням тестов. Смоук-тесты и юнит-тесты — на дешёвых моделях (Claude Haiku, DeepSeek V3.2 по $0,14/MTok). Интеграционные — на моделях среднего уровня (GPT-4.1-mini). Полные eval-ы агента — на боевой модели только для финальной валидации.

AgentAssay (arXiv 2603.02601) показал 78–100% снижение стоимости через три механизма: адаптивная оптимизация бюджета (калибровка числа прогонов по дисперсии поведения, до 4–7x сокращения для стабильных агентов), офлайн-анализ по трассам (бесплатное тестирование на записанных трассах), последовательное тестирование SPRT (снижение числа прогонов до 78%).

Promptfoo поддерживает проверки стоимости:

- type: cost
  threshold: 0.50

Skills 2.0 Outgrowth Detection — ещё один механизм экономии: если базовая модель проходит eval-ы без скилла, скилл больше не нужен и его можно деактивировать, сэкономив токены на загрузке описания в каждой сессии.

Ландшафт зрелости: что работает, а что нет

К маю 2026 года ландшафт тестирования скиллов и плагинов Claude Code неоднородный. Одни слои покрыты хорошо, другие почти никак.

Высокая зрелость: структурная валидация плагинов (claude plugin validate --strict + CPV), eval-ы качества скиллов (Promptfoo + Skill-Creator 2.0), триггерные eval-ы (eval-set.json + run_eval.py + оптимизатор описаний), MCP-серверы (MCP Inspector + фреймворки юнит-тестов).

Средняя зрелость: тестирование хуков (утилиты plugin-dev + ручная проверка кодов возврата), EDD/eval-as-CI (методология описана, инструментарий есть, внедрение раннее), E2E-тестирование (headless-режим + трассы MLflow + cc-plugin-eval), детекция преждевременной победы (слепое A/B в Skill-Creator 2.0).

Низкая зрелость: тестирование субагентов (ни одного специализированного фреймворка), тестирование автономных циклов (AgentAssay академический, Ralph Loop экспериментальный), детерминированный replay (Sakura Sky — архитектура без промышленного инструмента), кросс-сессионная регрессия (нет встроенного механизма для обнаружения, что обновление модели сломало скиллы), тестирование безопасности скиллов (SkillSieve — академический, 0,800 F1 на размеченном бенчмарке из ~400 скиллов, отобранных из корпуса в 49 592 реальных ClawHub-скилла).

Открытые вопросы

Пять проблем, которые никто публично не закрыл.

allowed-tools не контролируется во время выполнения. Поле в frontmatter скилла парсится, но не ограничивает доступ к инструментам. GitHub-issue #37683 закрыт как «not planned», исправление не планируется. Скиллы, полагающиеся на allowed-tools для безопасности, не защищены.

Стандарт без eval-формата. agentskills.io — открытый стандарт для скиллов, принятый более чем тридцатью продуктами, — не включает ни соглашений об eval-ах, ни формата тестовых кейсов, ни стандартов бенчмарков. Каждый инструмент изобретает свой формат: у Promptfoo это YAML, у Skill-Creator JSON, у TribeAI Python-фикстуры, у MLflow трассы. Портирование eval-наборов между инструментами остаётся ручной работой.

Разрыв 37% между лабораторией и продакшеном. CLEAR Framework (arXiv 2511.14136) показал 37% среднюю разницу между результатами бенчмарков и реальной производительностью. Производительность агента падает с 60% (одиночный прогон) до 25% (согласованность по 8 прогонам). Бенчмарки переоценивают надёжность, а большинство eval-конвейеров строится именно на бенчмарк-подобных тестах.

Нет обнаружения циклов в хуках. Если хук A создаёт условие для срабатывания хука B, который создаёт условие для A — ничто в архитектуре Claude Code не остановит замыкание. Документация рекомендует «не создавать циклы», но это совет, не принуждение. В сложных конфигурациях с плагинными хуками поверх пользовательских отладка циклов превращается в отдельное приключение.

Нет переносимости eval-ов между вендорами. Скилл Claude Code не запустится в Cursor без переписывания. Eval-набор для Claude Code скилла бесполезен для тестирования портированного Cursor-скилла, потому что механизмы триггеров, frontmatter и среда выполнения отличаются. Тестировать приходится на каждой платформе отдельно.

Реалистичные перспективы

Тестирование скиллов и плагинов — молодая дисциплина, ещё не перешедшая из категории «энтузиасты и ранние последователи» в «стандартную инженерную практику». Несколько вещей выглядят вероятными на горизонте года.

EDD закрепится как рекомендованная методология. Anthropic уже продвигает eval-ориентированный подход через документацию и Skill-Creator 2.0. Сообщество воспроизводит. Вопрос — в скорости внедрения: большинство разработчиков скиллов сегодня тестируют вручную.

agentskills.io добавит eval-секцию. Естественное расширение: стандарт описывает структуру скилла, но не его тестирование. Предложение уже обсуждается. Если реализуется — eval-наборы станут портируемыми между Claude Code, Cursor и Codex CLI.

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

Первый инцидент в цепочке поставок через плагин — вопрос месяцев. Ни один вендор не аудирует содержимое плагинов при установке. claude plugin validate проверяет структуру, не поведение. SkillSieve (академический, 0,800 F1) — одна из самых заметных попыток автоматической детекции вредоносных скиллов, и она далека от продакшена. Когда инцидент произойдёт, появится давление на тестирование безопасности.

Инструментарий консолидируется вокруг двух-трёх инструментов. Сейчас ландшафт фрагментирован: Promptfoo, DeepEval, Braintrust, LangSmith, TribeAI, cc-plugin-eval, MLflow, ECC — десяток инструментов с перекрывающейся функциональностью. Через год выживут два-три, остальные будут поглощены или маргинализированы. Promptfoo (при поддержке OpenAI) и LangSmith (при поддержке экосистемы LangChain) — наиболее вероятные победители.

Тестирование скиллов и плагинов Claude Code в мае 2026 года — это зрелая методология (EDD), растущий инструментарий и значительные дыры в покрытии. Кто строит серьёзные плагины — вкладывает в eval-конвейер. Кто пишет скилл на вечер — тестирует вручную и, скорее всего, продолжит. Разрыв между этими двумя группами — карта, по которой будет двигаться вся дисциплина.

Статья основана на материалах документации Claude Code, Anthropic engineering blog, официальных репозиториев anthropics/claude-code и anthropics/skills, исследований ArXiv (CLEAR Framework, AgentAssay, VeriGrey, SkillSieve), проектов сообщества Promptfoo, TribeAI/claude-evals, cc-plugin-eval, MLflow, Everything Claude Code, публикаций evaldriven.org, philschmid.de, mager.co, Walking Labs и независимых практиков. Контекст по архитектуре скиллов и плагинов — из каноничных статей проекта (апрель 2026).