Skill: Verify Frontend Change

Never report a UI change as complete based on a successful edit alone. A green typecheck proves the code compiles, not that the pixel moved, the button fires, or the console stayed clean. Verify it the way a human reviewer would — in a real browser.

Detection — When to Activate

Activate this skill when:

• You edited a component, page, route, style, layout, or interactive control
• You're about to say a frontend task is "done", "fixed", "working", or "shipped"
• You added or changed a control (button, input, toggle, modal, dropdown, form)
• A change is theme-, responsive-, or state-dependent (dark mode, mobile, loading/empty/error)

Do NOT activate for:

• Pure backend / API / data-layer changes with no rendered surface
• Docs, comments, config, or type-only changes that don't alter output
• Copy-only edits already confirmed by reading the diff (still glance at the rendered page)

The Protocol

Run these in order. Do not skip ahead.

1. Open the change in a real browser

Start the dev server and open the edited page — not the home page, the actual route you touched.

npm run dev        # or the project's equivalent (Vite / Next / etc.)
# then open the specific path you changed, e.g. http://localhost:3000/settings

Confirm the page renders and the change is visibly present. If it isn't there, stop — the edit didn't take effect (wrong file, HMR stale, build cache).

2. Interact with the change directly

Reading the DOM is not interacting. Drive it:

• New control (button / input / toggle / dropdown): click or type into it, then confirm the expected state change actually happened (value updates, panel opens, request fires, list re-renders).
• Screenshot before and after the interaction. The diff between the two is your evidence.
• Exercise the states that matter for this change: loading, empty, error, hover/focus, disabled.
• Check dark mode and mobile width if the change touches layout, color, or spacing.

3. Check the browser console

Open DevTools → Console. Requirement: zero new errors or warnings introduced by your change.

• React key warnings, hydration mismatches, act() warnings, failed network requests, 404s on assets — all count as failures.
• Compare against a baseline if the page already logs noise; only new messages are on you.

4. Run a performance pass

If a Chrome DevTools MCP (or equivalent browser-automation tool) is available, use it to record a performance trace and audit Core Web Vitals (LCP, INP, CLS). Prefer whatever project-specific wrapper already drives that tooling over hand-rolling a trace from scratch — but if none exists, run the MCP/Lighthouse directly rather than skipping the step.

• Flag regressions: layout shift from the new element, a slow interaction (INP), a render-blocking asset you introduced.
• Scale the rigor to the change: a one-line copy fix doesn't need a full trace; a new above-the-fold component or a data-heavy view does.

The Rule

If any step fails, fix the issue and rerun from step 1. Do not hand back partially verified work, and do not report the earlier steps as passing when a later one is still red — the change is either fully verified or it is not done.

Verification Checklist

State this back before declaring done:

If any row is blank, the task is not done.

Anti-Patterns

Gotchas

• HMR can lie. Hot-reload sometimes shows a stale render or a half-applied change. If something looks off, hard-refresh (or restart the dev server) before concluding your code is wrong.
• Open the right port/route. In multi-service projects, each service can run on its own fixed port. Verifying on the wrong port silently shows an old build from a different service — confirm the URL actually maps to the project you edited.
• Content baked at boot. Some projects compile content (Markdown, CMS data) into a database or bundle at server startup rather than serving it live. A content edit won't appear until that process restarts — a blank or stale page here is a restart problem, not a frontend bug.
• Dark mode and mobile are separate surfaces. A change that looks right in light/desktop can break contrast or overflow in dark/mobile — check both whenever the change touches color, spacing, or layout.
• Scrollable tables and anchor offsets are easy to skip. If the project has house rules for these (e.g. wide tables get overflow-x: auto instead of blowing out page width, anchor links use scroll-margin-top on the heading so it lands visible under a sticky nav), verify they still hold after your change.
• Chrome DevTools MCP may be absent in headless/cron/CI runs. If the perf tooling isn't reachable, say so explicitly and fall back to a manual Lighthouse or visual check — don't silently skip step 4 and imply it passed.
• Screenshots are the deliverable, not decoration. When you report the change as verified, attach or reference the before/after so the claim is auditable — "I verified it" without artifacts is the thing this skill exists to prevent.