Eyes - Visual Feedback Loop

Capture screenshots and collaborate with users on visual refinements. Treat specific feedback and explicit implementation approval in the user's current request as already supplied. Whenever you block on a missing fact or decline a request, state the reason, so the user can act on it.

Use the capture tool ladder below to take the screenshots. Do not skip this skill when Playwright MCP is unavailable.

Scope

This skill runs an interactive loop with a person. It applies to a defect someone reports and to visual iteration you drive yourself. Capture the current state. Agree the change with the user. Confirm the result with that same user.

This skill does not cover unattended automated test suites. Decline a request to build an unattended visual regression suite, to choose its snapshot tool, to define its baseline update process, or to set its pixel diff threshold. Choosing a capture tool for an interactive session stays in scope; the ladder below covers that choice. Design no part of the suite, not even as a sketch or an aside. Redirect the request to a real-browser end-to-end testing workflow, such as Playwright or Cypress visual comparisons. Do not redirect it to web:frontend-testing, which covers DOM tests in a test runner and declines visual work. Offer the in-scope help instead: capture and compare a specific state whenever someone wants to see a visual change.

Workflow

1. Collect the reproduction facts — Collect the facts the requested comparison needs: route, viewport, browser, operating system, theme, data, and interaction state, plus the expected result and the observed result. When the request already supplies the change and the state, do not ask for facts the comparison does not need. Ask the reporter for every fact you still need. When someone reports a defect, ask that person for a screenshot of it, or for the steps that reproduce it. Tell the reporter why you need these facts: a capture of a guessed state can neither confirm nor rule out the reported defect. Do not guess a state.

2. Capture the reported state — Reproduce the route, viewport, theme, data, and interaction state with the first available tool in the capture ladder. Name the ladder rung you used. Match the reported browser and operating system. When you cannot match them, report the difference as a proof gap. For a viewport narrower than 500px in Chrome headless, use an iframe harness or CDP device emulation, as rung 2 explains. Never trust a plain --window-size capture at that width. For focus- or interaction-dependent states, record an accessibility snapshot or equivalent state evidence. Report unavailable evidence as a proof gap.

3. Check that the capture can show the defect — A capture counts as evidence only when the target can appear in it. Capture the phase the report names. For a defect in the settled state, wait until the animation or transition has finished. For a defect during the movement, capture at the reported point in the transition. When the phase is unknown, capture during the transition and after it. Capture before any auto-dismiss removes the target. Confirm the target is present in the image and rendered at non-zero size. When the target cannot appear — a hidden tab, a collapsed container, a zero-sized element, or a component that is not mounted yet — put the page into a state that shows it. Capture again. Discard a capture that fails these checks, because it proves nothing.