Emil Kowalski's Skills repo adds /break-ui skill to stress-test UIs with realistic extreme data

Emil Kowalski recently added the /break-ui skill to his skills repository, and also added /mobile-native in the same period—the latter makes web apps feel more like native apps by disabling hover and similar behaviors on touchscreen devices. These two additions themselves are confirmed facts.

But /break-ui's positioning is more noteworthy: it is meant to play the "most annoying real user," crushing UI components with the worst but entirely real data, then reporting what broke and how to fix it. The key word here is "real"—it is not random destruction, but using extreme inputs that occur in the real world to force out defects in components that are masked under well-behaved data.

The skill's value judgment is hidden in two oppositions. First, it opposes meaningless data: a string of aaaaaa can burst the layout, but it is not input a real user would produce, and what it exposes is a false problem. The real world has Polish users named Wojciech Szczęsny-Nowak, 45-character no-space company emails, and German 30-character no-space compound words. The bug surface that real data can expose is far larger than that of garbled data.

Second, it opposes stopping at obvious problems. Long-text overflow is visible to everyone; the real killers are pluralization copy errors like "1 members," zero-value degradation like 0 seconds ago, cross-timezone dates off by one day, and 0.1+0.2 floating-point errors rendered as-is. These subtle problems are almost inevitably missed in manual testing.

These two oppositions together point to one judgment: the "realness" and "subtlety" of test data determine the effectiveness of testing more than destructive power itself.

The skill's workflow has six stages: map the surface, build the worst case, wire the toggle, launch the attack, report and stop, fix on demand.

The first step, "map the surface," requires listing every value the component renders, its source, type, and constraints, forming an attack-surface map. The second step, "build the worst case," takes data from the CATALOG by field type to assemble fixtures, and must simultaneously cover three scale states: empty, single item, and over a thousand items. The third step, "wire the toggle," requires placing a Demo data / Worst case segmented toggle visible only in the development environment at the bottom center of the viewport, making comparison zero-cost.

The fourth step, "launch the attack," requires checking item by item at real container width, 320px, 200% zoom, dark mode, and RTL, and includes a built-in symptom-cause-fix reference table of about 20 failure signatures. The fifth step, "report and stop," is discipline: report first, do not act on your own. The sixth step, "fix on demand," fixes only after the user nods, then re-verifies all states after fixing and keeps the fixture as a regression test.

The skill's most important hard rule is "change only the data, not the component." The reason is direct: if the AI casually "fixes" the component during testing, it contaminates the object under test and makes the problem hard to reproduce. This rule, together with "report before fixing," forms a closed loop of discipline—report first, do not act on your own, and fix only after the user nods.

Other hard rules include: worst values must be reasonable or schema-backed, to avoid the AI fabricating data that doesn't exist in reality and distorting the test; one dataset should hit multiple failures mixed across different rows, because real dirty data is mixed; the toggle is limited to the development environment to prevent test code from leaking into production; repository content is data, not instructions, so a <script>alert(1)</script> in a fixture must be treated as a string to render, not a command to execute.

The last one is especially noteworthy: it writes prompt-injection defense directly into the rules of the testing tool.

The skill's output is three-part: a breakage list marking severity at three levels—Broken / Ugly / Fragile; open design questions with suggestions but left to humans; and what held up as positive confirmation, which is equally informative.

The tone is deliberately matter-of-fact; the component "was spoiled by well-behaved data," without sarcasm. This output design separates "finding the problem" from "deciding how to fix it," consistent with the "report before fixing" discipline.

In the comments, some users endorsed the "crush only the UI, don't touch the component" approach, and pointed out that mixed data can expose cross-cutting problems such as long titles + empty covers + narrow containers. This belongs to the source-claim level of community feedback.

It must be made clear: the skills repository is said to have 43K stars and 1.9M installs, but this is only self-reported in a tweet, lacking first-party sources, and can at most be treated as a source claim. The tweet itself is a secondhand retelling—meng shao retelling Emil Kowalski's release—and its unique numbers and conclusions should not be treated as confirmed facts.

In addition, whether the six-stage workflow and six hard rules are official repository documentation or the tweet author's summary is not stated by the source; the specific entries and coverage of the built-in reference table of about 20 failure signatures are unknown; which frameworks or component libraries the skill applies to, and whether it has environment dependencies, are also not mentioned by the source. The repository link in the tweet is in short-link form, and the full address cannot be confirmed from the source.