macistone71-jpg/heqingfeng-product-ui-skill

Product UI Director｜何庆丰定制版

Verwandle „Mach es schön“ in wiederverwendbare Produktentwicklung: Zuerst das Produkt verstehen, dann ein Designsystem aufbauen; zuerst Differenzierung schaffen, dann Code schreiben; und am Ende muss die Abnahme im echten Browser erfolgen.

Erforderliche Einsatzszenarien

• Neue Produkte, Seiten, Landing Pages, Arbeitsbereiche, Dashboards, mobile oder Desktop-UI;
• Änderungen an Layout, Farbgebung, Schriftarten, Abständen, Navigation, Formularen, Animationen, Diagrammen und responsivem Design;
• Wenn Benutzer sagen: „Sieht unprofessionell aus“, „Zu sehr wie KI“, „Zu unübersichtlich“, „Mobil funktioniert es nicht“, „Die Interaktion ist umständlich“;
• UI-Code-Reviews, Abnahme vor dem Launch, Wettbewerbsanalyse und Verstetigung des Designsystems.

Dieses Skill wird nicht für reine Backend-, Datenbank- oder Deployment-Aufgaben geladen, die keine Änderungen an der Benutzeroberfläche erfordern.

Unverzichtbare Prinzipien

1. Produkt vor Stil: Zuerst die Zielgruppe, Kernaufgaben, Nutzungshäufigkeit, Plattform, Inhaltsdichte und Risiken klären, dann den Stil wählen.
2. Echte Inhalte vor Platzhaltern: Keine erfundenen Metriken, gefälschten Bewertungen, sinnloses Lorem Ipsum oder dekorative Zahlen als Produktbeweise verwenden.
3. Differenzierung vor Vorlagen: Den Standard-KI-Ästhetiklook „lila Verlauf + drei Glaskarten + riesige abgerundete Ecken“ nicht ohne Grund verwenden.
4. Ein Projekt – eine Design-Erinnerung: Wenn bereits eine design-system/<slug>/MASTER.md existiert, diese zuerst lesen; nicht stillschweigend überschreiben.
5. Funktionale Korrektheit hat Priorität: Visuelles Design darf Geschäftslogik, Datenzustände, Fehlerbehebung, Tastaturnavigation und mobile Benutzerfreundlichkeit nicht beeinträchtigen.
6. Echte Abnahme: Nicht nur den Code überprüfen und für fertig erklären; die Seite öffnen, die Kernabläufe ausführen und mindestens den 390px- und Desktop-Viewport prüfen.
7. Quellenangabe: Dieses Skill basiert auf einem MIT-lizenzierten Open-Source-Projekt; die Lizenz- und Ursprungsangaben dürfen nicht entfernt werden.

Sechsstufiger Workflow

0. Ist-Zustand erfassen

• PRD, README, vorhandene Seiten, Marken-Assets, Tech-Stack und letzte Änderungen lesen;
• Tech-Stack erkennen, nicht raten;
• Vorhandene design-system/**/MASTER.md, Seiten-Override und UI-Abnahmeberichte finden und lesen;
• Für neue Produkte 3–5 direkte oder verwandte Wettbewerbsseiten besuchen, Struktur und Interaktion notieren, aber nicht das visuelle Skin kopieren.

1. Produkt-UI-Brief erstellen

Zumindest klären: Produktaufgabe, Zielgruppe, Plattform, primärer CTA, Schlüsselinformationen, Risiken, Inhaltsdichte, Markenpersönlichkeit, Barrierefreiheitsanforderungen, unterstützte Viewports. Wenn Informationen aus dem Projekt abgeleitet werden können, direkt fortfahren, nicht wiederholt nachfragen.

Zum Erstellen von Projektdokumenten ausführen:

python3 scripts/qf_project_init.py --project-root <Projektstamm> --project-name "Projektname" --product-type "Produkttyp" --platform web

Das Skript überschreibt standardmäßig keine vorhandenen Dateien.

2. Designsystem generieren und persistieren

Für neue Projekte oder systemweite Überarbeitungen muss ausgeführt werden:

python3 scripts/search.py "<Produkttyp Branche Stilbeschränkungen>" --design-system --persist -p "Projektname" --output-dir "<Projektstamm>"

Verfügbare Modifikatoren: --variance 1-10, --motion 1-10, --density 1-10. Arbeitsbereiche verwenden normalerweise höhere density; Inhaltsprodukte niedrigere density; motion dient nur Status und Kausalität.

Wenn bereits eine MASTER.md existiert, diese zuerst lesen; nur bei expliziter Autorisierung durch den Benutzer --force verwenden.

3. „Produktsignatur“ erstellen

Jedes Produkt definiert mindestens 3 erkennbare, aber nicht störende Signaturen:

• Eine typografische Signatur (z. B. Redaktionsraster, Produktionszeitleiste, papierartiger Lesebereich);
• Eine Informationssignatur (z. B. Qualitätsgate, Beweiskette, Prüfstatus);
• Eine Interaktionssignatur (z. B. Probenmodus, lokale Rückgängig-Funktion, progressive Vorschau).

Signaturen müssen aus dem Produktmechanismus stammen, nicht aus zufälligen Farbverläufen, übermäßigen Animationen oder dekorativen Grafiken.

Für bestehende Produkttypen von He Qingfeng bei Bedarf references/heqingfeng-product-patterns.md lesen.

4. Implementierung und gezielte Recherche

Nur die aktuelle Frage abfragen, nicht alle Regeln auf einmal laden:

python3 scripts/search.py "keyboard focus modal" --domain ux
python3 scripts/search.py "dashboard dense filters" --domain style
python3 scripts/search.py "form error recovery" --domain ux
python3 scripts/search.py "responsive card grid" --stack <erkannter Tech-Stack>

Bei leeren Ergebnissen nur einmal enger fassen und wiederholen; wenn immer noch leer, klare allgemeine Regeln verwenden, kein falsches Datenbanktreffer vortäuschen.

Implementierungsanforderungen:

• Semantische Tokens verwenden, keine bedeutungslosen Farben und Abstände in Komponenten verteilen;
• Fließtext auf mobilen Geräten standardmäßig mindestens 16px; Bedienelemente mit sichtbarem Label;
• Tastaturfokus auf dem Web sichtbar; Touch-Ziele plattformkonform;
• Keine Abhängigkeit von Hover für Hauptaufgaben;
• Asynchrone Abläufe haben Lade-, Erfolgs-, Fehler- und Wiederherstellungszustände;
• Animationen respektieren prefers-reduced-motion;
• Lange chinesische Texte, lange englische Texte, URLs, Zahlen und leere Daten dürfen das Layout nicht zerbrechen.

5. Echte browserbasierte Abnahme

Wenn die Seite ausführbar ist, muss der Browser für Kernaufgaben verwendet werden. Bevorzugt das installierte ego-browser-Skill aufrufen:

1. Desktop-Viewport ca. 1440px: Hierarchie des oberen Bildschirmbereichs, Kernabläufe, Popups/Formulare/Export;
2. Mobil-Viewport 390px: Sicherstellen, dass scrollWidth === innerWidth, kein horizontaler Überlauf;
3. Tastaturbedienung: Fokus sichtbar, Reihenfolge sinnvoll, Esc/Zurück stellt Zustand wieder her;
4. Zustände: Leer, Laden, Fehler, Erfolg, Deaktiviert;
5. Lesbarkeit: Kontrast, langer Text, Zoom, reduzierte Animation;
6. Tatsächliche Ergebnisse dokumentieren, nicht „Code existiert“ als „Abnahme bestanden“ schreiben.

Für Web/Desktop-Abnahme §1–§3 aus references/quick-reference.md lesen; für native/mobile Auslieferung references/pro-rules.md vor der Abnahme lesen.

Zuerst statische Vorabprüfung durchführen:

python3 scripts/product_ui_audit.py <Projektstamm> --format markdown

Statische Ergebnisse sind nur Risikohinweise und ersetzen keine browserbasierte Abnahme.

6. Iterationserinnerungen speichern

Bei Auslieferung aktualisieren:

• design-system/<slug>/MASTER.md: Stabile Designregeln;
• design-system/<slug>/pages/<page>.md: Seitenunterschiede;
• design-system/<slug>/DECISIONS.md: Wichtige Abwägungen und Begründungen;
• design-system/<slug>/UI-ACCEPTANCE.md: Viewports, Aufgaben, Zustände, Mängel und Nachweise.

Nur echte Überprüfungen dokumentieren. Wenn keine Daten zu Graustufen, Konversionsraten oder Akzeptanzraten erhoben wurden, mit „Noch zu validieren“ markieren.

Qualitätsprioritäten

1. Accessibility: Kontrast, Fokus, Tastatur, Semantik, Alternativtexte;
2. Touch & Interaction: Zielgröße, Feedback, Fehlerbehebung;
3. Performance: Bildgröße, CLS, Schriftarten, Hauptthread;
4. Product Fit: Passt der Stil zur Produktaufgabe;
5. Responsive: Mobile-First, kein horizontaler Überlauf;
6. Typography & Color: Schriftgrade, Zeilenhöhen, semantische Farben;
7. Motion: Nur zur Darstellung von Kausalität, unterbrechbar, reduzierbar;
8. Forms & Feedback; 9. Navigation; 10. Charts.

Vollständige Regeln bei Bedarf aus references/quick-reference.md lesen.

Harte Abnahmetore

Die UI darf nicht als abgeschlossen erklärt werden, wenn eines der folgenden Kriterien zutrifft:

• Hauptaufgabe kann nicht ausgeführt werden, oder Buttons haben nur visuelle, aber keine funktionale Wirkung;
• Horizontaler Scroll bei 390px;
• Angezeigte fiktive Benutzerzahlen, Erfolgsmetriken oder Bewertungen ohne Quellenangabe;
• Formulare ohne Label, Fehlerbegründung oder Wiederherstellungspfad;
• Icon-Buttons ohne zugänglichen Namen, Tastaturfokus nicht sichtbar;
• Text-/Kern-Bedienelemente haben deutlich unzureichenden Kontrast;
• Popups können nicht geschlossen werden, Zurück zerstört den Zustand, fixierte Leisten verdecken Inhalte;
• Nur Code überprüft, aber nicht ausgeführt und mit der Seite interagiert;
• Neues Projekt ohne Designsystem, oder vorhandene MASTER.md ohne Erlaubnis überschrieben.

Lokale Wissensdatenbank

Dieses Skill behält die durchsuchbaren Daten des Upstreams: 79 Stile, 192 Produktkategorien mit Farbgebung/Logik, 74 Schriftkombinationen, 119 UX-Richtlinien, Icons, Animationen, Diagramme und 22 Tech-Stacks. scripts/search.py und die Datendateien stammen vom Upstream; der angepasste Workflow, Projektvorlagen und Abnahmetools wurden in diesem Repository hinzugefügt.