browser-qa — скилл для Claude: проверка UI после деплоя
Гоняет живой интерфейс через браузерный MCP: ошибки в консоли, Core Web Vitals, формы, скриншоты на трёх ширинах и axe-core. Выносит вердикт SHIP или DO NOT SHIP.
npx skills add affaan-m/ECC --skill browser-qa -a claude-codeЧто делает browser-qa
Скилл запускает проверку развёрнутой страницы так, как это делал бы человек в браузере. Сначала смоук: ошибки в консоли с отсечением шума аналитики, ответы сети без 4xx и 5xx, скриншот первого экрана на десктопе и мобильном, метрики LCP, CLS и INP. Потом взаимодействие — клики по навигации, отправка форм с валидными и невалидными данными, вход и выход по тестовым учёткам, ключевые сценарии.
Дальше визуальная регрессия: снимки ключевых страниц на 375px, 768px и 1440px сравниваются с сохранённой базой. Сдвиги больше 5px, пропавшие элементы и переполнение попадают в отчёт. Если базы нет, скилл честно пишет INCONCLUSIVE вместо тихого PASS. Четвёртая фаза — доступность через axe-core: нарушения WCAG 2.2 AA, порядок фокуса, навигация с клавиатуры, ориентиры для скринридеров.
Работает с любым браузерным MCP: инструменты claude-in-chrome, Playwright через mcp__browserbase__* или скрипты Puppeteer. По умолчанию всё идёт в режиме read-only. Изменяющие сценарии вроде оплаты или удаления на продакшене скилл не запускает без явного согласия и staging-URL, а учётные данные и токены нужно вычищать из скриншотов. Ставьте, если фронтенд уходит в релиз часто и хочется ловить сломанные формы и вёрстку до пользователей. Для проекта без staging-окружения польза будет меньше.
Какие задачи решает
- поймать ошибки в консоли на задеплоенной странице
- проверить формы с валидными и невалидными данными
- сравнить вёрстку с базовыми скриншотами на трёх ширинах
- прогнать axe-core и найти нарушения WCAG 2.2 AA
- проверить вход и выход по тестовым учёткам
Примеры запросов агенту
- прогони browser-qa по превью-URL и скажи, можно ли шипить
- проверь формы и навигацию на staging, отчёт с вердиктом
- сделай визуальную регрессию на 375, 768 и 1440 и проверь доступность
Как установить browser-qa
1Через Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill browser-qa -a claude-code2Вручную: положить файлы
~/.claude/skills/browser-qa/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/browser-qa/
1Через Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill browser-qa -a codex2Вручную: положить файлы
.agents/skills/browser-qa/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill browser-qa -a cursor2Вручную: положить файлы
.cursor/skills/browser-qa/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install affaan-m/ECC browser-qa2Вручную: положить файлы
.github/skills/browser-qa/SKILL.md1Через Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill browser-qa -a gemini-cli2Командой платформы
gemini skills install https://github.com/affaan-m/ECC --path skills/browser-qaВручную: положить файлы
.devin/skills/browser-qa/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Через Skills CLI (Vercel)
npx skills add affaan-m/ECC --skill browser-qa -a opencodeClaude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
Из того же набора146
Весь набор →Похожие
Вопросы о browser-qa
Как установить browser-qa в Claude?
Выполните npx skills add affaan-m/ECC --skill browser-qa -a claude-code. Файл скилла окажется в ~/.claude/skills/browser-qa/SKILL.md.
Что делает browser-qa?
Проверяет развёрнутый интерфейс через браузерный MCP: консоль, сеть, Core Web Vitals, формы, авторизацию, скриншоты на трёх ширинах и доступность. Завершается вердиктом SHIP, SHIP WITH FIXES или DO NOT SHIP.
С какими браузерными MCP работает скилл?
С claude-in-chrome, Playwright через mcp__browserbase__* и прямыми скриптами Puppeteer. Изменяющие сценарии запускаются только на staging с явного согласия.
Исходный текст
SKILL.md · MIT
---
name: browser-qa
description: "Run automated post-deploy UI verification with a browser automation MCP (claude-in-chrome, Playwright, or Puppeteer): console-error and Core Web Vitals smoke checks, form and auth-flow interaction tests, screenshot visual regression across three breakpoints, and axe-core accessibility audits ending in a SHIP / DO-NOT-SHIP verdict. Use when testing a deployed feature on staging or preview, before shipping frontend changes, reviewing a frontend PR, or checking responsive layout and accessibility."
metadata:
origin: ECC
---
# Browser QA — Automated Visual Testing & Interaction
## When to Use
- After deploying a feature to staging/preview
- When you need to verify UI behavior across pages
- Before shipping — confirm layouts, forms, interactions actually work
- When reviewing PRs that touch frontend code
- Accessibility audits and responsive testing
## How It Works
Uses the browser automation MCP (claude-in-chrome, Playwright, or Puppeteer) to interact with live pages like a real user.
### Safety first — blast radius (run read-only by default)
Browser QA drives real auth and real user journeys, so treat the blast radius explicitly.
Default to **read-only**: never run a **mutating** journey (checkout, payment, delete,
mass-update) against a production URL — require an explicit opt-in **and** a staging/preview
URL. Use seeded **test credentials**, never real production logins, and **redact**
credentials/tokens/PII before saving any screenshot.
### Phase 1: Smoke Test
```
1. Navigate to target URL
2. Check for console errors (filter noise: analytics, third-party)
3. Verify no 4xx/5xx in network requests
4. Screenshot above-the-fold on desktop + mobile viewport
5. Check Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms
(INP replaced FID in March 2024; thresholds per web.dev)
```
### Phase 2: Interaction Test
```
1. Click every nav link — verify no dead links
2. Submit forms with valid data — verify success state
3. Submit forms with invalid data — verify error state
4. Test auth flow: login → protected page → logout (test creds only, never prod)
5. Test critical user journeys (checkout, onboarding, search)
— read-only by default; only exercise mutating journeys against staging
with explicit opt-in (see "Safety first" above)
```
### Phase 3: Visual Regression
```
1. Screenshot key pages at 3 breakpoints (375px, 768px, 1440px)
2. Compare against committed baseline screenshots
— no baseline ⇒ report INCONCLUSIVE, never a silent PASS
3. Flag layout shifts > 5px, missing elements, overflow
4. Check dark mode if applicable
```
### Phase 4: Accessibility
```
1. Run axe-core or equivalent on each page
2. Flag WCAG 2.2 AA violations (contrast, labels, focus order)
3. Verify keyboard navigation works end-to-end
4. Check screen reader landmarks
```
> Note: axe-core automatically covers roughly 30–40% of WCAG. A clean run is **necessary,
> not sufficient** — keyboard nav, focus order, and a screen-reader pass still need a manual
> check. Don't report "accessible" from an automated pass alone.
## Output Format
```markdown
## QA Report — [URL] — [timestamp]
### Smoke Test
- Console errors: 0 critical, 2 warnings (analytics noise)
- Network: all 200/304, no failures
- Core Web Vitals: LCP 1.2s ✓, CLS 0.02 ✓, INP 89ms ✓
### Interactions
- [✓] Nav links: 12/12 working
- [✗] Contact form: missing error state for invalid email
- [✓] Auth flow: login/logout working
### Visual
- [✗] Hero section overflows on 375px viewport
- [✓] Dark mode: all pages consistent
### Accessibility
- 2 AA violations: missing alt text on hero image, low contrast on footer links
### Verdict: SHIP WITH FIXES (2 issues, 0 blockers)
# verdict ∈ SHIP / SHIP WITH FIXES / DO NOT SHIP; use INCONCLUSIVE if no visual baseline
```
## Integration
Works with any browser MCP:
- `mChild__claude-in-chrome__*` tools (preferred — uses your actual Chrome)
- Playwright via `mcp__browserbase__*`
- Direct Puppeteer scripts
Pair with `/canary-watch` for post-deploy monitoring.
© affaan-m · MIT · affaan-m/ECC