making-ui-changes

Guides UI changes through reuse, state coverage, blast-radius checks, and visual test verification.

21|1|Updated Jul 22, 2026
One-click install
npx skills add https://github.com/uiverify/uiverify --skill making-ui-changes-uiverify
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: making-ui-changes
Source: https://github.com/uiverify/uiverify/tree/main/packages/skills/skills/making-ui-changes
Command: npx skills add https://github.com/uiverify/uiverify --skill making-ui-changes-uiverify

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? UI changes often silently break unrelated screens because shared components drift, states go untested, and regressions slip past review. This Skill enforces a five-step discipline so every component, page, or style change is verified visually before it ships. ## Core Features & Use Cases - Reuse-First Discipline: Search for and extend existing components with variants or props instead of creating near-duplicates that drift apart. - Same-Change State Coverage: Every new or changed component state gets a story or capture in the same change, never as a follow-up. - Blast Radius Analysis: Grep importers of shared components to identify every affected screen and confirm each has visual coverage. - Visual Verification & Flake Control: Prove changes with visual diffs and fix flaky captures (clocks, live data, animations) at the source instead of accepting them. - Use Case: Before editing a shared Button component, run these five moves to extend it with a variant, add stories for all states, check every importing screen, and confirm the visual diff only shows intended changes. ## Quick Start Ask the agent to read the making-ui-changes guidance before modifying any component, page, or stylesheet in the project.

Frequently Asked Questions about making-ui-changes

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I change a shared UI component without breaking other screens?▼

Grep for all importers of the shared component to map the blast radius, then confirm each affected screen has a story or capture so visual diffs catch regressions. Extend the component with a variant or prop rather than creating a near-copy.

How to prevent visual regressions when editing components?▼

Add or update a story or capture for every changed state in the same change, then verify with a visual diff before merging. Any story that changed unexpectedly is a stop-and-inspect signal, not something to accept blindly.

Should I create a new component or extend an existing one?▼

Extend the existing component with a variant or new prop whenever one fits, since two components that look the same drift apart over time. Build net-new only when nothing existing fits the requirement.

Why do visual tests show changes when nothing actually changed?▼

Flaky captures come from nondeterministic sources like clocks, live data, animations, or randomness in the story. Fix the flake at capture time by mocking or freezing these sources rather than accepting the diff or disabling the check.

When should visual test coverage be added for a UI change?▼

Coverage belongs in the same change as the component or state edit, never as a follow-up task. Generate stories densely across states rather than hand-writing one per combination.