smirnovalex-qa
UserQA skills for AI coding agents — test design, automation, audits, and defect management from a single source.
Categories
Indexed Skills (19)
accessibility-audit
Accessibility (a11y) audit of a web interface against WCAG 2.1/2.2 (levels A and AA) — scope from a feature/screen/directory/branch, a requirements document, or a tracker issue; checking by the POUR principles (Perceivable/Operable/Understandable/Robust) with a mandatory LIVE run in the browser (keyboard, focus, aria, contrast, screen reader), not just reading the code. Every finding is tied to a WCAG success criterion, the affected user group, file:line, and a concrete scenario, with an explicit conformance verdict. Use when asked to check the accessibility of a page/component, do an a11y audit, assess WCAG conformance, verify accessibility for screen readers or keyboard, or sort out contrast/focus/aria/semantics/alt text/landmarks/modals — even without the word "audit", e.g. "is this usable for blind people", "does this work without a mouse", "why doesn't the screen reader read this button", "does this pass WCAG AA", "is the contrast okay here". The skill only analyzes and saves a report file; it does not c
api-test-author
Designs and writes API/contract automated tests for endpoints or a service (REST/GraphQL/gRPC), then actually runs them and fixes them until the run is green. First it detects which API-testing stack the repository already uses (pytest+httpx/requests / newman-Postman / REST-assured / supertest / k6 for smoke — from pyproject/package.json/pom/dependencies/existing tests/CI) and writes in that stack's conventions rather than imposing a new one. For each endpoint it covers the positive path (valid request → 2xx + correct body), negative (invalid body/types/missing fields → 4xx), boundaries (limits, pagination, empty lists, large payload), authorization (no token/another's token/another's role → 401/403, IDOR), idempotency of a repeated POST/PUT, status codes and headers, contract/schema validation of the response against the OpenAPI/Swagger/GraphQL schema, server error handling and rate limiting. Use when asked to "write api tests", "cover the endpoints with tests", "contract tests from openapi/swagger", "tests
bug-report-verify
Adversarially checks the validity of a bug report — not the formatting, but the problem itself against primary sources (code, spec, git history), trying to disprove the report before confirming it. Use when asked to check/validate/confirm a bug report, to doubt a bug report, or before starting work on a filed bug to make sure it is real and not an agent's hallucination.
bug-triage
Triage of the incoming bug stream — prioritization, deduplication, separate assessment of severity (technical impact) and priority (business urgency), classification and a recommended resolution for each defect. Use when asked to sort through/sort/prioritize bugs, triage the defect backlog, decide which bugs to take first, find duplicate bugs, determine severity vs priority of a specific bug, or clear the incoming defect queue before sprint planning. Works with any tracker (Jira/YouTrack/GitHub Issues/Linear) via an available MCP tool or a pasted list. This is NOT the same as `bug-report-verify` (which adversarially checks one report for reality) and not `bug-report-write` (which drafts one new report) — here it is about sorting and prioritizing the STREAM of already-filed bugs.
bugfix-audit
Independent QA/tech-lead audit of a bugfix — verifies against the facts of the code and tests whether the bug is actually fixed, whether a regression was introduced, whether adjacent functionality got broken, and whether the implementation meets enterprise/prod-ready standards. Use when asked to check/audit a bugfix, review a fix, confirm a bug is really fixed before merge/release, or check whether fixing the bug caused a regression.
ci-qa-gate
Designs, reviews, and configures a quality gate in a CI/CD pipeline — what should actually block a merge and a deploy (lint/format/types, unit+integration tests, coverage threshold on the diff, static analysis/SAST, dependencies/SCA, secret-scan, E2E/smoke, migrations, IaC scan), verifying that the gate really fails the build and does not just warn, that feedback is fast and fail-fast, that flaky tests do not block falsely, and that the pipeline itself is secure (script injection, pinned action versions, minimal token permissions). Use when asked "set up a quality gate", "add tests/lint/coverage to CI", "what should block a merge", "review the pipeline for QA gates", "a gate on coverage/security", "pre-merge checks", "make it so red tests can't be merged", "check our CI for holes in the gates" — even without the word "gate", when they say "why do failing tests get into main", "let's tighten the checks before deploy", "set up pre-commit/pre-push". The skill first detects the project's CI system from its config
cross-browser-compat
Cross-browser and responsive compatibility check of a web interface — scope from a feature/screen/directory/branch, a requirements document, or a tracker issue; checking against a browser/device matrix and breakpoints (mobile/tablet/desktop) with a mandatory live run in the browser via emulation of different viewports and user-agents, analysis of support for the CSS features and JS APIs used (caniuse logic), touch vs mouse, native controls, dark theme, and zoom. Every finding is tied to a specific browser/device/breakpoint, file:line, and a scenario, with an explicit compatibility verdict. Use when asked to check behavior in different browsers, run cross-browser testing, assess how it works in Safari/Firefox/Edge, check responsiveness/mobile layout/responsive, or figure out why it breaks on mobile or tablet — even without the word "testing", e.g. "will this work in safari", "won't the layout fall apart on a phone", "is this CSS supported everywhere", "is it fine on a tablet", "why doesn't the button tap on iO
e2e-test-author
Designs and writes E2E/UI automated tests for a user flow, screen, or form, then actually runs them and fixes them until the run is green. First it detects which E2E stack the repository already uses (Playwright / Cypress / Selenium / WebdriverIO — from package.json/dependencies/existing tests/CI) and writes in that stack's conventions rather than imposing a new one. It designs scenarios from requirements using the use-case technique (happy path + alternative + negative + edge), builds a resilient architecture (Page Object, fixtures, isolation), makes the tests non-flaky (role/testid locators, auto-waiting instead of sleep), and reports the actual run output. Use when asked to "write e2e tests", "automate this scenario in the browser", "playwright/cypress tests for this page", "cover a user flow with automated tests", "e2e for the login/checkout/registration form", "run this UI scenario automatically" — even if the word "e2e" is not said literally and the request is about "automated tests for the interface",
feature-review
Full review of a new feature or branch before merge/release — verification against requirements (YouTrack/a requirements file, if any; otherwise the agent reconstructs the scope of changes from the git diff itself), code review, hunting for inconsistencies in use cases, checking adjacent modules for regression, and live UI testing in the browser, with a final prod-ready verdict. Use whenever asked to check a feature/branch/PR for readiness to merge or release, review/test new functionality, walk through use cases live, check adjacent screens for regression, or do QA/acceptance before prod — even if there is no explicit reference to requirements/an issue in the request.
i18n-l10n-review
Internationalization (i18n) and localization (l10n) review — scope from a feature/screen/directory/branch, a requirements document, or a tracker issue; checking hardcoded strings, translation completeness, UI overflow on long languages, RTL support, pluralization, date/number/currency/time formats by locale, time zones, unicode, and variable interpolation, with a live run across locales in the browser. Every finding is tied to file:line, the specific breaking locale/language, and a scenario, with an explicit verdict on multilingual readiness. Use when asked to check localization, do an i18n/l10n review, assess support for other languages, find hardcoded user-facing strings, verify whether the layout will break on long translations or on RTL (Arabic/Hebrew), or whether dates/numbers/currencies are formatted correctly by locale — even without the word "review", e.g. "is there any hardcoded text here", "will this work in German", "did we really translate everything", "why is the date shown in American format", "
performance-audit-feature
Focused performance and resource-cost audit of ONE specific feature/change in the-platform (not the whole codebase) — scope taken from a directory/branch/diff, a requirements document, or a YouTrack issue; the same measurement discipline as the full audit (EXPLAIN ANALYZE, py-spy, bundle size, k6), a "before/after" comparison if the feature replaces existing functionality, an explicit production-readiness verdict. Use when asked to check the performance/resource consumption of a specific feature, branch, PR, or YouTrack task before merge/release, to assess whether a new implementation degraded existing functionality in speed/resources, or to give the resource-cost green light for that specific change — even without the word "audit", e.g. "will this feature take down the database", "how much will this eat at real volumes", "is this branch ready performance-wise".
performance-audit-full
Full performance and resource-cost audit of the entire the-platform repository (FastAPI/asyncpg/PostgreSQL/Redis/RabbitMQ backend services, the-frontend, shared libraries libs/*, Docker/Kubernetes/Helm infrastructure, k6 load testing in load-testing/) — three independent passes (instrumental profiling, line-by-line code review, architectural review), findings only with measurement (EXPLAIN ANALYZE, py-spy, bundle size, k6 runs), severity, file:line, and a final verdict. Use when asked to run a performance/resource-cost audit of the whole codebase or infrastructure, to check CPU/RAM/network-traffic/infrastructure-cost consumption, to find bottlenecks across the whole repository, to assess the economy of the architecture as load grows, or to re-verify the status of findings from a previous audit/load-testing reports — even if the user doesn't say the word "audit" literally, but says "why does the service eat so much CPU/memory", "let's look at the performance of the whole project", etc.
root-cause-analysis
Root cause analysis (RCA) of a defect, incident or failed test based on facts — proving the cause with code/logs/reproduction rather than guessing, separating the proximate and the root cause, using 5 Whys and Ishikawa/fishbone techniques, localizing the introducing commit via git bisect and a separate examination of "why the tests did not catch it". Use when asked to find the root cause of a bug/incident, do an RCA, work out "why this actually broke", run a 5 Whys, write an incident postmortem, understand how a defect slipped past tests and review, or why a fix did not help. Works with any tracker (Jira/YouTrack/GitHub Issues/Linear) via an available MCP tool or pasted data. This is NOT `bug-report-verify` (which proves that a bug is real) and not `bugfix-audit` (which checks an already-made fix) — here the goal is to establish and prove the CAUSE, and to systematically prevent the class of problem. Trigger even without the word "RCA", for example "why could this even happen", "dig down to the root", "how di
security-audit-feature
Focused security audit of ONE specific feature/change in the-platform (not the whole repository) — scope taken from a directory/branch/diff, a spec/PRD document, or a YouTrack issue; the same verification discipline as the full audit (adversarial verification, three independent passes, a 14-category checklist — auth/authz, multi-tenancy, websocket, internal API, injections, SSRF, XSS, secrets/PII, files, dependencies, docker, k8s/helm, error handling, CI/CD), with findings tied to file:line and an explicit release-readiness verdict. Use when asked to check the security of a specific feature, branch, PR, or YouTrack task before merge/release, to find vulnerabilities in a new endpoint/integration/file upload/webhook, or to assess whether new functionality opens access to someone else's data or another company — even without the word "audit", e.g. "is this feature leaking between companies", "is this feature OK to merge security-wise", "check this branch for security holes". This is NOT the same as the `security
security-audit-full
Full security audit of the ENTIRE the-platform repository (all backend services, the-frontend, embeddable widgets/extensions, shared libraries libs/*, infrastructure configs helm/k8s/docker) — three independent passes (automated scanning SCA/SAST/secret-scan/IaC, line-by-line code review by zone, architectural review), a detailed 14-category checklist (auth/authz, multi-tenancy, websocket, internal API, injections, SSRF, XSS, secrets/PII, files, dependencies, docker, k8s/helm, error handling, CI/CD), findings with file:line and an exploitation scenario, and a final report for leadership. Use when asked to run a full security audit of the whole codebase/repository/platform, to find vulnerabilities across the entire project, to re-verify the status of findings from a previous security audit, or to assess the platform's overall readiness to handle customer personal data from a security standpoint — even if the user doesn't say the word "audit" literally, but says "let's check the whole project for security holes
test-case-design
Проектирует полный набор тест-кейсов из требований/фичи по формальным техникам тест-дизайна (эквивалентное разбиение, граничные значения, таблицы решений, state transition, pairwise, use-case, error guessing) с трассируемостью требование→кейс, приоритетами P0/P1/P2 и позитивными/негативными/граничными кейсами. Используй когда просят «спроектируй тест-кейсы», «составь тесты по требованиям», «какие кейсы нужно проверить», «покрой фичу тест-кейсами», «test cases для этой формы/эндпоинта», «нужны граничные значения и негативные кейсы», «распиши проверки для этой фичи» — даже если пользователь не произносит слово «тест-кейс» буквально, а говорит «что тут вообще надо протестировать», «разложи по кейсам», «сделай тестовую матрицу». Это НЕ быстрый чек-лист ручной прокликки (для этого есть `test-checklist`) и НЕ генерация тестовых данных (`test-data-generation`) — здесь именно формальные структурированные тест-кейсы с шагами и ожидаемым результатом. Артефакт сохраняется в `docs/qa/test-cases/`, код проекта не трогаетс
test-checklist
Составляет быстрый практичный чек-лист ручной проверки экрана/фичи/флоу — легче формальных тест-кейсов, для exploratory-тестирования и приёмки перед демо/релизом. Группирует проверки (функциональные, поля ввода, состояния UI, негатив, навигация, права, отзывчивость, доступность, конкурентность) и даёт шаблон exploratory-charter (session-based testing). Используй когда просят «сделай чек-лист для проверки», «что руками прокликать на этой странице», «чек-лист приёмки фичи», «быстрый список проверок перед демо», «на что смотреть при тестировании этого экрана», «пройдись по фиче руками» — даже если слово «чек-лист» не звучит буквально, а говорят «что бы тут проверить», «дай список для смоука». Это НЕ формальные тест-кейсы с шагами и трассируемостью (для этого есть `test-case-design`) — здесь компактный практичный список для ручного прохода. Артефакт сохраняется в `docs/qa/checklists/`, код проекта не трогается.
test-summary-report
Формирует итоговый отчёт о тестировании (Test Summary Report, QA sign-off) для стейкхолдеров по циклу/релизу — что тестировалось и что нет, сводка результатов кейсов (passed/failed/blocked/skipped) и покрытия требований, найденные дефекты по severity, остаточные риски и known issues, нефункциональные результаты, метрики качества, вердикт-рекомендация и приложения со ссылками. Используй когда просят «отчёт о тестировании», «test summary report», «итоги тестирования релиза/цикла», «QA sign-off», «что протестировано и с каким результатом», «отчёт по прогону тест-цикла», «сводку для менеджмента по качеству», «резюме тестирования перед релизом» — даже если термин не произнесён, а говорят «собери, что мы натестили», «нужен документ для стейкхолдеров про качество релиза», «подведи итоги QA». Тон — для менеджмента (executive summary без жаргона) плюс технические приложения. Данные соб��раются из CI/трекера/предыдущих отчётов в docs/qa; при отсутствии данных скилл честно помечает пробелы, а не выдумывает цифры.
bug-report-write
Helps you put together a short, informative bug report in a fixed structure (Title, Description, Priority, Status, Date found, Steps to reproduce, Expected result, Actual result). Use when asked to write/draft/put together a bug report or defect report from a problem description.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.