LLMSkillHub
mirroredCopied from nahid-sparktales/agent-dispatcher under MIT. nahid-sparktales has not claimed this page, and is not affiliated with LLM SkillHub.

nahid-sparktales / browser-verification

Prove a UI change actually renders and works — desktop and mobile, controls operated, console clean. Use before reporting any change to rendered UI as done, when asked whether a screen actually functions, or when checking someone else's frontend work. Not for judging whether a design is good, and not a substitute for tests you intend to keep.

0
SKILL.md
3.8 KB

Browser verification

Reading the source is not verification. A component that compiles, type-checks and looks right in
the diff can still render blank, overflow its container, or throw on mount.

When this fires

After any change to rendered UI, before that change is reported as working — your own work or
someone else's. It does not fire for a change with no rendered surface. One change, checked
once, is this skill; a matrix of states across viewports and themes, or a comparison against a
screenshot baseline, is visual-verification.

Procedure

  1. Get it running. Start the dev server or open the deployed URL. If it will not start, that
    is the finding: report it and stop the verification — never verify a stale build. The work
    under test is then reported as unverified, not as failed.

  2. Render the route that changed, not the home page. Wait for network idle before judging.

  3. Read the console and network first, before looking at pixels. An error here explains most
    of what you are about to see. Record the exact message, not "some errors".

  4. Inspect desktop. Screenshot. Does the intended change appear; is anything clipped or
    overlapping; does content overflow; did images and fonts load.

  5. Inspect mobile. Resize to 375×812 and reload — layout-time breakpoints and device gates
    do not re-run on resize alone. Same checks, plus: horizontal scrolling, tap-target reachability,
    text legibility.

  6. Operate every control the change touches. Click the primary action, submit the form, open
    the menu, type in the input. A control that renders and does nothing is the most common failure
    this procedure exists to catch.

  7. Reach the states that are not the happy path — empty, loading, error, long content — by the
    cheapest honest route available.

  8. Re-read the console after interacting. Errors thrown on click do not appear on load.

  9. Fix what you found, then start again from step 2. A fix is not verified by the reasoning
    that produced it.

Checklist

  • [ ] The changed route was rendered, not just built
  • [ ] Desktop screenshot taken and read
  • [ ] Mobile viewport reloaded and read
  • [ ] Every control the change touches was actually operated
  • [ ] Console checked on load and again after interaction
  • [ ] Empty / loading / error states reached, or named as unchecked
  • [ ] Everything still unverified is named in the report

Failure handling

  • Server will not start, or the URL is unreachable — that is the result. Do not fall back to
    reading source and calling it verified.

  • Screenshot looks right but a control does nothing — trust the interaction, not the picture.
    Check the console: a handler that throws renders identically to one that works.

  • The failure will not reproduce — say so, with what you tried. An intermittent failure
    reported as fixed is worse than one reported as intermittent.

  • No browser tooling available — say rendered verification could not be performed, name what
    you did check, and do not call the change verified. Degrading honestly beats a false pass.

Evidence to report

The route and viewports checked; what each control did when operated; console output quoted, or
"clean" if it genuinely was; screenshots where they show what words cannot; and the list of states
and paths not checked. "Verified in the browser" with none of that is not evidence.

See references/driving-the-browser.md for which tool to reach for.