ABOUTME: End-to-end UI verification; never report a UI change done on a green edit or passing tests alone
ABOUTME: Browser interaction, zero-new-console-errors, before/after screenshots, Lighthouse gate when perf-relevant
Verify Frontend
A successful edit and green unit tests do NOT verify a UI change: they can encode the same wrong assumption as the code. Verify the way a human reviewer would, in a real browser, with quantitative checks wherever possible.
When
- After any change touching rendered UI (components, templates, styles, client-side logic)
- Before reporting a UI subtask complete in the orchestrator loop (feeds VERIFY, step 2)
- Skip only for changes with no runtime surface (type-only, test-only, docs)
Protocol
Run every step. A failure at any step means: fix, then rerun from step 1. Never hand back partially verified work.
If the chrome-devtools MCP tools are deferred, load the needed set in ONE ToolSearch call first (new_page, navigate_page, take_screenshot, list_console_messages, list_network_requests, resize_page, lighthouse_audit).
- Baseline (before the change, when still possible): start the dev server, open the affected page, screenshot it, record the console error/warning count. If the change is already applied and touches shared layout or navigation (risky: regressions can land outside the edited page), capture a true baseline:
git stash → screenshot + console count → git stash pop, then continue. Otherwise note that the baseline is post-hoc.
- Load: open the edited page in the browser (
new_page/navigate_page). The page must render without blank screens or error overlays.
- Interact: exercise the change directly. New control (button, input, toggle): click/type into it and confirm the expected state change. Changed layout: resize to mobile and desktop widths (
resize_page).
- Screenshot after: capture the changed state (
take_screenshot). Pair it with the baseline for the report.
- Console gate (quantitative):
list_console_messages: zero new errors or warnings versus baseline. A pre-existing error is noted, not fixed silently, and never used to excuse a new one.
- Network gate (when the change fetches):
list_network_requests: no failed requests introduced by the change.
- Performance gate (when perf-relevant: new page, heavy asset, list rendering, hydration change): run
lighthouse_audit and report the scores. Regression >5 points on Performance versus baseline is a finding, not a footnote.
Report format
State results per step, with numbers:
UI verification: PASS
- Render: /dashboard loads, no overlay
- Interaction: like button toggles state, count 0 → 1
- Console: 0 new errors (baseline 2 pre-existing warnings, unchanged)
- Screenshots: before/after captured
- Lighthouse: perf 94 (baseline 93); n/a if skipped, say why
A FAIL report names the step, the observed value, and what was expected. Partial verification is reported as NOT verified.
Quality notes
- Prefer quantitative checks (error counts, scores, pixel sizes) over "looks fine": they make self-verification and the two-confirmation gate (score-evidence-guard) possible.
- Browser dialogs (
alert/confirm) block the automation: don't trigger them; use console logging instead.
- This skill composes with
rules/verification-protocol.md: test/lint/build still run; this adds the runtime surface those can't see.
1---2name: verify-frontend3description: Verify UI changes end-to-end in a real browser before declaring them done: dev server, direct interaction, console check, before/after screenshots, Lighthouse when perf-relevant. Use after any frontend/UI change, when user says verify UI, check the page, or does it render. Supersedes generic verify flows for rendered UI. Not for backend-only changes (verification-protocol test/lint/build covers those).4---56# ABOUTME: End-to-end UI verification; never report a UI change done on a green edit or passing tests alone7# ABOUTME: Browser interaction, zero-new-console-errors, before/after screenshots, Lighthouse gate when perf-relevant89# Verify Frontend1011A successful edit and green unit tests do NOT verify a UI change: they can encode the same wrong assumption as the code. Verify the way a human reviewer would, in a real browser, with quantitative checks wherever possible.1213## When1415- After any change touching rendered UI (components, templates, styles, client-side logic)16- Before reporting a UI subtask complete in the orchestrator loop (feeds VERIFY, step 2)17- Skip only for changes with no runtime surface (type-only, test-only, docs)1819## Protocol2021Run every step. A failure at any step means: fix, then rerun **from step 1**. Never hand back partially verified work.2223If the chrome-devtools MCP tools are deferred, load the needed set in ONE ToolSearch call first (`new_page`, `navigate_page`, `take_screenshot`, `list_console_messages`, `list_network_requests`, `resize_page`, `lighthouse_audit`).24251. **Baseline (before the change, when still possible):** start the dev server, open the affected page, screenshot it, record the console error/warning count. If the change is already applied and touches shared layout or navigation (risky: regressions can land outside the edited page), capture a true baseline: `git stash` → screenshot + console count → `git stash pop`, then continue. Otherwise note that the baseline is post-hoc.262. **Load:** open the edited page in the browser (`new_page`/`navigate_page`). The page must render without blank screens or error overlays.273. **Interact:** exercise the change directly. New control (button, input, toggle): click/type into it and confirm the expected state change. Changed layout: resize to mobile and desktop widths (`resize_page`).284. **Screenshot after:** capture the changed state (`take_screenshot`). Pair it with the baseline for the report.295. **Console gate (quantitative):** `list_console_messages`: **zero new errors or warnings** versus baseline. A pre-existing error is noted, not fixed silently, and never used to excuse a new one.306. **Network gate (when the change fetches):** `list_network_requests`: no failed requests introduced by the change.317. **Performance gate (when perf-relevant: new page, heavy asset, list rendering, hydration change):** run `lighthouse_audit` and report the scores. Regression >5 points on Performance versus baseline is a finding, not a footnote.3233## Report format3435State results per step, with numbers:3637```38UI verification: PASS39- Render: /dashboard loads, no overlay40- Interaction: like button toggles state, count 0 → 141- Console: 0 new errors (baseline 2 pre-existing warnings, unchanged)42- Screenshots: before/after captured43- Lighthouse: perf 94 (baseline 93); n/a if skipped, say why44```4546A FAIL report names the step, the observed value, and what was expected. Partial verification is reported as NOT verified.4748## Quality notes4950- Prefer quantitative checks (error counts, scores, pixel sizes) over "looks fine": they make self-verification and the two-confirmation gate (score-evidence-guard) possible.51- Browser dialogs (`alert`/`confirm`) block the automation: don't trigger them; use console logging instead.52- This skill composes with `rules/verification-protocol.md`: test/lint/build still run; this adds the runtime surface those can't see.
maroffo