skills-qe: как заставить агента доказывать качество

Лена — тест-лид в команде из четырёх человек: они делают сервис бронирования переговорок. На прошлой неделе ей выдали Claude Code и сказали: «пусть агент пишет тесты». В первый же день агент отчитался: «Готово, все тесты проходят». В CI горели семь красных.

Лена не стала спорить с агентом — она поставила ему рамки. Рамки называются @dzhechkov/skills-qe: курируемый пакет из 22 навыков качества для агентов Claude Code. Навык (skill) — это файл SKILL.md с инструкцией и триггерными фразами; агент подгружает его сам, когда задача совпадает с триггером.

Откуда взялись 22:

• 20 навыков — из платформы agentic-qe версии 3.10.3: генерация тестов, анализ покрытия, гейты качества, хаос-тесты, пять QCSD-роёв и другие;
• 2 навыка дисциплины — validate и systematic-debugging из obra/superpowers: они не про инструменты, а про честность — «нет свидетельства — нет слова «готово»».

Пакет опубликован: страница @dzhechkov/skills-qe на npmjs.com, исходники — в репозитории dz-harness на GitHub. Это курируемое подмножество: полный agentic-qe — 94 навыка, 55 агентов, MCP-сервер и память; здесь оставлены 22, которые нужны команде вроде Лениной каждый день.

Компромисс: подмножество лёгкое и ставится одной командой, но в нём нет MCP-сервера и памяти полной платформы; за «полной мощью» — npm install -g agentic-qe && aqe init --auto.

🗣 Скажи агенту. Навыки этого пакета не запускают руками — их включает сама задача. Лена пишет: «дай этому коду беспощадное ревью» — и агент подгружает brutal-honesty-review. Всё, что дальше в курсе, работает так же: ты называешь намерение, агент подбирает навык.

Хватит истории — Лена открыла терминал, открой и ты.

Пакет ставится через dz — пакетный менеджер навыков из @dzhechkov/harness-cli. Три способа, от рекомендуемого к точечному:

1. Пресетом — dz init --target claude-code --preset qe-engineer. Пресет — готовый набор навыков под роль; qe-engineer разворачивает 22 навыка этого пакета под Claude Code.
2. С самообучением — dz setup --target claude-code --preset qe-engineer: та же установка, плюс самообучение агента на его прогонах.
3. Напрямую — dz install @dzhechkov/skills-qe: сам пакет, без пресета.

Как убедиться, что навыки действительно легли:

• dz info validate — покажет триггеры и файлы конкретного навыка;
• dz registry search coverage — найдёт навык по слову.

Грабли Лены — не повторяй: она запустила dz init в домашней папке, а не в папке проекта. Навыки раскладываются относительно текущей директории — сначала cd в проект, потом установка.

Компромисс: пресет ставит всё разом — быстро, но в списке появятся навыки, которые тебе пока не нужны (например, qe-browser, если браузерных тестов у тебя нет); точечный dz install чище, но требует знать имя пакета.

🗣 Скажи агенту. «Поставь пакет навыков качества skills-qe в этот проект» — агент сам выполнит dz init --target claude-code --preset qe-engineer. Лена за первую неделю набрала руками только cd.

Лена спросила: «А как агент понимает, какой из 22 навыков брать?» Ответ — в шапке каждого SKILL.md.

У каждого навыка есть поле description с триггерными фразами: описанием ситуаций, в которых навык нужен. Агент сравнивает твою задачу с этими описаниями и подгружает совпавший навык сам — ты не пишешь /qe-test-generation, ты просто говоришь, чего хочешь. Это и есть автоактивация.

Примеры из README пакета:

• «Сгенерируй тесты для этого модуля» → qe-test-generation;
• «Дай этому коду беспощадное ревью» → brutal-honesty-review;
• «Оцени пробелы в покрытии тестами» → qe-coverage-analysis.

А теперь угадай, прежде чем читать дальше: какой навык включится на фразу «предыдущий фикс не помог, ошибка вернулась»? Запомни ответ — проверим в упражнении.

Два инструмента, чтобы не гадать:

• dz info <skill-id> — точные триггеры и файлы навыка;
• dz registry search <слово> — поиск навыка по слову.

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

🗣 Скажи агенту. Лена завела одну привычку: если навык не включился — она пересказывает задачу словами из его description. «Ошибка вернулась после фикса» → systematic-debugging включается стабильно.

Вернёмся к первому дню Лены: «Готово, все тесты проходят» — и семь красных в CI. Навык validate существует ровно для этого случая.

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

Функция-гейт из пяти шагов, которую агент обязан пройти ДО слова «готово»:

1. Определи — какая команда доказывает утверждение?
2. Запусти — полностью, заново.
3. Прочитай — весь вывод, код выхода, число падений.
4. Сверь — подтверждает ли вывод утверждение? Нет — назови реальное состояние.
5. Только теперь — заявляй, и вместе со свидетельством.

Пропуск любого шага = непроверенное заявление. Таблица навыка бьёт по самым частым подменам: «тесты проходят» требует вывода с 0 падений; «баг починен» — проверки, что исходный симптом исчез; «регрессионный тест работает» — цикла красный → фикс → зелёный.

Красные флаги, на которых навык велит остановиться: «должно», «вероятно», «похоже»; «Отлично!» до проверки; доверие отчёту субагента без независимой сверки.

После собственных проверок навык требует независимых валидаторов-субагентов: один на маленькую правку, два на многофайловую, три на архитектурную. Они только читают и сообщают, не чинят; максимум два раунда.

Компромисс: каждая проверка стоит времени и токенов, зато «готово» снова значит «готово». Лена посчитала: семь красных в CI обошлись команде дороже, чем все прогоны validate за месяц.

🗣 Скажи агенту. «Перед тем как сказать «готово», покажи свежий вывод тестов» — и validate включится. Его триггер — сама попытка агента сказать «готово», «починено», «все тесты проходят».

На третий день агент Лены починил падающий тест — и сломал два соседних. Потом «починил» ещё раз. Классический симптомный фикс: правят там, где видна ошибка, а не там, где она рождается.

systematic-debugging ставит второй Железный закон: *никаких фиксов без расследования корневой причины*. Пока первая фаза не завершена, предлагать фикс нельзя.

Фазы навыка (в заголовке их четыре, плюс пятая — перекрёстная проверка):

1. Расследование корневой причины — прочитать ошибку целиком; воспроизвести (живое воспроизведение — curl, браузер, REPL — ценнее чтения кода); проверить недавние изменения; протрассировать данные через все слои и назад — до места, где плохое значение родилось.
2. Анализ образцов — найти похожий работающий код и выписать КАЖДОЕ отличие, даже «незначительное».
3. Гипотеза и проверка — одна гипотеза («причина X, потому что Y»), одно минимальное изменение, одна переменная за раз.
4. Реализация — сначала падающий тест, потом ОДИН фикс без «заодно», потом проверка. Не сработало — откатить, не наслаивать. Три неудачи подряд — стоп и разговор об архитектуре.
5. Перекрёстная проверка субагентами — от одного до трёх валидаторов по размеру задачи, только чтение, максимум два раунда.

Фразы, на которых навык велит вернуться в первую фазу: «быстрый фикс сейчас, разберёмся потом», «попробую поменять X и посмотрю», «ещё одна попытка» после двух провалов.

Компромисс: расследование кажется медленнее, чем «попробовать», но навык настаивает: системный путь быстрее метаний, потому что не плодит новых багов. Цена — дисциплина: агенту придётся объяснять, почему он всё ещё не чинит.

🗣 Скажи агенту. Лена пишет: «ошибка вернулась после фикса — сначала найди корневую причину, фикс не предлагай». systematic-debugging включается, а когда фикс лёг, его подхватывает validate.

Теперь — к инструментам. Первое, о чём Лена попросила агента: «напиши тесты для UserService». Навык qe-test-generation делает это по анализу кода: ветки, пути ошибок, граничные случаи, а не только счастливый путь.

Быстрый старт из навыка:

• один файл: aqe test generate --file src/services/UserService.ts --framework jest;
• каталог с целью по покрытию: aqe test generate --scope src/api/ --coverage 90 --type unit;
• интеграционные: aqe test generate --file src/controllers/AuthController.ts --type integration.

Три стратегии внутри: по анализу кода (методы, ветки, зависимости, пути ошибок), по образцу (--pattern repository для слоя репозиториев) и по пробелам покрытия (читает lcov.info и добивает до цели).

Грабли, записанные в самом навыке — Лена наступила на два из четырёх:

1. Агент обрезает вывод на файлах длиннее 3000 строк — генерируй по модулям, не по каталогам.
2. Компоненты проходят юнит-тесты по одному и никак не связаны между собой — минимум один интеграционный тест на каждую границу модулей.
3. Проверь, какой фреймворк стоит (jest или vitest): у них разные API моков, и агент возьмёт не тот.
4. Театр завершения: агент заявляет «полный набор тестов сгенерирован», а внутри заглушки и зашитые значения — всегда запускай сгенерированные тесты.

Четвёртые грабли — тот самый первый день Лены.

Компромисс: генерация даёт десятки тестов за минуты, но не гарантирует их смысла; навык сам советует после генерации прогнать /mutation-testing и проверить, ловят ли тесты хоть что-то.

🗣 Скажи агенту. «Сгенерируй юнит-тесты для src/services/UserService.ts под vitest, затем запусти их и покажи вывод» — вторая половина фразы включает validate и закрывает четвёртые грабли.

Агент отчитался Лене: «покрытие 100 %». Она открыла тесты: сто процентов строк выполнены, ноль проверок (expect). Навык qe-coverage-analysis прямо записал это как типичный вывод агента: *высокое покрытие строк НЕ значит хорошие тесты*.

Что навык делает вместо одной средней цифры:

• aqe coverage analyze --source src/ --tests tests/ — покрытие по операторам, веткам и функциям;
• aqe coverage gaps --risk-weighted --threshold 80 — пробелы, взвешенные риском;
• aqe coverage diff --base main --head feature-branch — что изменилось между ветками.

Взвешивание риском — ключ. Пробел в покрытии оценивается не по числу строк, а по четырём факторам с весами из навыка: сложность кода (0.3, порог цикломатической сложности 10), частота изменений за 90 дней (0.25), история багов за 180 дней (0.25), критичность по меткам вроде payment и auth (0.2). Непокрытая функция в модуле оплаты весит больше, чем непокрытый геттер.

Гейты, которые навык предлагает для слияния: блокировать, если новый код покрыт меньше чем на 80 % или покрытие упало больше чем на 5 пунктов; предупреждать при общем покрытии ниже 75 %.

Спроси себя, прежде чем идти в упражнение: что для ТВОЕГО проекта «100 %» — цель или симптом? Лена ответила «симптом» и с тех пор смотрит на две цифры сразу: покрытие И мутационный счёт.

Компромисс: взвешивание требует истории (git, баг-трекер) — на свежем репозитории оно вырождается в обычное покрытие. И честная оговорка из навыка: домен анализа покрытия успешен в 86 % прогонов, 14 % падают на инициализации — держи запасной путь (обычный c8 или istanbul).

🗣 Скажи агенту. «Найди пробелы покрытия с учётом риска и предложи, какие тесты писать первыми» — qe-coverage-analysis включится и передаст список в qe-test-generation.

Пятница. Релиз. Лена спрашивает агента: «Можно катить?» — и хочет не мнение, а вердикт. Навык qe-quality-assessment отвечает именно вердиктом: pass / fail / warn по каждому гейту и общей оценкой от A до F.

Команды:

• aqe quality assess --scope src/ --gates all — прогнать все гейты;
• aqe quality deploy-ready --environment production — готовность к выкладке;
• aqe quality compare --from v1.0 --to v2.0 — сравнить два релиза.

Гейт качества — это порог плюс флаг «блокирующий». В примере навыка: покрытие ≥ 80 (блокирует), уязвимости critical/high = 0 (блокирует), сложность ≤ 15 (предупреждает), дублирование ≤ 3 % (предупреждает). Провал блокирующего гейта = block-merge.

Общая оценка складывается из пяти частей с весами: покрытие тестами 0.25, безопасность 0.25, качество кода 0.20, надёжность (плотность багов, нестабильные тесты) 0.20, документация 0.10. Шкала: A — 90–100, B — 80–89, C — 70–79, D — 60–69, F — ниже 60.

Сноска, которую навык выделяет как главную — и она про первый день Лены: никогда не доверяй pass/fail, о котором отчитался агент. В истории навыка записано 12 падений тестов, которые агенты объявили пройденными. Вердикт читается из вывода команды, не из слов.

Второй совет из навыка: чини находки волнами по приоритету — P0, затем P1, затем P2 — с проверкой между волнами, а не всё сразу.

Компромисс: гейты дают воспроизводимое «да/нет», но пороги надо настраивать под проект — чужие пороги дают чужие вердикты. И честно: домен оценки качества успешен в 53.7 % прогонов — ожидай сбоев и держи ручной путь (aqe health, при необходимости aqe init).

🗣 Скажи агенту. «Оцени готовность к релизу по всем гейтам и дай вердикт с цифрами из вывода» — включится qe-quality-assessment; слова «с цифрами из вывода» включат и validate.

Тесты красные, а Лена уходит на встречу. Что агент может сделать без неё — и не наврать? Навык qe-iterative-loop — адаптация техники «Ralph Wiggum» под инженерию качества: агент крутит петлю «запустил → починил → перезапустил», пока измеримая цель не достигнута.

Почему именно QE подходит для петель: критерии успеха объективны. Тесты — код выхода 0 или нет; покрытие — 78.5 % против цели 80; гейт — pass или fail. Агент точно знает, когда он закончил.

Пять образцов петли, каждый со своим промисом — маркером завершения, который агент обязан вывести:

1. Починка тестов → <promise>TESTS_GREEN</promise>;
2. Покрытие до цели → COVERAGE_MET;
3. Соответствие гейтам → QUALITY_GATES_PASSED;
4. Стабилизация нестабильных тестов (пять прогонов подряд) → TESTS_STABLE;
5. Согласование контрактов API → CONTRACTS_VALID.

Петля починки в деталях: прогнать весь набор → разобрать ПЕРВОЕ падение (упал код или тест?) → починить → перезапустить только упавший файл → если прошёл, весь набор → зелёный — промис, нет — следующее падение.

Предохранители из навыка: не больше 30 итераций; после 10 — отчёт об оставшемся; один и тот же тест упал 5 раз — стоп, вероятно, дело в дизайне.

Компромисс: петля экономит часы человеческого внимания, но промис — это слово агента, а не свидетельство; Лена после каждой петли всё равно смотрит вывод последнего прогона (тот самый validate).

🗣 Скажи агенту. /qe-loop "Запусти npm test и почини все падающие тесты. Успех: npm test завершается с кодом 0. Выведи <promise>TESTS_GREEN</promise>, когда всё зелёное."

Лена попросила: «дай беспощадное ревью». Агент включил brutal-honesty-review — и первым делом спросил согласия. Это не вежливость, это контракт навыка: «Я дам нефильтрованную техническую обратную связь. Цель — ясность, не жестокость».

У навыка три режима — три голоса:

• Linus — код технически неверен: «ты держишь соединение с базой на время HTTP-вызова; под нагрузкой пул кончится за секунды»;
• Ramsay — качество ниже очевидной планки: «15 тестов, 14 — счастливый путь; где проверки ошибок?»;
• Bach — детектор чепухи: сертификаты, «лучшие практики», обещания вендора — «кому это на самом деле выгодно?».

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

Структура любого вывода фиксирована: что сломано → почему это неверно → как выглядит правильно → как починить → почему это важно. И правило, которое навык повторяет дважды: бей по работе, не по работнику.

Когда навык применять НЕЛЬЗЯ — вопрос на суждение, не на память: первый PR джуна, деморализованная команда, публичный форум. Реши сам, прежде чем идти в квиз: ревью для нового стажёра — Linus или мягкий code-review-quality?

Два предохранителя от пустого ревью:

1. Минимум три взвешенных находки (CRITICAL = 3, HIGH = 2, MEDIUM = 1, LOW = 0.5); нашёл меньше — копай глубже или объясни с доказательствами, почему.
2. Квитанции роя: когда ревьюеры работают параллельно, каждый обязан оставить файл со Status: completed или Status: failed. Ревьюер, который ничего не вернул, ничего и не проверял — а выглядит точно так же, как тот, кто ещё работает. Без всех квитанций вердикт не собирается.

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

🗣 Скажи агенту. «Ревью в режиме Ramsay: только качество тестов, минимум три находки с весом» — Лена формулирует так, чтобы режим и планка были заданы, а не угаданы.

Планирование спринта. Эпик — «онлайн-оплата брони». Лена просит агента: «дай тест-идеи по этому эпику» — включается sfdipot-product-factors, навык по факторам продукта из HTSM Джеймса Баха.

SFDIPOT — семь вопросов, которые задают продукту по очереди, чтобы ни одна сторона не осталась без тест-идей:

• Structure — что продукт ЕСТЬ? (компоненты, код, зависимости)
• Function — что он ДЕЛАЕТ? (функции, расчёты, ошибки, безопасность)
• Data — что он ОБРАБАТЫВАЕТ? (ввод, вывод, хранение, границы)
• Interfaces — как он СОЕДИНЯЕТСЯ? (UI, API, интеграции, CLI)
• Platform — от чего ЗАВИСИТ? (ОС, браузер, железо, сеть)
• Operations — как его ИСПОЛЬЗУЮТ? (обычно, экстремально, админ, восстановление)
• Time — КОГДА что происходит? (параллельность, расписание, последовательности)

Для эпика Лены фактор Time дал самую дорогую идею: «два пользователя одновременно бронируют одну переговорку и платят — наблюдай разрешение конфликта». Без седьмого вопроса эту идею никто не записал бы.

Правила качества идей из навыка:

1. Никаких «Verify X» — только глаголы действия: не «проверить, что логин работает», а «отправить учётные данные; подтвердить, что сессия создана».
2. Распределение приоритетов: P0 — 8–12 % (безопасность, потеря данных, регуляторика), P1 — 20–30 %, P2 — 35–45 %, P3 — 20–30 %.
3. Ручное исследование ≥ 10 % — не всё автоматизируется, и навык требует оставить долю для человека.

Работают два агента: qe-product-factors-assessor делает оценку, qe-test-idea-rewriter переписывает «Verify»-идеи в действия.

Компромисс: семь факторов дают широту, но не глубину — идея «наблюдай разрешение конфликта» ещё не тест; и в навыке заведомо больше идей, чем команда успеет сделать, поэтому распределение приоритетов — не формальность, а способ выбросить лишнее.

🗣 Скажи агенту. «Разбери эпик по SFDIPOT: тест-идеи с глаголами действия, приоритеты P0–P3, уточняющие вопросы по пробелам» — Лена получает таблицу, а не эссе.

Ретро после релиза. Один говорит «всё отлично», другой — «мы чуть не уронили прод», третий молчит. Лена просит агента провести обсуждение по six-thinking-hats — методу шести шляп де Боно, адаптированному навыком под тестирование.

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

Быстрая ротация из навыка — 30 минут:

1. 🤍 Белая (5 мин) — только факты: метрики, покрытие, число тестов;
2. ❤️ Красная (3 мин) — чувства без обоснования: что тревожит, где уверенность;
3. 🖤 Чёрная (7 мин) — риски, пробелы, что может сломаться;
4. 💛 Жёлтая (5 мин) — что работает, быстрые победы;
5. 💚 Зелёная (7 мин) — идеи и альтернативы;
6. 🔵 Синяя (3 мин) — план действий с владельцами.

Пример из навыка для стратегии тестирования API: белая — 47 эндпоинтов, покрытие 30 %; красная — тревога за безопасность; чёрная — нет тестов авторизации, лимиты не проверены; жёлтая — хорошие доки, CI на месте; зелёная — контрактные тесты, хаос; синяя — сначала безопасность, контракты в следующем спринте.

В командной сессии на 60 минут — по 10 минут на шляпу, синяя подводит итог.

В упражнении ты — ведущий: тебе решать, какую шляпу надеть на каждую реплику. Готового ответа в навыке нет — есть только правило «одна перспектива за раз».

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

🗣 Скажи агенту. «Проведи анализ падений релиза по шести шляпам, по 5 минут на шляпу, закончи планом с владельцами» — Лена получает шесть коротких блоков и список действий.

Месяц спустя Лена больше не спорит с агентом о том, прошли ли тесты. Теперь она ведёт весь цикл — и для этого в пакете есть пять роёв QCSD (Quality Criteria for Software Development — «критерии качества на протяжении разработки»). Рой (swarm) — это навык, который запускает нескольких специализированных агентов параллельно и сводит их выводы в один вердикт.

Пять фаз, у каждой — свой рой и свой трёхзначный вердикт:

1. Ideation — qcsd-ideation-swarm, планирование PI/спринта: GO / CONDITIONAL / NO-GO. Критерии качества по HTSM, штурм рисков, тестируемость. Первый гейт цикла.
2. Refinement — qcsd-refinement-swarm, уточнение историй: READY / CONDITIONAL / NOT-READY. SFDIPOT, BDD-сценарии, проверка требований.
3. Development — qcsd-development-swarm, во время спринта: SHIP / CONDITIONAL / HOLD. TDD, сложность, пробелы покрытия, предсказание дефектов.
4. Verification — qcsd-cicd-swarm, перед релизом: RELEASE / REMEDIATE / BLOCK. Гейты CI/CD, регрессия, нестабильные тесты. Вопрос фазы: не «достаточно ли качество кода?», а «безопасно ли это выпускать?».
5. Production — qcsd-production-swarm, после релиза: HEALTHY / DEGRADED / CRITICAL. DORA-метрики, анализ первопричин, предсказание дефектов — и единственная фаза с двойной ответственностью: оценить прод И вернуть уроки назад в Ideation и Refinement.

Правила исполнения, общие для роёв (у каждого — своя таблица E1–E8): запускать ВСЕХ трёх основных агентов, без исключений; все параллельные вызовы — в одном сообщении; после каждой партии — остановиться и дождаться; не подменять агентов собственным пересказом; не сокращать отчёт «для краткости».

Компромисс: рой даёт независимые перспективы и воспроизводимый вердикт, но стоит дорого (оценка токенов у одного роя — 3500, у Production — 32 000) и требует строгого следования шагам: рой, в котором агент «сэкономил» одного специалиста, выносит вердикт без доказательств.

🗣 Скажи агенту. «Проведи QCSD-оценку готовности релиза по артефактам CI: вердикт RELEASE / REMEDIATE / BLOCK с отчётом» — включится qcsd-cicd-swarm. Лена начинала с одного навыка validate; закончила циклом из пяти роёв. Твоя очередь.