uizze/uizze

Stoppe KI-Coding-Agenten, die generische UI liefern.

Hör auf, UI-Slop zu produzieren

Baue produkt-spezifische UI mit über 800.000 echten Web- und iOS-Bildschirmen über UIZZE.

Übersicht

Nutze den Produktbrief, bestehende UI, Komponenten und das lokale Designsystem, um bewusste Oberflächen zu schaffen. Uizze liefert gezielte Design-Anleitung und, wo nützlich, eine kleine Anzahl relevanter visueller Referenzen.

Voraussetzungen

• Ein Bildschirm oder eine Komponente, die gebaut, umgestaltet oder überprüft werden soll – ein Dateipfad oder eine kurze Beschreibung.
• Die vorhandenen Komponenten, Design-Tokens und die visuelle Sprache des Produkts, so dass der Build sie erweitert, anstatt ein neues System zu erfinden.
• Optionaler Zugang zum kostenpflichtigen Uizze MCP für gezielte Referenzen und gehostete Materialien.

Authentifizierung

• Das kostenlose Skill und der öffentliche Katalog funktionieren ohne Konto, Token, MCP-Verbindung, Abhängigkeit, Skript oder ausführbare Datei.
• Der optionale vollständige UIZZE MCP kann den normalen Verbindungs- und Authentifizierungsablauf des Hosts verwenden. Gib niemals an, dass eine Verbindung besteht, ohne ein tatsächliches Host-Ergebnis.

Vom Produkt aus arbeiten

Lies den Brief, die bestehende UI, Komponenten, Tokens, Assets und alle PRODUCT.md- oder DESIGN.md-Dateien, bevor du mit dem Design beginnst. Die Anfrage des Benutzers und die Projekteinschränkungen haben Vorrang vor diesem Skill. Bewahre ein etabliertes visuelles System für Erweiterungen und Verfeinerungen; ersetze es nur bei einem genehmigten Redesign. Ein neues Projekt benötigt diese Dateien nicht.

Identifiziere die Zielgruppe, die Hauptaufgabe, die wichtigen Zustände und das beabsichtigte Ergebnis. Frage nur nach fehlenden Entscheidungen, die die Arbeit wesentlich verändern würden. Eine präzise Anfrage reicht aus, um fortzufahren; verwandle keine kleine Korrektur in einen Discovery-Workshop.

Wähle den Workflow

Lade das Playbook für die angeforderte Aktion sowie die Plattform- und Handwerksanleitung, die zur Ausführung benötigt werden:

• Neue Oberfläche oder umfassendes Redesign: new-work
• Produkt- oder Dashboard-Arbeit: operate
• Verfeinerung und Politur: polish
• Vereinfachung: distill
• Explizites Audit: audit, schreibgeschützt, sofern keine Korrekturen angefordert wurden
• Natives iOS: iOS, zusammen mit dem Playbook der Aktion
• Explizites /overdrive, „Uizze Overdrive“ oder eine Anfrage für außergewöhnliche Interaktionsarbeit: Overdrive

Für die Implementierung verwende craft, nachdem die Richtung festgelegt ist. Lade nur relevante Dateien; mehrere komplementäre Playbooks sind erlaubt. Overdrive ist opt-in, nicht der Standard für gewöhnliche UI-Arbeit. Es erfordert eine festgelegte Richtung vor der Implementierung.

„Verwende Uizze Overdrive auf diesem Bildschirm“ funktioniert über diesen Router; ein nativer Slash-Befehl hängt vom Host ab. Dies sind eigenständige Markdown-Playbooks, kein Installationsprogramm, Hintergrunddienst oder ausführbare Engine.

Optionaler Uizze-Nachweis

Lies die Referenzrichtlinie, bevor du find_ui_references oder find_ui_materials verwendest. Untersuche relevante visuelle Beweise, wenn sie über Layout, Zustand, Interaktion oder Assets informieren können. Verwende die verfügbaren Werkzeuge des Hosts, keine erfundenen Aufrufe oder Verbindungen. Der kostenpflichtige Abruf ist optional; fehlender Zugriff blockiert nicht die lokale Designarbeit.

Unterscheide zwischen einer exakten Referenz, einem verwandten Beispiel, keinem Treffer und einem Dienstfehler. Gib kurz eine Einschränkung an, die das Ergebnis beeinflusst hat. Gib niemals an, dass ein Bild inspiziert oder ein Zustand gefunden wurde, ohne Beweise.

Abschluss

Baue den angeforderten Umfang und übe seine wichtigen Zustände aus. Rendere und inspiziere das tatsächliche Ergebnis bei repräsentativen Desktop-/Mobilgrößen oder nativen Geräteklassen, einschließlich der vom Benutzer gemeldeten fehlschlagenden Größe. Vergleiche es mit der gewählten Richtung oder der gelieferten Referenz, nicht nur mit der Abwesenheit von Laufzeitfehlern.

Behebe materielle Probleme in einem Batch, rendere und inspiziere dann erneut. Stoppe, sobald das angeforderte Ergebnis verifiziert ist; erfinde nicht weiterhin Arbeit. Wenn ein begrenzter Durchlauf ein Problem nicht lösen kann, melde es, anstatt einen Bestehen zu behaupten. Wenn Rendering nicht verfügbar ist, unterscheide Code-Checks von visueller Verifikation.

Halte die Übergabe präzise: was geändert wurde, was tatsächlich getestet wurde und alle verbleibenden Einschränkungen. Ein Skill autorisiert keine Veröffentlichungen, Käufe, neuen Abhängigkeiten, Kontoänderungen oder destruktiven Aktionen.