The skills are runtime-free. They use whatever browser and quality tooling a target project already has. Add integrations only when their signal justifies their installation and maintenance.
Every substantial interface change should pass:
- The primary flow in a real browser
- Narrow, intermediate, and wide layouts
- Keyboard-only operation and visible focus
- Reduced-motion behavior
- Loading, empty, error, and long-content states in scope
- Existing tests, lint, type checks, and production build
- A final visual comparison against the brief and
DESIGN.md
Source review cannot replace the rendered pass.
Use deterministic Playwright tests for behavior that must not regress:
- Navigation and task completion
- Dialog, menu, tab, and form behavior
- Responsive state changes
- ARIA snapshots for stable semantic structures
- Reviewed screenshots for a small number of high-value states
Keep screenshot baselines on one pinned operating system, browser, font set, locale, and timezone. Rendering varies across environments.
Playwright MCP is useful for exploratory agent inspection and longer browser sessions. It is not a deterministic CI runner or a security boundary.
If a team chooses it:
- Pin the package version.
- Use an isolated browser profile.
- Do not expose credentials or private browsing state.
- Limit accessible origins.
- Convert repeated exploratory checks into normal Playwright tests.
- Prefer the lighter CLI or existing browser tools when MCP schemas consume unnecessary context.
Do not add an MCP configuration automatically. Each agent stores MCP configuration differently, and enabling a browser server changes the local trust boundary.
Use axe-core directly when the project has browser tests, or Storybook's accessibility addon when Storybook is already the component harness. Do not add both by default.
Automated checks can identify many semantic, naming, and contrast failures, but they do not prove:
- Logical reading and focus order
- Useful alternative text
- Correct announcements
- Clear error recovery
- Appropriate target sizes
- Usability at zoom or with assistive technology
Pair automation with keyboard and screen-reader-oriented inspection of the primary flow. Treat WCAG 2.2 AA as a baseline when the product has not declared another target.
Use Lighthouse CI for repeatable budgets after a production build. Prefer ranges or regression budgets over a universal score:
- Largest Contentful Paint
- Cumulative Layout Shift
- Total Blocking Time or Interaction to Next Paint evidence
- Asset and JavaScript budgets
- Best-practice regressions
Run multiple samples because local and CI measurements vary. Avoid the default temporary public report storage for private products.
Use browser performance traces for a specific animation or interaction. Do not infer runtime cost from a CSS property name alone.
Storybook is valuable when the product already develops components in isolation. Use it to cover:
- Visual and semantic variants
- Loading, empty, error, and long-content states
- Theme and responsive stories
- Interaction tests
- Accessibility checks
Do not initialize Storybook solely to improve one page. Its configuration, dependencies, and story maintenance are a product-level choice.
Keep the baseline set small and meaningful:
- One representative state per major composition
- Stable deterministic content
- Masks only for genuinely nondeterministic regions
- Reviewed threshold changes
Pixel stability is not design quality. A screenshot can match while the task, semantics, or content is wrong.
Use blinded pairwise comparison for subjective improvement when possible. Ask:
- Which version makes the task clearer?
- Which feels more specific to the product?
- Which has a stronger hierarchy?
- Which remains coherent across widths and states?
Record disagreement. Do not collapse visual quality into one model-generated score.