Всем привет! Меня зовут Костя, я QA-инженер в Банки.ру. Общение с агентом у меня давно стало обыденным делом. И в какой-то момент я заметил, что работа тестировщика превратилась в ежедневное объяснение ему одного и того же: «прочти задачу и проанализируй», «составь критерии приёмки и выдели, что регрессить», «сделай короткий баг-репорт», «сделай отчёт о тестировании за сегодня». И ещё десяток просьб, которые давно стали рутиной.

Сначала под каждую задачу у меня был свой промпт. Но копировать промпты из заметок, когда есть скиллы, — уже какой-то архаизм. Недолго думая, я взял скилл для поиска скиллов — find-skills. QA-скиллы в каталоге есть, например qa-test-planner, но в основном про автотесты и тест-планы в общем виде. Под ручное и backend-тестирование на моём стеке я не нашёл ничего.

А стек такой: Jira и Confluence для анализа задачи, Bitbucket для кода, Bamboo для раскатки на стенд, Kibana, OpenSearch и Jaeger для логов и трейсов, Allure TestOps для тестовых артефактов.

Цель я поставил такую: перестать объяснять агенту одно и то же, каждое такое действие завернуть в скилл, а каждую ошибку агента — в правило внутри скилла. Собирать скиллы помогает официальный скилл Anthropic skill-creator, в Claude Code это /skill-creator. Он расспрашивает, что должен делать скилл, пишет черновик, гоняет на нём тестовые запросы и правит по результатам.

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

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

Почему скилл, а не CLAUDE.md

Можно сложить знания в CLAUDE.md, только он грузится в каждую сессию целиком. Если задача мелкая, в сессию незачем тащить порядок деплоя и состав полей тест-кейса в Allure. Скилл подгружается по делу: в Claude Code агенту сразу видны только имена и описания скиллов, а всю «начинку» скилла он читает, когда запрос подходит под триггерные фразы из описания. Попросил оформить баг — подтянулся скилл баг-репорта, попросил раскатить задачу — скилл деплоя. Вот как устроен скилл баг-репорта:

skills/bug-report/
├── SKILL.md                  ← когда применять, порядок, правила, пример
├── references/
│   ├── developer-formats.md  ← развёрнутые форматы для разработчика
│   ├── neuro-critic.md       ← проверка текста перед отправкой
│   └── project-config.md     ← что настроить под свой проект
└── scripts/
    └── trace_warnings.py     ← разбор WARN/ERROR в трейсе Jaeger

Jira этому скиллу не нужна. Он берёт то, что уже собрано в сессии: ответы API, traceId, куски логов, мои заметки, — и сводит в короткий понятный баг-репорт. Отправить его в Jira — отдельный шаг: агент делает это через MCP-сервер или REST и только после моего «да». Так устроены многие скиллы: скилл задаёт порядок работы и формат результата, а доступ к системам дают MCP-серверы. Они не конкурируют, я пользуюсь и тем, и другим.

Как в скилле появляется правило

Скилл не учится сам, правила в него дописываю я. Цикл простой:

  1. Ловлю вывод агента, который не сходится с реальностью.

  2. Разбираю, какой проверки ему не хватило.

  3. Записываю правило в скилл — коротко, с историей, откуда оно взялось.

  4. В следующей сессии агент проверяет себя по этому правилу до того, как что-то утверждать.

Так выглядит одно из 19 правил в скилле тестирования задачи — дословно:

6. Перед выводом BUG прочитай требование (спеку или код). Наблюдаемое поведение не баг, пока не доказано расхождение с требованием. Порядок: факт → требование → расхождение → BUG.
Урок: деактивацию старой записи при совпадающей дате назвали BUG, не прочитав сервис, где это правило явно описано.

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

Почему не дать агенту записывать уроки самому? В англоязычных наборах популярен паттерн self-improving agent, где агент сам собирает уроки из сессий и повышает их до правил. Так быстрее, но агент, который сам себе пишет правила, может закрепить и неверный вывод. Об этом есть исследование с говорящим названием «Practice Makes Unsafe: Skill Misevolution in Self-Improving LLM Agents». Поэтому правило у меня появляется только после разбора человеком.

Человек в этой схеме — необходимое звено. Скиллы забирают рутину: собрать контекст, выкатить сервисы, поднять моки, оформить текст разрабу так, чтобы он не обиделся и не спросил: «Зачем ты кинул мне этот нейрослоп?!». Решать, что проверять и баг ли это, остаётся мне.

Чего агент не сделает без меня

Первое, что спрашивают про агента с доступом к стенду: не наломает ли он дров. Ограничения зашиты в сами скиллы:

  • работает только на тестовых стендах, прод-логи читает, только если я попрошу;

  • не деплоит на prod и stable: перед каждым деплоем скилл сверяет имя окружения со списком запрещённых. Права в Bamboo это не заменяет, но от случайной команды защищает;

  • данные на стенде меняет только по согласованному плану и потом откатывает;

  • ничего не публикует в Jira и Allure без моего «да».

Сам агент работает на Claude по корпоративной подписке компании.

Одна задача через весь конвейер

Возьмём вымышленную задачу PROJ-123: «при отмене оплаченного заказа возвращать деньги». Так она проходит через скиллы. На каждом этапе — что я говорю агенту, что делает скилл, где нужно моё «да» и какое правило там выросло.

1. Критерии приёмки — acceptance-criteria

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

Говорю агенту: «Составь критерии приёмки к PROJ-123 и выдели, что регрессить». Скрипт скилла собирает описание задачи, комментарии, страницы Confluence и изменения кода по всем PR. Агент раскладывает критерии в таблицу и, когда я скажу «да», оставляет её комментарием в задаче:

№

Тип

Критерий

Чем докажем

1 ⭐

HP

Отмена оплаченного заказа → заказ отменён, создан возврат

Запрос в базу до и после

2 ⭐

HP

Событие об отмене обработано без ошибок

Трейс

3

EC

Повторная отмена → ошибка, второй возврат не создаётся

Ответ API и запрос в базу

4

EC

Платёжный шлюз ответил 500 → заказ остаётся оплаченным, есть повторная попытка

Трейс

HP — то, что написано в задаче, EC — пограничные случаи, которые додумал QA, звёздочка — проверить ещё и на проде. Как мы готовим критерии с агентом, подробнее рассказывала моя коллега.

Правило, которое здесь выросло: искать в изменениях кода места, которые выглядят безобидно, а на стенде ломаются. Например, брокер сообщений ответил «доставлено» — это значит только, что сообщение попало в очередь. Обработал ли его получатель, отсюда не видно, и это отдельная строка в критериях.

2. Раскатка на стенд — bamboo-deploy

Критерии готовы — задачу нужно выкатить на стенд. Руками один-два сервиса — не проблема: зашёл в Bamboo, создал релиз, катнул. Но бывают задачи на десять сервисов, и для четырёх из них нужна отдельная ветка с настройками. Тут уже запара.

Говорю агенту: «Раскати PROJ-123 на стенд 2». Скилл находит все сервисы задачи, создаёт релизы в Bamboo и выкатывает их параллельно. Я подтверждаю дважды: сначала список релизов, потом список деплоев.

Вывод bamboo-deploy

Правило: деплой однажды упал с сообщением «приложение не запустилось». Агент полез в логи приложения, а упала на самом деле миграция базы — она пишет в лог то же самое. Теперь перед деплоем скилл проверяет миграции, а при падении первым делом смотрит их.

3. Заглушка партнёра — wiremock-stubs

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

Говорю агенту: «Сделай мок платёжного шлюза, чтобы возврат отвечал 500». Скилл достаёт из кода сервиса адреса, которые нужно застабить, создаёт заглушку в WireMock и по журналу запросов проверяет, что сервис ходит в мок, а не в реальный шлюз. Если партнёр сам шлёт нам ответ обратным запросом, мок не поможет — тогда скилл выдаёт готовый запрос, и партнёра играешь сам.

Вывод wiremock-stubs

Правило: русские буквы, отправленные через curl из Git Bash на Windows, приходят на сервер испорченными. Так я однажды потерял названия заглушек. Теперь такие запросы агент шлёт только через Python.

4. План и прогон — qa-task-testing

С этого скилла всё и началось, он самый большой в наборе. Стенд готов, говорю агенту: «Протестируй PROJ-123». Он читает задачу, спеку и изменения кода и прежде всего присылает план:

Вывод qa-task-testing: план прогона

Пока я не написал «go», агент только читает. По плану сразу видно, на каких данных агент собирается работать и что будет считать успехом.

После «go» агент гоняет проверки по плану. У каждой проверки есть доказательство: ответ API, запрос в базу или трейс, а где его нет, вывод помечается как гипотеза. Всё, что агент создал на стенде, он после прогона удаляет и показывает, что стенд вернулся в исходное состояние.

Вывод qa-task-testing после прогона

Правила, которые здесь выросли:

  • Данные — только из базы. Однажды агент написал два тест-кейса на заявках, которых на стенде не было. Теперь каждая строка плана опирается на реальную запись, найденную запросом.

  • Негативная проверка засчитывается, только если рядом прошла позитивная. Агент отправил неправильный запрос и получил ошибку — это ещё ничего не доказывает: может, запрос упал бы и с правильными данными. В плане выше это строки 1 и 3.

  • Сказать «этого нет» сложнее, чем «это есть». Однажды агент уверенно заявил, что нужного метода в коде нет. Метод был, просто в ветке задачи, а агент смотрел основную ветку. Чтобы сказать «нет», надо проверить все ветки и все PR.

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

5. Логи — opensearch-logs

Вторая проверка из плана упала: повторная отмена заказа создала второй возврат. Говорю агенту: «Найди ошибку в логах по traceId». Скилл находит записи в Kibana и сверяет их с трейсом в Jaeger. Если Kibana недоступна, агент заходит в OpenSearch через браузер с помощью agent-browser. Пароль от корпоративного входа хранится в agent-browser, агент его не видит.

Вывод opensearch-logs

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

6. Баг-репорт — bug-report

Второй возврат при повторной отмене — это баг. Говорю: «Сделай короткий баг-репорт». Скилл собирает всё, что уже есть в сессии: шаги из плана, ответ API, трейс и записи из логов. Получается два слоя: четыре строки для аналитика без кода и трейсов, а ниже — полный репорт для разработчика.

Вывод bug-report

Правило: баг подаётся вместе с масштабом. Агент любит раздувать находки: нашёл настоящий дефект и сразу пишет «критично». Поэтому в первом слое есть строка «Масштаб и что делать»: сколько реальных данных или пользователей это задевает сейчас. Бывает, что баг настоящий, а затронутых данных ноль, как в примере: функция на проде ещё выключена. Тогда это спокойный фикс до релиза.

7. Тест-кейсы — allure-testops-cases

Раньше тест-кейсы генерировал n8n-бот из моей прошлой статьи. Его работу я перенёс в скилл ради качества: бот знал только задачу и документацию и выдавал сырую пачку кейсов. А к этому моменту в сессии уже есть план и проведённые проверки, их осталось занести в Allure. Достаточно сказать «заведи тест-кейсы» — по таким фразам скилл включается сам — и он разложит проверки по кейсам: шаги, данные, ожидаемый результат, связь с задачей. Кейсы описывают то, что реально проверили, поэтому получаются точнее. До создания я их ревьюю и оставляю главное, а в Allure они попадают только после «да, создавай».

Вывод allure-testops-cases

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

8. Отчёт — test-session-report

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

Вывод test-session-report

Что забрать к себе, даже если стек другой

Ловушки конкретных инструментов — Bamboo, Allure, Kibana — пригодятся, только если стек совпадает с моим. Остальные правила от стека не зависят:

  • план до любой проверки на стенде и «go» от человека;

  • публикация в трекер и TMS — только после «да»;

  • за собой агент убирает и доказывает, что стенд чистый;

  • негатив — только в паре с позитивом;

  • «этого нет» требует больше доказательств, чем «это есть»;

  • баг — вместе с масштабом;

  • вывод без доказательства помечается как гипотеза.

С чего начать

1. Поставьте баг-репорт — ему не нужны ни токены, ни доступы:

npx skills add KonstantinVCH/QA-agent-skills --skill bug-report

Или вручную: скопируйте папку skills/bug-report из репозитория в ~/.claude/skills/.

2. Прогоните его на старом баге. В Claude Code опишите находку своими словами:

Оформи баг: при повторной отмене оплаченного заказа создаётся второй возврат.
Вот ответ API и traceId: ...

Агент вернёт баг в два слоя: четыре строки для аналитика и полный репорт для разработчика.

3. Добавьте test-session-report — ему тоже не нужны доступы.

4. Когда понравится, ставьте весь набор: npx skills add KonstantinVCH/QA-agent-skills. Задайте JIRA_URL, JIRA_TOKEN, CONFLUENCE_URL, CONFLUENCE_TOKEN, BITBUCKET_URL, BITBUCKET_TOKEN и заполните references/project-config.md в нужных скиллах. Остальные переменные — для Bamboo, Allure, Jaeger, OpenSearch и WireMock — перечислены в README.

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

Как раздать скиллы команде

Дописал правило в скилл — оно должно дойти до всей команды без напоминаний в чате. Для этого наш командный репозиторий собран как маркетплейс плагинов Claude Code. Плагины в нём по ролям: для QA, аналитиков, разработчиков и общий. Каждый ставит свои, а обновления приходят сами.

Скиллы командного маркетплейса в настройках Claude

Публичный репозиторий тоже ставится плагином:

/plugin marketplace add KonstantinVCH/QA-agent-skills
/plugin install qa-skills@qa-agent-skills

У сторонних маркетплейсов автообновление выключено, каждый включает его сам: /plugin → Marketplaces → маркетплейс → Enable auto-update.

Для своего маркетплейса хватит файла .claude-plugin/marketplace.json в репозитории, пошагово это описано в документации Anthropic. Главная ловушка — поле version. Не указывайте его: тогда версией считается коммит, и каждый пуш доходит до команды. С "version": "1.0.0" все останутся на старой копии, пока вы не смените номер.

Репозиторий: github.com/KonstantinVCH/QA-agent-skills. Если попробуете — расскажите, что сломалось, это станет следующим правилом. А в комментариях поделитесь, на какие грабли наступал ваш агент.

Спасибо, что прочитали! Буду рад пообщаться в комментариях.