Репозиторий на GitHub

ПЛАГИН ДЛЯ CLAUDE CODE · ОНБОРДИНГ

qa-pilot

Скиллы для Claude Code: QA-план задачи, анализ покрытия, аудит требований и тестов, написание тестов.

3 команды

1100+ правил QA

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

ПРАВИЛА · ТЕСТЫ

Четыре правила для тестов

Тест должен доказать, что умеет падать

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

Убирает тесты, которые проходят при любом поведении.

Ожидаемый результат — с источником

Источник — строка спеки или AC, решение проекта, инвариант из базы или конвенция в другом месте кода. Проверяемый код источником не бывает. Нет источника — вопрос владельцу, а не тест.

Убирает тесты, которые закрепляют баг как норму.

UI-тест проверяет то, что видит пользователь

Удалили — строки нет в списке. Сохранили — значение на месте после перезагрузки. Статус ответа проверяется только в дополнение. Исключения (у действия нет следа в UI, API-тест) помечаются в тесте с причиной.

Убирает зелёный тест при ответе 200 и неизменившемся экране.

«Покрыто» — это три ссылки

Тест по файлу и строке, проверка именно этого условия, слой тестов запускается в CI. «Не покрыто» тоже доказывается: прикладывается поиск и число совпадений.

Убирает «всё покрыто» на слово.

ПРАВИЛА · РАБОТА В ПРОЕКТЕ

Как плагин работает в репозитории

Требования проверяются до кода

Если test вызван до разработки: тестируемость AC, согласованность с кодом и соседними спеками, неописанные состояния сущностей.

Спрашивает, а не угадывает

Недостающее — одним списком вопросов. Без ответа — в раздел «Open gaps», зависимая работа помечается заблокированной.

Правила проекта главнее правил плагина

CLAUDE.md, AGENTS.md и конфиги репозитория перекрывают плагин. Конфликт отмечается в отчёте.

Границы автонаписания тестов

Без отдельного согласования — до 5 тестов и 1 e2e на задачу. Продуктовый код не меняется. Тест на баг остаётся красным. Удалить или ослабить тест решает владелец.

Ревью перед сдачей

Ревьюеры по узким аспектам: ложно-зелёные тесты, флаки, простота, конвенции. До 3 раундов, каждая находка сверяется с кодом.

Безопасность

Браузер запускается только на окружениях, отмеченных безопасными в профиле. Значения секретов не читаются.

ЧТО ЭТО

Плагин для Claude Code: набор QA-скиллов и база правил тестирования

Установка. Две команды в Claude Code. Менять что-либо в репозитории не нужно.

Контекст проекта. Стек, тестовые слои, команды и CI записываются в профиль один раз.

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

Состав. Три команды для пользователя, восемь внутренних скиллов, база из 1137 правил книги и 176 собственных, Python-скрипты проверок.

КАК УСТРОЕНО

Три команды

КомандаЧто делаетКогда вызывать
/qa-pilot:onboardСоздаёт профиль проекта: стек, тестовые слои, команды, CI, критичные флоу, окруженияОдин раз при подключении. Повторно — после смены фреймворка или структуры тестов
/qa-pilot:test [контекст]QA одной задачи: план до кода, проверка после кода, проверка в браузере, тесты по готовому плануНа каждую задачу: до начала разработки и после реализации
/qa-pilot:audit [контекст]Аудит всего проекта, требований одной фичи или кода тестов. Результат — список работ по приоритетуПри входе в проект, после большой фичи, перед релизом, при нестабильных тестах

Контекст — номер тикета, название фичи, URL или «в браузере». Без контекста режим определяется по ветке и диффу.

ОБЩАЯ СХЕМА

Когда какую команду вызывать

ВХОД В ПРОЕКТ · ОДИН РАЗ

Пришли на проект

onboard

audit

→ карта рисков и план: что чинить, что покрыть первым

КАЖДАЯ ЗАДАЧА

Тикет

test

QA-план

Пишете код

test

проверка + тесты

Мерж

ВРЕМЯ ОТ ВРЕМЕНИ

audit — после большой фичи или серии мелких изменений, перед релизом

test «в браузере» — пройти флоу руками, воспроизвести баг, проверить фикс

ШАГ 1 · КАК УСТРОЕН

/qa-pilot:onboard

1 · Сканирование, без вопросов

Читает манифесты, конфиги, CI-воркфлоу, CLAUDE.md и AGENTS.md, выборку тестов. Записывает команды тестов, линта и тайпчека; какие слои тестов запускает CI; как ошибки API доходят до UI; зрелость тестового фреймворка по 9 областям. Значения секретов не читаются.

2 · Вопросы, одним сообщением

Только то, чего нет в коде: безопасные и запрещённые окружения, источник тестовых учёток, трекер, 3–7 критичных флоу (плагин предлагает, человек подтверждает), черты продукта, противоречия из шага 1. Без ответа — в раздел «Open gaps».

3 · Профиль и где он используется

  • команды и CI-слои → запуск тестов, проверка «покрыто»
  • критичные флоу → P2 на них становится Must
  • черты продукта → отбор правил из базы
  • окружения → где разрешена проверка в браузере

4 · Проверки

Запуск самой дешёвой команды из профиля. Скрипт сверки профиля с репозиторием должен пройти без расхождений. Та же сверка выполняется перед каждым test и audit; при расхождении — список отличий и обновление только этих строк.

Результат: docs/qa/project-profile.md. Остальные команды читают его вместо сканирования репозитория.

ШАГ 2 · ВЫБОР РЕЖИМА И ПЛАН ДО КОДА

/qa-pilot:test

РЕЖИМ ПО СИГНАЛАМ: СЛОВА ПОСЛЕ КОМАНДЫ, ТИКЕТ, ДИФФ НА ВЕТКЕ, ФАЙЛ ПЛАНА

тикет, кода нет → план

есть дифф → проверка

«в браузере», URL → ручное исследование

путь к плану → написание тестов

«покрой» → тесты на готовый код

РЕЖИМ «ПЛАН» — ДО НАЧАЛА РАЗРАБОТКИ

1 · Область

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

2 · Проверка AC

Каждый критерий: проверяем ли, согласован ли с кодом, полон ли по обязательным веб-паттернам. Пробел → правка AC или вопрос.

3 · Карта влияния

Кто использует затронутый код: импорты, запросы, вызовы сервисов. Для каждой связи — файл, строка и ожидаемый эффект.

4 · Тест-дельта

Какие тесты поменять, новые тесты по корзинам Must / Should (до 5) / Highlight, регрессионный набор.

Результат: docs/qa/tasks/<тикет>.md. Бюджет — около 80 тыс. токенов. Перед запуском режим и причина выводятся одной строкой.

ШАГ 2 · ПРОВЕРКА ПОСЛЕ КОДА

/qa-pilot:test

1 · Сверка с планом

Каждый фрагмент диффа: запланирован, объяснимый рефакторинг или меняет поведение без плана. Невыполненные пункты плана — списком.

2 · Пересчёт влияния

Карта влияния строится заново по реальному диффу. Изменение там, где ждали «без изменений», → вопрос «это намеренно?» с доказательством.

3 · Покрытие

Для каждого Must и Should: тест, проверка именно этого условия, слой в CI. Прогон регрессии и новых тестов командами из профиля.

4 · Недостающие тесты

Пишутся в стиле проекта и проходят ревью. Тест на найденный баг остаётся красным и уходит владельцу вместе с багом.

ОГРАНИЧЕНИЯ ДЛЯ АВТОМАТИЧЕСКИХ ТЕСТОВ

Ожидаемый результат берётся из AC, спеки или решения — не из изменённого кода

Не больше 5 новых тестов и 1 e2e за задачу, остальное — списком владельцу

Продуктовый код не меняется

Результат: раздел «Verify log» в файле задачи и готовый блок для описания PR. Бюджет — около 100 тыс. токенов. Если план не делали, сначала строится его сжатая версия.

ШАГ 3 · КАК УСТРОЕН АУДИТ ПРОЕКТА

/qa-pilot:audit

Без контекста — весь проект, шаги 1–5. С фичей, спекой или тикетом — аудит требований этой фичи (шаг 3 на полной глубине). Со словом «тесты» — аудит кода тестов (шаг 4 по всему набору).

1 · Фундамент

Зрелость тестового фреймворка по 9 областям профиля. Блокеры (слой считается покрытием, но CI его не запускает; ложно-зелёные тесты) — первыми в Must.

2 · Критичные флоу

3–7 флоу из профиля. Пользователь подтверждает список и видит стоимость до запуска: около 150–250 тыс. токенов на флоу.

3 · Аудит флоу

Скрипт отбирает правила под черты продукта. Для каждой сущности — карточка «сущность × обязательный паттерн»: у каждой ячейки вердикт с доказательством, пустая ячейка блокирует отчёт.

4 · Код тестов

Тесты вокруг критичных флоу: ложная зелень, флаки, неверный уровень теста.

5 · Дорожная карта

Отчёт и список задач в JSON для агента-исполнителя. JSON проходит валидатор: ошибок должно быть 0.

НА ЧЁМ ОСНОВАНО · 1

Приоритет — по риску, а не по проценту покрытия

Приоритет находки определяется последствиями для продукта, а не формулировкой правила.

P1 — потеря данных, сломанная защита, нет проверки перед продом. Ставится, только если показано место в коде.

P2 — серьёзная дыра. P3 — косметика.

Must

P1, любой подтверждённый баг и P2 на критичном флоу. Делается всегда

Should

Остальные P2 — не больше 8, чтобы список можно было реально сделать

Highlight

Одна строка о риске, без теста — пока вы сами не решите его поднять

Риски, исключённые фильтрами проекта, перечисляются в отдельном разделе отчёта.

НА ЧЁМ ОСНОВАНО · 2

База знаний по тестированию

1300+

правил в базе знаний по тестированию

Тест-дизайн, требования, API, формы, доступность (WCAG 2.2), безопасность, локализация, производительность, мобильные платформы, UX, AI-фичи, качество тест-кода

Каждое правило сверено со стандартами

RFC, W3C, ISTQB, OWASP, NIST. У правила есть уровень авторитета — стандарт, практика индустрии, гайд вендора или мнение автора. Правило уровня «мнение автора» не может быть обязательным.

Расширено для продуктовых команд

Собственные домены qa-pilot: веб-паттерны поломок, безопасность (OWASP ASVS), HTTP API, аутентификация (NIST), стратегия тестирования, AI-фичи, качество тест-кода — и правила, выученные на реальных аудитах.

Отдельное спасибо Роману Суркову: базовый свод правил взят из его книги «Качество решает всё».

КОНТРОЛЬ · 1

Что проверяют скрипты

Модель

Суждение: что здесь может сломаться, какие сценарии важны, как сформулировать находку.

Скрипты без LLM

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

Вы

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

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

КОНТРОЛЬ · 2

Требования к доказательствам

«ПОКРЫТО» — ТОЛЬКО ПРИ ТРЁХ ДОКАЗАТЕЛЬСТВАХ

1

Есть тест — с точным файлом и строкой

2

Он ловит именно этот случай, а не соседний

3

Этот слой реально запускается в CI

«Теста нет» — только с приложенным поиском: команда и число совпадений

Умеет падать: новый тест проверяется на сломанном коде, существующие — пробой скрипта на выборке

Код тестов проходит ревью отдельными агентами, до 3 раундов; каждая находка сверяется с кодом

Баги в продукте не исправляются автоматически: передаются владельцу с шагами и ожидаемым поведением

КОНТРОЛЬ · 3

Ограничения

ОграничениеЧто это значит на практике
Сильнее всего на фронтенде и e2eНа чистом бэкенде работает, но опирается на конвенции проекта, а не на готовую библиотеку паттернов
Аудиты стоят токеновПорядка 150–250 тыс. на один флоу. Цену плагин называет заранее, флоу выбираете вы
Один репозиторий — один профильСвязи между репозиториями плагин не анализирует
Требует ответов на вопросыВ первую неделю нужно время на ответы: от них зависит точность профиля
Продуктовые решения — за командойПродуктовый код не меняется, приоритеты бизнеса не определяются

КОГДА ПОЛЕЗНО

Типовые сценарии и команды

Новый проект с существующими тестами

onboard → audit

Оценка тестового фреймворка, риски критичных флоу, порядок работ

Задача до начала разработки

test TICKET-123

Проверка AC, карта влияния, список тестов к добавлению

Задача после реализации

test

Сверка диффа с планом, недостающие тесты

Проверка спецификации

audit <фича>

Противоречия, неописанные состояния, вопросы к продукту

Нестабильные тесты

audit тесты

Ложно-зелёные и флаки-тесты, дубли, план рефакторинга

Ручная проверка в браузере

test в браузере

Прохождение флоу, баги с шагами воспроизведения, перепроверка фикса

КАК НАЧАТЬ

Установка

1 /plugin marketplace add grooownow/qa-pilot

2 /plugin install qa-pilot@qa-pilot

3 /qa-pilot:onboard

Нужно: Claude Code и Node.js. Работает на подписке Claude Pro.

Дальше: audit для общей картины, потом test на каждую задачу.

Подробнее: github.com/grooownow/qa-pilot

Открыть репозиторий на GitHub
Repository on GitHub

A CLAUDE CODE PLUGIN · ONBOARDING

qa-pilot

Skills for Claude Code: a QA plan per task, coverage analysis, requirement and test audits, test writing.

3 commands

1100+ QA rules

script checks

RULES · TESTS

Four rules for tests

A test must prove it can fail

New test: the agent breaks the code under test or the assertion, sees it fail, reverts; the main session spot-checks. Existing tests: the test audit breaks the code under a sample of tests with a script that restores the file itself.

Removes tests that pass whatever the code does.

Every expected result has a source

A source is a spec or AC line, a project decision, an invariant from the rule base, or a convention elsewhere in the code. The code under test is never a source. No source means a question for the owner, not a test.

Removes tests that lock in a bug as expected behaviour.

A UI test checks what the user sees

Deleted: the row is gone from the list. Saved: the value is there after a reload. A response status is checked only in addition. Exceptions (no trace in the UI, an API test) are marked in the test with the reason.

Removes the green test over a 200 response and an unchanged screen.

“Covered” means three references

A test by file and line, an assertion on this exact condition, a test layer that CI runs. “Not covered” is proven too: the search and its match count are attached.

Removes “it’s all covered” on trust.

RULES · WORKING IN A PROJECT

How the plugin works in your repo

Requirements are checked before code

When test runs before development: AC testability, consistency with the code and sibling specs, undefined entity states.

Asks instead of guessing

What is missing comes as one list of questions. Unanswered items go to “Open gaps”, and dependent work is marked blocked.

Project rules win over plugin rules

The repo’s CLAUDE.md, AGENTS.md and configs override the plugin. A conflict is noted in the report.

Limits on writing tests automatically

Without separate approval: up to 5 tests and 1 e2e per task. Product code is not changed. A bug test stays red. Deleting or weakening a test is the owner’s call.

Review before hand-off

Reviewers with narrow lenses: false greens, flakiness, simplicity, conventions. Up to 3 rounds; every finding is checked against the code.

Safety

The browser runs only on environments marked safe in the profile. Secret values are never read.

WHAT IT IS

A Claude Code plugin: a set of QA skills and a base of testing rules

Install. Two commands in Claude Code. Nothing in the repo needs to change.

Project context. The stack, test layers, commands and CI are written to a profile once.

Results. Plans, reports and tests are saved as files in the repo. Progress is written as work goes on, so an interrupted session can resume.

Contents. Three user commands, eight internal skills, a base of 1137 rules from the book plus 176 of its own, Python check scripts.

HOW IT WORKS

Three commands

CommandWhat it doesWhen to run it
/qa-pilot:onboardCreates the project profile: stack, test layers, commands, CI, critical flows, environmentsOnce, when you start. Again after a change of framework or test structure
/qa-pilot:test [context]QA for one task: a plan before code, verification after code, browser testing, tests from a ready planEvery task: before development starts and after it is done
/qa-pilot:audit [context]Audits the whole project, one feature’s requirements, or the test code. The result is a prioritised work listWhen joining a project, after a big feature, before a release, when tests are flaky

Context is a ticket number, a feature name, a URL or “in the browser”. Without context, the mode is chosen from the branch and the diff.

THE OVERALL LOOP

Which command to run when

JOINING A PROJECT · ONCE

You join a project

onboard

audit

→ a risk map and a plan: what to fix, what to cover first

EVERY TASK

Ticket

test

QA plan

You write code

test

verification + tests

Merge

FROM TIME TO TIME

audit — after a big feature or a series of small changes, before a release

test “in the browser” — walk a flow by hand, reproduce a bug, check a fix

STEP 1 · HOW IT WORKS

/qa-pilot:onboard

1 · Scan, no questions

Reads manifests, configs, CI workflows, CLAUDE.md and AGENTS.md, a sample of tests. Records the test, lint and typecheck commands; which test layers CI runs; how API errors reach the UI; test framework maturity in 9 areas. Secret values are not read.

2 · Questions, in one message

Only what the code can’t tell: safe and forbidden environments, where test accounts come from, the tracker, 3–7 critical flows (the plugin proposes, you confirm), product traits, contradictions from step 1. Unanswered items go to “Open gaps”.

3 · The profile and where it is used

  • commands and CI layers → running tests, the “covered” check
  • critical flows → a P2 on them becomes Must
  • product traits → which rules are picked from the base
  • environments → where browser testing is allowed

4 · Checks

Runs the cheapest command from the profile. The profile-vs-repo check script must pass with no drift. The same check runs before every test and audit; on drift you get the list and an update of just those lines.

Output: docs/qa/project-profile.md. The other commands read it instead of scanning the repo.

STEP 2 · CHOOSING THE MODE AND THE PLAN BEFORE CODE

/qa-pilot:test

MODE FROM SIGNALS: WORDS AFTER THE COMMAND, TICKET, BRANCH DIFF, PLAN FILE

ticket, no code → plan

a diff exists → verify

“in the browser”, URL → exploratory testing

path to a plan → write tests

“cover” → tests for existing code

“PLAN” MODE — BEFORE DEVELOPMENT

1 · Scope

The change in user terms, the touched modules and entities, whether a critical flow is involved.

2 · AC check

Each criterion: testable? consistent with the code? complete against the must-check web patterns? A gap → an AC edit or a question.

3 · Impact map

Who uses the touched code: imports, queries, service calls. For each edge — file, line and expected effect.

4 · Test delta

Which tests to change, new tests by bucket Must / Should (up to 5) / Highlight, the regression set.

Output: docs/qa/tasks/<ticket>.md. Budget: about 80k tokens. Before it starts, the mode and the reason are shown in one line.

STEP 2 · VERIFICATION AFTER CODE

/qa-pilot:test

1 · Reconcile with the plan

Each diff hunk: planned, an explained refactor, or an unplanned behaviour change. Plan items not done are listed.

2 · Recompute impact

The impact map is rebuilt from the real diff. A change where “unchanged” was expected → an “intended?” question with evidence.

3 · Coverage

For each Must and Should: a test, an assertion on this exact condition, a layer in CI. Regression and new tests run with the profile’s commands.

4 · Missing tests

Written in the project’s style and reviewed. A test for a found bug stays red and goes to the owner with the bug.

LIMITS FOR AUTOMATIC TESTS

The expected result comes from the AC, the spec or a decision — not from the changed code

At most 5 new tests and 1 e2e per task; the rest goes to the owner as a list

Product code is not changed

Output: a “Verify log” section in the task file and a ready block for the PR description. Budget: about 100k tokens. If there was no plan, a compact one is built first.

STEP 3 · HOW THE PROJECT AUDIT WORKS

/qa-pilot:audit

No context: the whole project, steps 1–5. With a feature, spec or ticket: an audit of that feature’s requirements (step 3 at full depth). With the word “tests”: a test-code audit (step 4 over the whole suite).

1 · Foundation

Test framework maturity in the profile’s 9 areas. Blockers (a layer counted as coverage that CI doesn’t run; false-green tests) go first in Must.

2 · Critical flows

3–7 flows from the profile. You confirm the list and see the cost before it runs: about 150–250k tokens per flow.

3 · Flow audit

A script picks the rules that fit the product traits. Each entity gets an “entity × must-check pattern” card: every cell has a verdict with evidence, and an empty cell blocks the report.

4 · Test code

Tests around the critical flows: false greens, flakiness, wrong test level.

5 · Roadmap

A report and a JSON task list for an executing agent. The JSON goes through a validator: errors must be 0.

WHAT IT RELIES ON · 1

Priority by risk, not by coverage percentage

A finding’s priority is set by its consequences for the product, not by the wording of a rule.

P1 — data loss, broken security, no check before prod. Assigned only with the place in the code shown.

P2 — a serious gap. P3 — cosmetic.

Must

P1, any confirmed bug, and P2 on a critical flow. Always done

Should

Other P2s — at most 8, so the list can actually be done

Highlight

One line about the risk, no test — until you decide to raise it

Risks excluded by project filters are listed in a separate section of the report.

WHAT IT RELIES ON · 2

The testing knowledge base

1300+

rules in the testing knowledge base

Test design, requirements, APIs, forms, accessibility (WCAG 2.2), security, localisation, performance, mobile platforms, UX, AI features, test-code quality

Every rule is checked against standards

RFC, W3C, ISTQB, OWASP, NIST. Each rule has an authority level — standard, industry practice, vendor guideline or author’s opinion. An author’s-opinion rule cannot be mandatory.

Extended for product teams

qa-pilot’s own domains: web failure patterns, security (OWASP ASVS), HTTP APIs, authentication (NIST), test strategy, AI features, test-code quality — and rules learned on real audits.

Special thanks to Roman Surkov: the core rule set comes from his book “Quality Decides Everything”.

CONTROL · 1

What scripts check

The model

Judgment: what can break here, which scenarios matter, how to word a finding.

Scripts, no LLM

  • pick rules by product traits
  • find “TBD”, “fast”, “easy” in requirements
  • validate the audit report: fields, source, verdicts
  • break the code under a test and restore the file
  • compare the profile with the repo
  • check the plugin itself: skills and links

You

Product decisions: what is critical, which depth to choose, what to do with a bug.

Scripts check data and the shape of the result, not the model’s judgment. A report with a validation error is not done.

CONTROL · 2

Evidence requirements

“COVERED” ONLY WITH THREE PROOFS

1

A test exists — with the exact file and line

2

It catches this exact case, not a neighbouring one

3

This layer actually runs in CI

“No test” — only with the search attached: command and match count

Can fail: a new test is checked against broken code; existing ones by a script probe on a sample

Test code is reviewed by separate agents, up to 3 rounds; every finding is checked against the code

Product bugs are not fixed automatically: they go to the owner with steps and the expected behaviour

CONTROL · 3

Limits

LimitWhat it means in practice
Strongest on frontend and e2eWorks on a pure backend, but relies on the project’s conventions rather than a ready pattern library
Audits cost tokensAbout 150–250k per flow. The plugin names the cost up front; you pick the flows
One repo, one profileThe plugin does not analyse links between repos
Needs answers to questionsIn the first week, answering takes time: the profile’s accuracy depends on it
Product decisions stay with the teamProduct code is not changed, business priorities are not set

WHEN IT HELPS

Typical situations and commands

A new project with existing tests

onboard → audit

Test framework assessment, critical-flow risks, order of work

A task before development

test TICKET-123

AC check, impact map, list of tests to add

A task after implementation

test

Diff reconciled with the plan, missing tests

Checking a spec

audit <feature>

Contradictions, undefined states, product questions

Flaky tests

audit tests

False-green and flaky tests, duplicates, a refactoring plan

Manual check in the browser

test in the browser

Walking a flow, bugs with repro steps, re-checking a fix

HOW TO START

Install

1 /plugin marketplace add grooownow/qa-pilot

2 /plugin install qa-pilot@qa-pilot

3 /qa-pilot:onboard

Needs: Claude Code and Node.js. Works on a Claude Pro subscription.

Next: audit for the big picture, then test for every task.

More: github.com/grooownow/qa-pilot

Open the repository on GitHub