Break UIby Emil Kowalski

Break UI Skill.

Find the interface failures that friendly demo data hides. Break UI gives your coding agent a method for testing real components with plausible extreme values, then presenting the breaks before changing the design.

UI Stress Testing
Edge-Case Fixtures
Review Report

Download OpenDesign View Usage Guide

Source Review · break-uiSKILL.md

Task Design Review & Accessibility Produces • A field inventory with sources, limits and optional values • Worst-case fixtures and a dev-only dataset switcher • Prioritized failures, proposed fixes and decisions for the owner Before You Start Component source, existing demo data and field limits; a running app and browser for visual verification.

Editorial summary · source reviewed 2026-10-12 · not a generated example

01 What It Does

Test the Component, Not a Mocked-Up Failure

This workflow is described in the pinned source. It is not a recorded run or a benchmark.

Source-based workflowNot an execution benchmark

The Working Approach

A member list can work for short names and still lose its action menu when an email is long. Break UI traces every displayed value back to props, fixtures or API data, checks the accepted limits, and replaces the data at that same boundary. It does not alter the layout just to manufacture a failure.

The comparison is meant to stay inspectable: switch between demo and worst-case data, with separate empty, single-item and large-list states where relevant. The report distinguishes unreadable or unreachable content, visual damage and fragile assumptions; it also records what already held up.

Expected Deliverables

A field inventory with sources, limits and optional values
Worst-case fixtures and a dev-only dataset switcher
Prioritized failures, proposed fixes and decisions for the owner

See the Example Brief

From Input to Findings

01
Map Every Displayed Value
Read the component, validation rules and API shapes. Record limits and missing-field behavior, including counts, badges, images and list length—not only text inputs.
02
Build Believable Edge Cases
Combine long names, short names, missing fields and localized labels in a fixture with the same shape as the existing data. Use schema limits where known, and record unbounded fields instead of inventing a limit.
03
Compare at Real Sizes
Keep the switcher in development or a prototype route. Inspect the component’s actual container, 320px and its widest layout, plus enlarged text; include dark mode and RTL if the product supports them.
04
Report Before Repairing
Give each failure a severity, triggering value, proposed fix and file location. Stop for decisions such as wrapping versus truncation; apply fixes only when requested, then retest demo and extreme states.

02 When to Use It

When to Use It

Use it on an existing component whose content varies. This is a data-resilience review, not a visual redesign.

A Good Fit

Dense Lists and CardsMember rows, search results and file cards combine names, metadata, badges and actions that compete for limited space.
Localized InterfacesLong translated labels, non-Latin names and supported RTL layouts can expose assumptions that English demo text misses.
Empty and Large CollectionsCheck zero items, one item, page-size boundaries and a realistic large list, including pluralization and scrolling behavior.

Limits to Check

Not a Taste CritiqueThe skill does not choose a new visual direction or redesign the component. Its findings concern realistic data and the existing design.
No Automatic Product DecisionsWhether a field should wrap, truncate or disappear may require an owner’s decision. The default workflow reports first and stops before applying fixes.
Visual Evidence Needs a BrowserA source-only review can identify risks, but it cannot prove what the user sees. The source requires inferred findings to be distinguished from visually checked failures.

Bring These Inputs

The Actual ComponentProvide the component or screen, its usual container and a working local route. A screenshot alone does not expose the data boundary or validation limits.
Data Shapes and LimitsInclude demo fixtures, props or API types, validation rules and optional fields. Synthetic records are enough; do not supply real customer data.
Supported States and EnvironmentsName the maximum list size, supported languages, dark-mode and RTL requirements. Identify whether the request is report-only or includes approved fixes.

03 Decisions That Matter

Decisions That Matter

Fixtures Enter Through the Real Boundary
Changing a prop or mock response tests the component’s behavior. Editing markup or CSS to force a break would test a different component.
Short and Missing Values Count Too
A single-letter name, absent avatar or count of one can expose initials, fallback and pluralization defects that long strings will never reveal.
The Worst Case Becomes a Regression Fixture
After approved repairs, keep the fixture for later checks and compare it with normal data. The switcher remains development-only and must not ship to production.

04 Try a Focused Brief

Try a Focused Brief

The example brief below has not been tested. Check the skill’s setup before using it.

Review the Setup

Install from Emil Kowalski’s public skills repository and select this skill for your agent.

Scoped Install Command

npx skills@latest add emilkowalski/skills --skill break-ui

The README documents the repository install with npx skills@latest add emilkowalski/skills. The scoped command below selects this entry. It requires Node.js/npm for npx; the source does not pin a minimum version. Inspect the upstream instructions before running it.

Start With One Data-Driven Component

This example brief is original and untested. Replace its component and environment details with your project’s actual context.

Example Brief

Use break-ui on our MemberList component in its existing prototype route. Inspect the prop types and validation limits first. Create synthetic demo and realistic worst-case fixtures covering long and one-letter names, a long example.com email, a missing avatar and role, and supported non-Latin text. Add empty and single-member states, plus the realistic upper list size found in the code. Keep the dataset switcher dev-only and preserve the component markup and styles during testing. Check its actual sidebar width, 320px, the widest supported layout and 200% zoom. Report failures with file locations, proposed fixes and any decisions needed. Separate browser-verified findings from code-based risks, record what held up, and do not apply fixes yet.

Review the Evidence Before Fixing

Check the report against the code and actual browser behavior. Keep unverified observations separate from reproduced failures.

Every tested field has a real source and a documented limit or an explicit unknown.
Switching data reaches the same component boundary; the control is confined to development or a prototype.
Findings include the failing value, location and evidence; normal data and passing cases are not omitted.

OpenDesign provides a local design workspace for coding agents. This listing does not mean the skill is bundled or that its external tools, credentials and software dependencies are included.

Download OpenDesign Read the Quickstart

05 Source and License

Source and License

This page describes the pinned source revision linked below. Upstream behavior and requirements can change.

Source Owner: Emil Kowalski
Repository: emilkowalski/skills
Skill File: skills/break-ui/SKILL.md
License: MIT
Reviewed Snapshot: 2026-10-12 · 2d228630ba14

Editorial Source Summary

Stress-test existing UI with realistic extreme data and a dev-only comparison toggle; report failures before fixing them. This is an editorial summary of the pinned source, not an execution report.

Original summary by OpenDesign, based on the linked source. Repository stars are a dated popularity signal, not skill usage or a quality score.

06 Questions Before You Start

Questions Before You Start

Does Break UI automatically fix the component?

Not by default. It reports failures and proposed fixes, then waits. The source also supports an explicit fix request; decisions with more than one valid answer still need to be resolved.

Does it only test long text?

No. Its catalog covers missing values, numbers, collections, time, media, states and environment. Empty and one-item lists are separate cases, not substitutes for a long-text fixture.

Can I run it without a project?

The source allows a standalone component and self-contained HTML comparison. Without browser access, findings must be marked as inferred rather than visually verified.

Break UI

Try Data the Demo Did Not Anticipate

Start with one component and realistic synthetic records. Review what fails, choose the fixes and keep the fixture for the next change.

Download OpenDesign Browse Design Skills