Verify ui visually
Skill pipipip169/fable5-handoff/sources/adamentwistle-fable-skills/verify-ui-visually
Verify UI changes by rendering and looking — screenshot, browser, or running app — never by reading the markup and imagining it. Use after any change to components, styles, layouts, templates, charts, emails, or generated documents/images.From its SKILL.md
npx -y skills add pipipip169/fable5-handoff --skill verify-ui-visuallyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 28 days oldThe repository was created 28 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.9 KB, 369 tokens by cl100k_base, as published. Nobody here has run it
verify-ui-visually
Code that compiles tells you nothing about what the user sees. "The JSX looks right" is the UI equivalent of "should work" (see verify-before-done).
- Render it and look at it. Run the dev server and take a screenshot (browser tooling,
mcp__chrome-devtools__take_screenshot, or the project's snapshot setup), open the generated PDF/image/email HTML. Reading the diff is not seeing the output. - Look at the actual pixels critically: overflow and truncation, misalignment, spacing collapse, z-index sandwiches, contrast, the loading and empty states — the bugs that no test asserts and every user notices instantly.
- Check the states, not just the happy render: empty (zero items), loaded (typical), overloaded (long strings, many items — "WWWWWWWW" and a 200-char title), error, and loading. Most layout breaks live in empty and overloaded.
- Check both themes and at least two widths when the project supports them: light/dark, mobile/desktop breakpoint. A change verified only in dark-mode desktop ships broken for half the users.
- Interact, don't just render: click the button you changed, submit the form, tab through for focus order. Console errors during the interaction count as failures even when the screen looks fine (see read-what-came-back).
- When you can't render (no display, missing env), say so explicitly in the report and downgrade the claim: "markup changed as requested; not visually verified — needs a look at /settings in the browser."
Rule: a UI change reported as done carries either a screenshot-verified claim or a stated inability to verify. Never the silent middle.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.