Break UIvon Emil Kowalski

Break UI Skill.

Finden Sie die Oberflächenfehler, die freundliche Demodaten verbergen. Break UI gibt Ihrem Coding-Agenten eine Methode, echte Komponenten mit plausiblen Extremwerten zu testen und die Brüche aufzuzeigen, bevor das Design geändert wird.

UI-Stresstests
Edge-Case-Fixtures
Prüfbericht

OpenDesign herunterladen Nutzungsanleitung ansehen

Quellenprüfung · break-uiSKILL.md

Aufgabe Design-Review & Barrierefreiheit Ergebnis • Ein Feldinventar mit Quellen, Grenzen und optionalen Werten • Worst-Case-Fixtures und ein Datensatz-Umschalter nur für die Entwicklung • Priorisierte Fehler, vorgeschlagene Korrekturen und Entscheidungen für die verantwortliche Person Bevor Sie beginnen Komponentenquellcode, vorhandene Demodaten und Feldgrenzen; eine laufende App und ein Browser zur visuellen Überprüfung.

Redaktionelle Zusammenfassung · Quelle geprüft 2026-10-12 · kein generiertes Beispiel

01 – Was er leistet

Die Komponente testen, nicht einen nachgebauten Fehler

Dieser Ablauf ist in der fixierten Quelle beschrieben. Es ist weder ein aufgezeichneter Lauf noch ein Benchmark.

Quellenbasierter AblaufKein Ausführungs-Benchmark

Die Arbeitsweise

Eine Mitgliederliste kann bei kurzen Namen funktionieren und dennoch ihr Aktionsmenü verlieren, wenn eine E-Mail-Adresse lang ist. Break UI verfolgt jeden angezeigten Wert zurück zu Props, Fixtures oder API-Daten, prüft die zulässigen Grenzen und ersetzt die Daten an genau dieser Schnittstelle. Das Layout wird nicht verändert, nur um einen Fehler zu erzeugen.

Der Vergleich soll nachvollziehbar bleiben: Es wird zwischen Demodaten und Worst-Case-Daten umgeschaltet, bei Bedarf mit separaten Zuständen für leer, einzelnes Element und große Liste. Der Bericht unterscheidet unlesbare oder unerreichbare Inhalte, optische Schäden und fragile Annahmen; er hält auch fest, was bereits standgehalten hat.

Erwartete Ergebnisse

Ein Feldinventar mit Quellen, Grenzen und optionalen Werten
Worst-Case-Fixtures und ein Datensatz-Umschalter nur für die Entwicklung
Priorisierte Fehler, vorgeschlagene Korrekturen und Entscheidungen für die verantwortliche Person

Beispielbriefing ansehen

Von der Eingabe zu den Befunden

01
Jeden angezeigten Wert erfassen
Lesen Sie Komponente, Validierungsregeln und API-Strukturen. Halten Sie Grenzen und das Verhalten bei fehlenden Feldern fest, einschließlich Zahlen, Badges, Bildern und Listenlänge – nicht nur Texteingaben.
02
Glaubwürdige Edge Cases bauen
Kombinieren Sie lange Namen, kurze Namen, fehlende Felder und lokalisierte Labels in einem Fixture mit derselben Struktur wie die vorhandenen Daten. Nutzen Sie Schema-Grenzen, wo bekannt, und vermerken Sie unbegrenzte Felder, statt eine Grenze zu erfinden.
03
In realen Größen vergleichen
Belassen Sie den Umschalter in der Entwicklung oder auf einer Prototyp-Route. Prüfen Sie den tatsächlichen Container der Komponente, 320 px und das breiteste Layout sowie vergrößerten Text; beziehen Sie Dark Mode und RTL ein, falls das Produkt sie unterstützt.
04
Erst berichten, dann reparieren
Geben Sie jedem Fehler Schweregrad, auslösenden Wert, vorgeschlagene Korrektur und Dateiort. Halten Sie bei Entscheidungen wie Umbruch oder Kürzung an; wenden Sie Korrekturen nur auf Anfrage an und testen Sie danach Demo- und Extremzustände erneut.

02 – Wann er sich eignet

Wann er sich eignet

Nutzen Sie ihn für eine bestehende Komponente mit variierendem Inhalt. Es ist eine Prüfung der Datenrobustheit, kein visuelles Redesign.

Gut geeignet

Dichte Listen und KartenMitgliederzeilen, Suchergebnisse und Dateikarten kombinieren Namen, Metadaten, Badges und Aktionen, die um begrenzten Platz konkurrieren.
Lokalisierte OberflächenLange übersetzte Labels, nicht-lateinische Namen und unterstützte RTL-Layouts können Annahmen offenlegen, die englischer Demotext übersieht.
Leere und große SammlungenPrüfen Sie null Elemente, ein Element, Seitengrößen-Grenzen und eine realistisch große Liste, einschließlich Pluralisierung und Scrollverhalten.

Zu beachtende Grenzen

Keine GeschmackskritikDer Skill wählt keine neue visuelle Richtung und gestaltet die Komponente nicht neu. Seine Befunde betreffen realistische Daten und das bestehende Design.
Keine automatischen ProduktentscheidungenOb ein Feld umbrechen, gekürzt werden oder entfallen soll, kann eine Entscheidung der verantwortlichen Person erfordern. Der Standardablauf berichtet zuerst und hält an, bevor Korrekturen angewendet werden.
Visuelle Belege brauchen einen BrowserEine reine Quellcode-Prüfung kann Risiken erkennen, aber nicht belegen, was Nutzende sehen. Die Quelle verlangt, abgeleitete Befunde von visuell geprüften Fehlern zu unterscheiden.

Diese Eingaben mitbringen

Die tatsächliche KomponenteStellen Sie die Komponente oder den Screen, ihren üblichen Container und eine funktionierende lokale Route bereit. Ein Screenshot allein zeigt weder die Datenschnittstelle noch Validierungsgrenzen.
Datenstrukturen und GrenzenFügen Sie Demo-Fixtures, Props oder API-Typen, Validierungsregeln und optionale Felder bei. Synthetische Datensätze genügen; liefern Sie keine echten Kundendaten.
Unterstützte Zustände und UmgebungenNennen Sie die maximale Listengröße, unterstützte Sprachen sowie Anforderungen an Dark Mode und RTL. Geben Sie an, ob die Anfrage nur einen Bericht oder auch freigegebene Korrekturen umfasst.

03 – Entscheidungen, die zählen

Entscheidungen, die zählen

Fixtures gelangen über die echte Schnittstelle hinein
Das Ändern einer Prop oder Mock-Antwort testet das Verhalten der Komponente. Markup oder CSS zu bearbeiten, um einen Bruch zu erzwingen, würde eine andere Komponente testen.
Kurze und fehlende Werte zählen auch
Ein einbuchstabiger Name, ein fehlender Avatar oder eine Anzahl von eins können Fehler bei Initialen, Fallbacks und Pluralisierung zeigen, die lange Strings nie aufdecken.
Der Worst Case wird zum Regressions-Fixture
Behalten Sie das Fixture nach freigegebenen Reparaturen für spätere Prüfungen und vergleichen Sie es mit normalen Daten. Der Umschalter bleibt nur für die Entwicklung und darf nicht in die Produktion gelangen.

04 – Ein fokussiertes Briefing ausprobieren

Ein fokussiertes Briefing ausprobieren

Das folgende Beispielbriefing wurde nicht getestet. Prüfen Sie die Einrichtung des Skills, bevor Sie es verwenden.

Einrichtung prüfen

Aus dem öffentlichen Skills-Repository von Emil Kowalski installieren und diesen Skill für Ihren Agenten auswählen.

Eingegrenzter Installationsbefehl

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

Die README dokumentiert die Repository-Installation mit npx skills@latest add emilkowalski/skills. Der folgende eingegrenzte Befehl wählt diesen Eintrag aus. Er benötigt Node.js/npm für npx; die Quelle legt keine Mindestversion fest. Prüfen Sie die Upstream-Anleitung, bevor Sie ihn ausführen.

Mit einer datengetriebenen Komponente beginnen

Dieses Beispielbriefing ist original und ungetestet. Ersetzen Sie Komponenten- und Umgebungsdetails durch den tatsächlichen Kontext Ihres Projekts.

Beispielbriefing

Verwende break-ui für unsere MemberList-Komponente in ihrer bestehenden Prototyp-Route. Prüfe zuerst die Prop-Typen und Validierungsgrenzen. Erstelle synthetische Demo- und realistische Worst-Case-Fixtures mit langen und einbuchstabigen Namen, einer langen example.com-E-Mail-Adresse, fehlendem Avatar und fehlender Rolle sowie unterstütztem nicht-lateinischem Text. Ergänze Zustände für leer und einzelnes Mitglied sowie die im Code gefundene realistische obere Listengröße. Halte den Datensatz-Umschalter nur für die Entwicklung und bewahre Markup und Styles der Komponente während des Tests. Prüfe die tatsächliche Seitenleistenbreite, 320 px, das breiteste unterstützte Layout und 200 % Zoom. Berichte Fehler mit Dateiorten, vorgeschlagenen Korrekturen und nötigen Entscheidungen. Trenne im Browser verifizierte Befunde von codebasierten Risiken, halte fest, was standgehalten hat, und wende noch keine Korrekturen an.

Belege prüfen, bevor repariert wird

Gleichen Sie den Bericht mit dem Code und dem tatsächlichen Browserverhalten ab. Halten Sie nicht verifizierte Beobachtungen getrennt von reproduzierten Fehlern.

Jedes getestete Feld hat eine echte Quelle und eine dokumentierte Grenze oder ein ausdrücklich unbekanntes Limit.
Das Umschalten der Daten erreicht dieselbe Komponentenschnittstelle; das Steuerelement ist auf Entwicklung oder einen Prototyp beschränkt.
Befunde enthalten den fehlerhaften Wert, den Ort und Belege; normale Daten und bestandene Fälle werden nicht ausgelassen.

OpenDesign bietet einen lokalen Design-Arbeitsbereich für Coding-Agenten. Dieser Eintrag bedeutet nicht, dass der Skill mitgeliefert wird oder dass externe Tools, Zugangsdaten und Software-Abhängigkeiten enthalten sind.

OpenDesign herunterladen Quickstart lesen

05 – Quelle und Lizenz

Quelle und Lizenz

Diese Seite beschreibt die unten verlinkte fixierte Quellrevision. Upstream-Verhalten und -Anforderungen können sich ändern.

Quellen-Inhaber: Emil Kowalski
Repository: emilkowalski/skills
Skill-Datei: skills/break-ui/SKILL.md
Lizenz: MIT
Geprüfter Stand: 2026-10-12 · 2d228630ba14

Redaktionelle Zusammenfassung der Quelle

Bestehende UI mit realistischen Extremdaten und einem Vergleichsschalter nur für die Entwicklung stresstesten; Fehler berichten, bevor sie behoben werden. Dies ist eine redaktionelle Zusammenfassung der fixierten Quelle, kein Ausführungsbericht.

Originalzusammenfassung von OpenDesign auf Grundlage der verlinkten Quelle. Repository-Sterne sind ein datiertes Popularitätssignal, keine Skill-Nutzung und keine Qualitätsbewertung.

06 – Fragen vor dem Start

Fragen vor dem Start

Behebt Break UI die Komponente automatisch?

Standardmäßig nicht. Er berichtet Fehler und vorgeschlagene Korrekturen und wartet dann. Die Quelle unterstützt auch eine ausdrückliche Reparaturanfrage; Entscheidungen mit mehr als einer gültigen Antwort müssen weiterhin geklärt werden.

Testet er nur lange Texte?

Nein. Sein Katalog umfasst fehlende Werte, Zahlen, Sammlungen, Zeit, Medien, Zustände und Umgebung. Leere Listen und Listen mit einem Element sind eigene Fälle, kein Ersatz für ein Fixture mit langem Text.

Kann ich ihn ohne Projekt ausführen?

Die Quelle erlaubt eine eigenständige Komponente und einen in sich geschlossenen HTML-Vergleich. Ohne Browserzugriff müssen Befunde als abgeleitet statt visuell verifiziert gekennzeichnet werden.

Break UI

Daten testen, die die Demo nicht vorhergesehen hat

Beginnen Sie mit einer Komponente und realistischen synthetischen Datensätzen. Prüfen Sie, was fehlschlägt, wählen Sie die Korrekturen und behalten Sie das Fixture für die nächste Änderung.

OpenDesign herunterladen Design-Skills durchsuchen