smirnovalex-qa
- 58 skills
- 0 followers
- 1 day ago last updated
- ▌ En 2 · smirnovalex-qaTriage 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.
- ▌ Ru 2 · smirnovalex-qaТриаж входящего потока багов — приоритизация, дедупликация, раздельная оценка severity (техническое влияние) и priority (бизнес-срочность), классификация и рекомендация решения по каждому дефекту. Используй когда просят разобрать/отсортировать/приоритизировать баги, затриажить беклог дефектов, решить какие баги брать первыми, найти дубликаты багов, определить severity vs priority конкретного бага, или расчистить очередь входящих дефектов перед планированием спринта. Работает с любым трекером (Jira/YouTrack/GitHub Issues/Linear) через доступный MCP-инструмент или вставленный список. Это НЕ то же, что `bug-report-verify` (тот адверсариально проверяет один репорт на реальность) и не `bug-report-write` (тот оформляет один новый репорт) — здесь речь о разборе и приоритизации ПОТОКА уже заведённых багов.
- ▌ En 3 · smirnovalex-qaDesigns, 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
- ▌ Ru 3 · smirnovalex-qaПроектирует, ревьюит и настраивает quality-gate в CI/CD пайплайне — что реально должно блокировать мерж и деплой (линт/формат/типы, unit+integration тесты, порог покрытия на diff, статический анализ/SAST, зависимости/SCA, secret-scan, E2E/smoke, миграции, IaC-скан), с проверкой что гейт действительно fail'ит билд, а не только предупреждает, что фидбэк быстрый и fail-fast, что flaky не блокируют ложно, и что сам пайплайн безопасен (script injection, pin версий actions, минимальные permissions токена). Используй когда просят «настрой quality gate», «добавь тесты/линт/покрытие в CI», «что должно блокировать мерж», «ревью пайплайна на QA-гейты», «gate по покрытию/безопасности», «pre-merge проверки», «сделай так чтобы красные тесты не давали смержить», «проверь наш CI на дыры в гейтах» — даже если слова «gate» нет, а говорят «почему упавшие тесты пропускают в main», «давай ужесточим проверки перед деплоем», «настрой pre-commit/pre-push». Скилл сначала определяет CI-систему проекта по конфигам и может РЕДАКТИРОВАТЬ
- ▌
- ▌
- ▌ En 5 · smirnovalex-qaIndependent 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.
- ▌ Ru 5 · smirnovalex-qaНезависимый QA/tech-lead аудит багфикса — проверяет по фактам кода и тестов, действительно ли баг исправлен, нет ли регрессии, не сломан ли смежный функционал, и соответствует ли реализация enterprise/prod-ready стандартам. Используй когда просят проверить/заодитить фикс бага, ревьюнуть исправление, убедиться что баг реально пофикшен перед мержем/релизом, или проверить нет ли регрессии от исправления бага.
- ▌
- ▌
- ▌
- ▌
- ▌ En 8 · smirnovalex-qaFull 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.
- ▌ Ru 8 · smirnovalex-qaПолное ревью новой фичи или ветки перед мержем/релизом — сверка с требованиями (YouTrack/файл требований, если есть; иначе агент сам восстановит объём изменений по git diff), code review, поиск нестыковок в use cases, проверка регрессии смежных модулей и живое тестирование UI в браузере, с итоговым prod-ready вердиктом. Используй всегда, когда просят проверить готовность фичи/ветки/PR к мержу или релизу, ревьюнуть/протестировать новую функциональность, пройти use cases вживую, проверить регрессию соседних экранов, или сделать QA/приёмку перед продом — даже если явной ссылки на требования/issue в запросе нет.
- ▌ En 9 · smirnovalex-qaBuilds a quick, practical manual-check checklist for a screen/feature/flow — lighter than formal test cases, for exploratory testing and acceptance before a demo/release. Groups the checks (functional, input fields, UI states, negative, navigation, permissions, responsiveness, accessibility, concurrency) and provides an exploratory-charter template (session-based testing). Use when asked to "make a checklist to verify", "what to click through by hand on this page", "a feature acceptance checklist", "a quick list of checks before the demo", "what to look at when testing this screen", "walk through the feature by hand" — even if the word "checklist" is not said literally, but they say "what to check here", "give me a list for the smoke". This is NOT formal test cases with steps and traceability (use `test-case-design` for that) — here it is a compact, practical list for a manual pass. The artifact is saved to `docs/qa/checklists/`; project code is not touched.
- ▌ Ru 9 · smirnovalex-qaСоставляет быстрый практичный чек-лист ручной проверки экрана/фичи/флоу — легче формальных тест-кейсов, для exploratory-тестирования и приёмки перед демо/релизом. Группирует проверки (функциональные, поля ввода, состояния UI, негатив, навигация, права, отзывчивость, доступность, конкурентность) и даёт шаблон exploratory-charter (session-based testing). Используй когда просят «сделай чек-лист для проверки», «что руками прокликать на этой странице», «чек-лист приёмки фичи», «быстрый список проверок перед демо», «на что смотреть при тестировании этого экрана», «пройдись по фиче руками» — даже если слово «чек-лист» не звучит буквально, а говорят «что бы тут проверить», «дай список для смоука». Это НЕ формальные тест-кейсы с шагами и трассируемостью (для этого есть `test-case-design`) — здесь компактный практичный список для ручного прохода. Артефакт сохраняется в `docs/qa/checklists/`, код проекта не трогается.
- ▌ En 10 · smirnovalex-qaDesigns 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
- ▌ Ru 10 · smirnovalex-qaПроектирует и пишет API/контрактные автотесты на эндпоинты или сервис (REST/GraphQL/gRPC), затем реально запускает их и чинит до зелёного прогона. Сначала определяет, какой стек API-тестов уже используется в репозитории (pytest+httpx/requests / newman-Postman / REST-assured / supertest / k6 для смока — по pyproject/package.json/pom/зависимостям/существующим тестам/CI) и пишет в его конвенции, а не навязывает новый. На каждый эндпоинт покрывает позитив (валидный запрос → 2xx + корректное тело), негатив (невалидное тело/типы/отсутствующие поля → 4xx), границы (лимиты, пагинация, пустые списки, большой payload), авторизацию (без токена/чужой токен/чужая роль → 401/403, IDOR), идемпотентность повторного POST/PUT, коды статусов и заголовки, contract/schema-валидацию ответа против OpenAPI/Swagger/GraphQL-схемы, обработку ошибок сервера и rate limiting. Используй когда просят «напиши api тесты», «покрой эндпоинты тестами», «контрактные тесты по openapi/swagger», «тесты на REST/GraphQL API», «проверь ответы и коды ст
- ▌ En 11 · smirnovalex-qaDesigns 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",
- ▌ Ru 11 · smirnovalex-qaПроектирует и пишет E2E/UI-автотесты на пользовательский флоу, экран или форму, затем реально запускает их и чинит до зелёного прогона. Сначала определяет, какой E2E-стек уже используется в репозитории (Playwright / Cypress / Selenium / WebdriverIO — по package.json/зависимостям/существующим тестам/CI) и пишет в его конвенции, а не навязывает новый. Проектирует сценарии из требований по технике use-case (happy path + альтернативные + негативные + edge), строит устойчивую архитектуру (Page Object, fixtures, изоляция), делает тесты нефлейкими (роль/testid-локаторы, auto-waiting вместо sleep) и приводит вывод фактического прогона. Используй когда просят «напиши e2e тесты», «автоматизируй этот сценарий в браузере», «playwright/cypress тесты на эту страницу», «покрой пользовательский флоу автотестами», «e2e на форму логина/чекаут/регистрацию», «прогони UI-сценарий автоматом» — даже если слово «e2e» не произнесено буквально, а речь про «автотесты на интерфейс», «браузерные тесты», «проверить страницу автоматически
- ▌ En 12 · smirnovalex-qaHelps 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.
- ▌ Ru 12 · smirnovalex-qaПомогает составить короткий, информативный баг-репорт в фиксированной структуре (Название, Описание, Приоритет, Статус, Дата обнаружения, Шаги для воспроизведения, Ожидаемый результат, Фактический результат). Используй когда просят написать/оформить/составить баг-репорт или отчёт об ошибке по описанию проблемы.
- ▌ En 13 · smirnovalex-qaInternationalization (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", "
- ▌ Ru 13 · smirnovalex-qaРевью интернационализации (i18n) и локализации (l10n) — периметр из фичи/экрана/директории/ветки, документа-требований или issue в трекере; проверка хардкода строк, полноты переводов, переполнения UI на длинных языках, поддержки RTL, плюрализации, форматов дат/чисел/валют/времени по локали, часовых поясов, unicode и интерполяции переменных, с живым прогоном на разных локалях в браузере. Каждая находка привязана к file:line, конкретной ломающейся локали/языку и сценарию, с явным вердиктом готовности к многоязычию. Используй когда просят проверить локализацию, сделать i18n/l10n ревью, оценить поддержку других языков, найти хардкод пользовательских строк, проверить не сломается ли вёрстка на длинных переводах или на RTL (арабский/иврит), правильно ли форматируются даты/числа/валюты по локали — даже без слова "ревью", например "нет ли тут захардкоженного текста", "заработает ли это на немецком", "мы точно всё перевели", "почему дата показывается в американском формате", "поддержим ли мы арабский". Скилл только ан
- ▌ En 14 · smirnovalex-qaDesigns a complete set of test cases from requirements/a feature using formal test-design techniques (equivalence partitioning, boundary values, decision tables, state transition, pairwise, use-case, error guessing) with requirement→case traceability, P0/P1/P2 priorities, and positive/negative/boundary cases. Use when asked to "design test cases", "write tests from the requirements", "which cases need to be checked", "cover this feature with test cases", "test cases for this form/endpoint", "we need boundary values and negative cases", "lay out the checks for this feature" — even if the user does not say the phrase "test case" literally, but says "what actually needs testing here", "break this down into cases", "build a test matrix". This is NOT a quick manual click-through checklist (use `test-checklist` for that) and NOT test data generation (`test-data-generation`) — here it is specifically formal, structured test cases with steps and an expected result. The artifact is saved to `docs/qa/test-cases/`; proj
- ▌ Ru 14 · smirnovalex-qaПроектирует полный набор тест-кейсов из требований/фичи по формальным техникам тест-дизайна (эквивалентное разбиение, граничные значения, таблицы решений, state transition, pairwise, use-case, error guessing) с трассируемостью требование→кейс, приоритетами P0/P1/P2 и позитивными/негативными/граничными кейсами. Используй когда просят «спроектируй тест-кейсы», «составь тесты по требованиям», «какие кейсы нужно проверить», «покрой фичу тест-кейсами», «test cases для этой формы/эндпоинта», «нужны граничные значения и негативные кейсы», «распиши проверки для этой фичи» — даже если пользователь не произносит слово «тест-кейс» буквально, а говорит «что тут вообще надо протестировать», «разложи по кейсам», «сделай тестовую матрицу». Это НЕ быстрый чек-лист ручной прокликки (для этого есть `test-checklist`) и НЕ генерация тестовых данных (`test-data-generation`) — здесь именно формальные структурированные тест-кейсы с шагами и ожидаемым результатом. Артефакт сохраняется в `docs/qa/test-cases/`, код проекта не трогаетс
- ▌ En 15 · smirnovalex-qaAdversarially 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.
- ▌ Ru 15 · smirnovalex-qaАдверсариально проверяет валидность баг-репорта — не оформление, а саму проблему по первоисточникам (код, спека, git history), с попыткой опровергнуть репорт прежде чем подтвердить его. Используй, когда просят проверить/провалидировать/подтвердить баг-репорт, усомниться в баг-репорте, или перед тем как начинать работу над заведённым багом, чтобы убедиться что он реальный, а не галлюцинация агента.
- ▌
- ▌
- ▌
- ▌
- ▌
- ▌
- ▌ En 19 · smirnovalex-qaAccessibility (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
- ▌ Ru 19 · smirnovalex-qaАудит доступности (a11y) веб-интерфейса по WCAG 2.1/2.2 (уровни A и AA) — периметр из фичи/экрана/директории/ветки, документа-требований или issue в трекере; проверка по принципам POUR (Perceivable/Operable/Understandable/Robust) с обязательным ЖИВЫМ прогоном в браузере (клавиатура, фокус, aria, контраст, скринридер), а не только чтением кода. Каждая находка привязана к WCAG success criterion, затронутой группе пользователей, file:line и конкретному сценарию, с явным вердиктом соответствия. Используй когда просят проверить доступность страницы/компонента, сделать a11y аудит, оценить соответствие WCAG, проверить доступность для скринридеров или с клавиатуры, разобраться с контрастом/фокусом/aria/семантикой/alt-текстами/landmarks/модалками — даже без слова "аудит", например "доступно ли это для незрячих", "работает ли это без мыши", "почему скринридер не читает эту кнопку", "проходит ли это по WCAG AA", "нормальный ли тут контраст". Скилл только анализирует и сохраняет отчёт-файл, код проекта не меняет.
- ▌ En 20 · smirnovalex-qaRequirements review for testability, completeness, and consistency (shift-left)
- ▌
- ▌ En 21 · smirnovalex-qaRoot 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
- ▌ Ru 21 · smirnovalex-qaАнализ первопричины (RCA) дефекта, инцидента или упавшего теста по фактам — доказывая причину кодом/логами/воспроизведением, а не угадывая, с разделением непосредственной и корневой причины, техниками 5 Whys и Ishikawa/fishbone, локализацией вводящего коммита через git bisect и отдельным разбором «почему это не поймали тесты». Используй когда просят найти первопричину бага/инцидента, сделать RCA, разобрать «почему это сломалось на самом деле», провести 5 почему, написать постмортем по инциденту, понять как дефект прошёл мимо тестов и ревью, или почему фикс не помог. Работает с любым трекером (Jira/YouTrack/GitHub Issues/Linear) через доступный MCP-инструмент или вставленные данные. Это НЕ `bug-report-verify` (тот доказывает, что баг реален) и не `bugfix-audit` (тот проверяет уже сделанный фикс) — здесь цель установить и доказать ПРИЧИНУ, а также системно предотвратить класс проблемы. Срабатывай даже без слова «RCA», например «почему вообще это могло произойти», «докопайся до корня», «как такое утекло в прод».
- ▌ En 22 · smirnovalex-qaFull 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
- ▌ Ru 22 · smirnovalex-qaПолный аудит безопасности ВСЕГО репозитория the-platform (все backend-сервисы, the-frontend, встраиваемые виджеты/расширения, общие библиотеки libs/*, инфраструктурные конфиги helm/k8s/docker) — три независимых среза (автоматизированное сканирование SCA/SAST/secret-scan/IaC, построчный код-ревью по зонам, архитектурный обзор), детальный чек-лист по 14 категориям (auth/authz, мультитенантность, websocket, internal API, инъекции, SSRF, XSS, секреты/PII, файлы, зависимости, docker, k8s/helm, обработка ошибок, CI/CD), находки с file:line и сценарием эксплуатации, и итоговым отчётом для руководства. Используй когда просят провести полный аудит безопасности всей кодовой базы/репозитория/платформы целиком, найти уязвимости по всему проекту, перепроверить статус находок из предыдущего security-аудита, или оценить общую готовность платформы к обработке персональных данных клиентов с точки зрения безопасности — даже если пользователь не произносит слово "аудит" буквально, а говорит "давай проверим весь проект на дыры в
- ▌ En 23 · smirnovalex-qaProduces a Test Summary Report (QA sign-off) for stakeholders on a cycle/release — what was and wasn't tested, a summary of case results (passed/failed/blocked/skipped) and requirements coverage, defects found by severity, residual risks and known issues, non-functional results, quality metrics, a verdict-recommendation, and appendices with links. Use when asked for a "test report", "test summary report", "testing results for a release/cycle", "QA sign-off", "what was tested and with what result", "a report on the test-cycle run", "a quality summary for management", "a testing recap before release" — even if the term isn't said and it's phrased as "pull together what we tested", "we need a document for stakeholders about the release quality", "wrap up the QA". Tone — for management (executive summary without jargon) plus technical appendices. Data is gathered from CI/the tracker/previous reports in docs/qa; when data is missing the skill honestly flags the gaps rather than inventing numbers.
- ▌ Ru 23 · smirnovalex-qaФормирует итоговый отчёт о тестировании (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; при отсутствии данных скилл честно помечает пробелы, а не выдумывает цифры.
- ▌ En 24 · smirnovalex-qaCross-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
- ▌ Ru 24 · smirnovalex-qaПроверка кросс-браузерной и адаптивной (responsive) совместимости веб-интерфейса — периметр из фичи/экрана/директории/ветки, документа-требований или issue в трекере; проверка по матрице браузеров/устройств и брейкпоинтам (mobile/tablet/desktop) с обязательным живым прогоном в браузере через эмуляцию разных вьюпортов и user-agent, анализ поддержки используемых CSS-фич и JS-API (caniuse-логика), touch vs mouse, нативных контролов, тёмной темы и зума. Каждая находка привязана к конкретному браузеру/устройству/брейкпоинту, file:line и сценарию, с явным вердиктом совместимости. Используй когда просят проверить работу в разных браузерах, провести кросс-браузерное тестирование, оценить работу в Safari/Firefox/Edge, проверить адаптивность/мобильную вёрстку/responsive, разобраться почему ломается на мобильном или планшете — даже без слова "тестирование", например "заработает ли это в сафари", "не поедет ли вёрстка на телефоне", "поддерживается ли этот CSS везде", "нормально ли на планшете", "почему на iOS кнопка не н
- ▌
- ▌
- ▌
- ▌
- ▌ En 27 · smirnovalex-qaFull 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.
- ▌ Ru 27 · smirnovalex-qaПолный аудит производительности и ресурсоёмкости всего репозитория the-platform (backend-сервисы FastAPI/asyncpg/PostgreSQL/Redis/RabbitMQ, the-frontend, общие библиотеки libs/*, Docker/Kubernetes/Helm инфраструктура, нагрузочное тестирование k6 в load-testing/) — три независимых среза (инструментальное профилирование, построчный код-ревью, архитектурный обзор), находки только с измерением (EXPLAIN ANALYZE, py-spy, размер бандла, k6-прогоны), severity, file:line и итоговым вердиктом. Используй когда просят провести аудит производительности/ресурсоёмкости всей кодовой базы или инфраструктуры целиком, проверить расход CPU/RAM/сетевого трафика/стоимости инфраструктуры, найти узкие места по всему репозиторию, оценить экономичность архитектуры при росте нагрузки, или повторно перепроверить статус находок из предыдущего аудита/load-testing отчётов — даже если пользователь не произносит слово "аудит" буквально, а говорит "почему сервис жрёт столько CPU/памяти", "давай посмотрим на производительность всего проекта" и
- ▌ En 28 · smirnovalex-qaFocused 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
- ▌ Ru 28 · smirnovalex-qaТочечный аудит безопасности ОДНОЙ конкретной фичи/изменения в the-platform (не всего репозитория) — периметр из директории/ветки/diff, документа-спецификации/PRD или YouTrack issue; та же дисциплина проверки, что и у полного аудита (адверсариальная верификация, три независимых среза, чек-лист по 14 категориям — auth/authz, мультитенантность, websocket, internal API, инъекции, SSRF, XSS, секреты/PII, файлы, зависимости, docker, k8s/helm, обработка ошибок, CI/CD), с привязкой находок к file:line и явным вердиктом готовности к релизу. Используй когда просят проверить безопасность конкретной фичи, ветки, PR или YouTrack-задачи перед мержем/релизом, найти уязвимости в новом эндпоинте/интеграции/загрузке файлов/вебхуке, оценить не открывает ли новая функциональность доступ к чужим данным или чужой компании — даже без слова "аудит", например "не течёт ли эта фича между компаниями", "можно ли эту фичу мержить с точки зрения безопасности", "проверь эту ветку на security-дыры". Это НЕ то же самое, что скилл `security-r
- ▌ En 29 · smirnovalex-qaFocused 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".
- ▌ Ru 29 · smirnovalex-qaТочечный аудит производительности и ресурсоёмкости ОДНОЙ конкретной фичи/изменения в the-platform (не всей кодовой базы) — периметр из директории/ветки/diff, документа требований или YouTrack issue; та же дисциплина измерений, что и у полного аудита (EXPLAIN ANALYZE, py-spy, размер бандла, k6), сравнение "до/после" если фича заменяет существующий функционал, явный вердикт готовности к продакшену. Используй когда просят проверить производительность/расход ресурсов конкретной фичи, ветки, PR или YouTrack-задачи перед мержем/релизом, оценить не деградировала ли новая реализация существующий функционал по скорости/ресурсам, или дать зелёный свет по ресурсоёмкости именно для этого изменения — даже без явного слова "аудит", например "не положит ли эта фича базу", "сколько это будет жрать на реальных объёмах", "готова ли эта ветка по производительности".
- ▌
- ▌