Zur Nutzungsanleitung springen
Anti UI Slopvon UIZZE

Anti UI Slop Skill.

Beginnen Sie mit den tatsächlichen Objekten und Einschränkungen des Produkts, bevor Sie eine visuelle Gestaltung wählen.

  • UI-Design
  • Design-Review
Quellenprüfung · Anti UI SlopSKILL.md
Aufgabe UI-Design Ergebnis • Eine produktbezogene Überarbeitung der Oberfläche oder eine gezielte Kritik • Designentscheidungen, die an vorhandene Tokens, Komponenten und Nutzeraufgaben gebunden sind • Eine knappe Übergabe, die beobachtbare Probleme und gelöste Änderungen benennt Vor dem Start Ein Agent, der Projektdateien lesen kann; Rendering-Unterstützung für visuelle Prüfungen. Das kostenpflichtige UIZZE MCP ist optional.
Redaktionelle Zusammenfassung · Quelle geprüft 2026-10-07 · kein generiertes Beispiel

01 Funktionen

Interface-Entscheidungen im Produkt verankern

Ein produktorientierter UI-Workflow, der einen aufgabenspezifischen Leitfaden auswählt, optional UIZZE-Referenzen nutzt und die gerenderte Oberfläche prüft.

Quellenbasierter WorkflowKein Ausführungs-Benchmark

Die Arbeitsweise

Anti UI Slop ist ein kompakter Workflow zum Erstellen, Verfeinern oder Prüfen einer Oberfläche, ohne die Identität des Produkts durch eine generische KI-Ästhetik zu ersetzen. Der Agent soll zuerst den Brief, vorhandene Screens, Komponenten und Design-Tokens prüfen. Diese Vorgaben haben Vorrang vor den Beispielen des Skills und sind daher besonders für Arbeiten in einer etablierten Anwendung relevant.

Die Quelle leitet jede Anfrage an ein Playbook weiter: Neuentwicklung, Produktbedienung, Feinschliff, Vereinfachung, Audit oder natives iOS. Der Agent soll nicht alle Checklisten kombinieren. Optionale UIZZE-Referenztools können eine konkrete offene visuelle Frage beantworten, doch der kostenlose Skill und der öffentliche Katalog erfordern kein Konto. Die letzte Prüfung betrifft beobachtbares Verhalten der Oberfläche, etwa abgeschnittene Elemente, Überlappungen und Bedienelemente ohne Funktion.

Erwartete Ergebnisse

  • Eine produktbezogene Überarbeitung der Oberfläche oder eine gezielte Kritik
  • Designentscheidungen, die an vorhandene Tokens, Komponenten und Nutzeraufgaben gebunden sind
  • Eine knappe Übergabe, die beobachtbare Probleme und gelöste Änderungen benennt
Beispiel-Brief ansehen

Vom Brief zum Review

  1. 01
    Produktkontext lesen

    Prüfen Sie den angefragten Screen und das umgebende Designsystem. Klären Sie, was Nutzer erreichen wollen, bevor Sie Layout oder Styling ändern.

  2. 02
    Einen Arbeitsmodus wählen

    Wählen Sie das Playbook, das zur Anfrage passt. Ein Polish-Durchgang sollte nicht unbemerkt zum Redesign werden, und ein Audit bleibt eine Kritik, sofern keine Umsetzung gewünscht ist.

  3. 03
    Gerendertes Ergebnis prüfen

    Wenn die Umgebung es erlaubt, prüfen Sie die tatsächliche Oberfläche einmal und beheben sichtbare Fehler, nicht zugängliche Bedienelemente und wirkungslose Interaktionen.

02 Einsatzbereiche

Wann Sie es nutzen

Ein Agent, der Projektdateien lesen kann; Rendering-Unterstützung für visuelle Prüfungen. Das kostenpflichtige UIZZE MCP ist optional.

Gut geeignet

  • Bestehende Produkt-ScreensNützlich, wenn ein Agent ein Dashboard oder einen Workflow erweitern soll, ohne ein konkurrierendes Designsystem zu erfinden.
  • Gezielte VerfeinerungPasst, wenn ein bestimmter Screen vereinfacht oder poliert werden soll und seine etablierte Funktionalität erhalten bleibt.

Zu prüfende Grenzen

  • Referenzen sind optionalDas kostenpflichtige UIZZE MCP ist eine separate Verbindung. Die Installation dieses Skills verschafft keinen Zugang zu gehosteten Referenztools.
  • Kein automatisches DesignurteilDie Quelle beschreibt eine Arbeitsmethode, keine Garantie, dass jede generierte Oberfläche eigenständig oder barrierefrei ist.
  • Lizenzhinweise weichen voneinander abSKILL.md deklariert MIT, während die LICENSE im Skill-Verzeichnis Apache-2.0-Bedingungen enthält. Bitten Sie die Maintainer vor einer Wiederverwendung um Klärung der geltenden Bedingungen.

Diese Eingaben mitbringen

  • Ein konkreter ScreenGeben Sie einen Dateipfad, einen Screenshot oder eine kurze Beschreibung der Oberfläche an, die erstellt oder geprüft werden soll.
  • Bestehende DesignspracheNennen Sie Komponentenkonventionen, Tokens und Beispiele akzeptierter Produkt-UI.
  • Umfang der ÄnderungWählen Sie Neuentwicklung, Redesign, Feinschliff, Vereinfachung oder Audit, damit der Agent die Aufgabe nicht ausweitet.

03 Wichtige Entscheidungen

Entscheidungen, auf die es ankommt

  1. Produkt vor Neuheit

    Vertraute Konventionen bleiben erhalten, wenn sie dem Workflow helfen. Unterscheidbarkeit entsteht durch produktspezifische Hierarchie, nicht durch Dekoration.

  2. Ein Playbook nach dem anderen

    Das explizite Routing verringert widersprüchliche Anweisungen und verhindert, dass eine kleine Verfeinerung unzusammenhängende Redesign-Anforderungen ansammelt.

04 Beispielbriefing

Mit einem gezielten Brief ausprobieren

Der folgende Beispiel-Brief wurde nicht getestet. Prüfen Sie die Einrichtung des Skills, bevor Sie ihn verwenden.

Einrichtung prüfen

Verwenden Sie den vollständigen Skill-Ordner, damit das ausgewählte Playbook verfügbar ist. Der kostenlose Workflow benötigt weder Abhängigkeiten noch ausführbare Dateien.

Upstream-Quelldatei
https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/skills/anti-ui-slop/SKILL.md

Ein Agent, der Projektdateien lesen kann; Rendering-Unterstützung für visuelle Prüfungen. Das kostenpflichtige UIZZE MCP ist optional.

Mit einem Ergebnis beginnen

Passen Sie Umfang, Quellenmaterial und Vorgaben in diesem Brief an, bevor Sie den Skill ausführen.

Beispiel-Brief
Nutze anti-ui-slop, um unsere Rechnungslisten-Ansicht zu polieren. Lies zuerst die vorhandenen Tabellen-, Filter- und Button-Komponenten. Bewahre die Informationsarchitektur und den Zahlungsworkflow. Verwende ausschließlich das Polish-Playbook, benenne das wichtigste Hierarchieproblem, setze eine zurückhaltende Korrektur um und prüfe Abschneidungen, Tastaturbedienung und das Verhalten des Leerzustands. Verbinde keinen kostenpflichtigen Referenzdienst.

Ergebnis prüfen

Prüfen Sie die tatsächliche Ausgabe anhand dieser beobachtbaren Kriterien.

  • Vorhandene Komponenten- und Token-Konventionen bleiben erkennbar.
  • Das gewählte Playbook entspricht dem angefragten Umfang.
  • Der gerenderte Screen zeigt im geprüften Ablauf keine beobachteten Abschneidungen, Überlappungen oder wirkungslosen Bedienelemente.

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.

05 Quelle und Lizenz

Quelle und Lizenz

Diese Seite beschreibt die unten verlinkte, festgelegte Quellrevision. Verhalten und Anforderungen im Upstream können sich ändern.

Quellinhaber
UIZZE
Lizenz
SKILL.md deklariert MIT; die verlinkte LICENSE im Skill-Verzeichnis enthält Apache-2.0-Bedingungen. Klären Sie die geltenden Bedingungen vor einer Wiederverwendung.
Geprüfter Stand
2026-10-07 · 3a685010a7af
Redaktionelle Quellenzusammenfassung
Ein produktorientierter UI-Workflow, der einen aufgabenspezifischen Leitfaden auswählt, optional UIZZE-Referenzen nutzt und die gerenderte Oberfläche prüft.

Eigene Zusammenfassung 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

Brauche ich ein UIZZE-Abonnement?

Nicht für den kostenlosen Skill und den öffentlichen Katalog. Die Quelle beschreibt kostenpflichtige MCP-Referenzen als optional und verlangt ein tatsächliches Verbindungsergebnis, bevor Zugang behauptet wird.

Schreibt er einen einzigen visuellen Stil vor?

Nein. Der Produkt-Brief und die vorhandene Designsprache haben Vorrang vor den Beispielen im Skill.

Kann ich ihn nur für ein Audit nutzen?

Ja. Ein ausdrückliches Audit hat ein eigenes Playbook; eine Review-Anfrage muss keine Änderungen an der Oberfläche erlauben.

OpenDesign

Schaffen Sie Raum für die nächste Design-Iteration.

Halten Sie Brief, Quellenmaterial und Designarbeit in einem lokalen Arbeitsbereich zusammen. Prüfen Sie die eigene Einrichtung des Skills, bevor Sie ihn in Ihren Workflow aufnehmen.

Upstream-Quelldatei
https://github.com/github/awesome-copilot/blob/3a685010a7afdc0dbd4c83b7fbda6c316aa516e5/skills/anti-ui-slop/SKILL.md