UIUX Prototyp
Gestalte Produktoberflächen rund um echte Aufgaben. Liefere überprüfbares HTML vor der Anwendungsimplementierung. Arbeite in der Sprache des Benutzers; standardmäßig chinesische Erklärungen mit notwendigen englischen Begriffen. Diese Fähigkeit ist in sich abgeschlossen: Übergeordnete Fähigkeiten und kostenpflichtige Referenzdienste sind optional, keine Abhängigkeiten.
1. Produkt etablieren und seinen Ist-Zustand bewahren
Lies zuerst die zutreffenden AGENTS.md, HANDOFF.md, die vorhandene DESIGN.md und die aktuellen Prototyp-Dateien. Identifiziere die Benutzer, das Szenario, den Einstieg, die Hauptaufgabe, das Ergebnis, den Geschäftswert, die angeforderten Oberflächen und was außerhalb dieser Version liegt. Bewahre bestehende Markenentscheidungen und die Änderungen anderer Personen. Kläre routinemäßige Details selbst; frage nur nach fehlenden Informationen, die das Design wesentlich verändern.
Vereinbare ein begrenztes Inventar an Bildschirmen/Flüssen aus der Aufgabenstellung, nicht eine willkürliche Anzahl von Seiten. Decke jede angeforderte Oberfläche ab (Web, Miniprogramm, Mobil, Desktop); erfinde keine irrelevante App. Wenn der Oberflächenumfang unbekannt ist und das Projekt ihn nicht festlegen kann, frage einmal nach, bevor du fortfährst. Eine übernommene UI erhält ein Audit und eine nicht überschreibende Version, kein unaufgefordertes Redesign.
Lies die relevanten Entscheidungsregel-Abschnitte (§1–7) in source-synthesis.md; verwende seine Quellenkarte (§8–10), wenn ein Kompromiss erklärt werden muss. Es integriert alle sieben Quell-Repositories. Produktaufgabenklarheit, bestehende Designverträge und Benutzerentscheidungen haben Vorrang vor Landing-Page-Konventionen, Stilverboten und zufälligen Themen.
2. Referenzen recherchieren, dann STOPP für eine Stilentscheidung
Lies reference-research.md. Beginne mit Dribbble; verwende 即时设计 und Behance als Fallbacks oder Ergänzungen. Suche nach der Produktkategorie, der Benutzeraufgabe und der relevanten Plattform, nicht nur nach „schöner UI“. Verwende verfügbare Browser/Suchwerkzeuge; dokumentiere, welche Seiten und Bilder tatsächlich inspiziert wurden. Bezeichne einen Auszug aus einer Suche nicht als visuelle Überprüfung. Beachte Zugriffsbeschränkungen; wenn echte Fälle nicht eingesehen werden können, melde dies und bitte um bereitgestellte Referenzen oder einen expliziten Verzicht auf die Recherche.
Erstelle eine neue Version unter docs/prototype/versions/vX.Y.Z/ (oder dem etablierten Prototyp-Stammverzeichnis des Projekts). Verwende die untenstehende CLI, um sicher zu starten. Schreibe zuerst style-reference.html: normalerweise 2–3 differenzierte, aufgabenangemessene Richtungen, Links/Ersteller zu echten Fällen, beobachtete Beweise versus deine Interpretation, Token-Beispiele und eine originelle kleine UI-Studie der GLEICHEN Aufgabe zum Vergleich. Füge Plattformtauglichkeit, Einschränkungen und deine Empfehlung hinzu. Bewahre bekannte Markenentscheidungen; wenn der Benutzer bereits eine Richtung vorgegeben hat, validiere sie, anstatt Alternativen zu erzwingen.
Liefere das tatsächliche Style-Reference-HTML und bitte den Benutzer, es auszuwählen oder zu überarbeiten. Halte hier an. Erstelle erst die vollständigen App-Bildschirme, design-system.html oder die endgültige DESIGN.md, wenn der Benutzer eine benannte Richtung ausdrücklich genehmigt hat (oder diese genaue Entscheidung in der aktuellen Aufgabe delegiert). Ein lokal ausgewähltes Radio/Kärtchen, eine bevorzugte Empfehlung, eine verstrichene Zeit oder ein CLI-Eintrag ist keine Benutzerautorisierung. Bewahre den Genehmigungsnachweis zusammen mit dem SHA-256 des genehmigten HTMLs auf; eine wesentliche Änderung an diesem Board erfordert eine neue Entscheidung. Behandle dieses Tor nicht als Erlaubnis, erneut nach nicht zusammenhängenden, bereits autorisierten Arbeiten zu fragen.
3. Vollständigen HTML-Prototyp nach der Genehmigung erstellen
Lies prototype-contract.md und nur die relevanten Abschnitte von platforms-and-quality.md. Dokumentiere die tatsächliche Entscheidung des Benutzers; der Helfer zeichnet Beweise auf, er kann nicht überprüfen, wer sie gegeben hat. Bereite dann die generierten Gerüste vor und ersetze sie durch gestaltete, funktionierende Artefakte:
index.html: Prototyp-Startseite/Navigation mit Version, Oberflächeneinträgen, Kernabläufen, Stilreferenz und Links zur visuellen Spezifikation. Jede App hat auch ihre eigene aufgabenorientierte Startseite. Halte Implementierungs-/Statusdetails in diesem Überprüfungs-Hub, nicht im Produkt-Chrome.design-system.html: Vollständige visuelle Spezifikation für die in dieser Version verwendeten Komponenten: semantische Farben, Typografie, Abstände, Layout/Dichte, Symbole, Oberflächen, anwendbare Komponentenzustände, Interaktion/Bewegung und responsive/Plattform-Unterschiede. Zeige tatsächliche gerenderte Beispiele, nicht nur Tabellen mit Namen.- `DESIGN.md': Kanonische Entscheidungen, Token-Werte, Bildschirm-/Flussinventar, Interaktionen, Plattform-Überschreibungen, Barrierefreiheit, Herkunft und bekannte Prototyp-Einschränkungen. Per-Oberfläche DESIGN.md erklärt nur relevante Variationen.
- HTML-Bildschirme jeder angeforderten Oberfläche: Vollständige vereinbarte kritische Pfade, plausible beschriftete synthetische Daten, Navigation und sinnvolle Zustandsänderungen. Gemeinsame semantische Token; plattformangemessene Interaktion, kein verkleinerter Desktop-Screenshot.
Verwende standardmäßig semantisches HTML, CSS-Variablen und kleine lokale Skripte. Verwende das vorhandene Framework/die vorhandenen Komponenten wieder, wenn es die Komplexität reduziert; keine zwingende React-, Tailwind-, shadcn- oder Netzwerkabhängigkeit. Ein statischer HTML-Prototyp muss über einen lokalen HTTP-Server geöffnet werden und sollte nach Möglichkeit mit Datei-URLs navigierbar bleiben. Für die Überprüfung des Prototyps benötigte Assets sollten lokal und lizenziert sein. Halte den Prototyp getrennt vom Anwendungsquellcode.
4. Verifizieren, versionieren und übergeben
Verwende platforms-and-quality.md, um das gerenderte Ergebnis bei schmalen und breiten Viewports, Tastaturfokus, Zoom und reduzierter Bewegung zu überprüfen; inspiziere das zutreffende Geräte-/Plattformverhalten. Teste tatsächliche primäre Pfade sowie leere/Lade-/Fehler-/Erfolgs- und Extreminhaltszustände, die von Bedeutung sind. Behalte nicht die Geräte- oder native SDK-Akzeptanz aus der Browsersimulation. Behebe die beobachteten Probleme und überprüfe die betroffenen Pfade erneut.
Führe eine strukturelle Validierung durch, dokumentiere dann Browser-Nachweise, Viewport-Größen, getestete Abläufe und ungelöste Probleme in QA.md. Strukturelle Validierung kann keine visuelle Qualität, geschäftliche Vollständigkeit, Durchsetzung von Berechtigungen, externe Integration oder Produktionsreife nachweisen. Melde nicht getestete Elemente explizit. Für Bereitstellungsarbeiten messe relevante Lade-/Laufzeit-/Ressourcenkosten, anstatt nur funktionale Prüfungen zu melden; gewöhnliche lokale Prototypen benötigen keine Produktions-Benchmark-Suite.
Halte vorherige Versionen intakt. Lies versioning.md für Genehmigungsungültigkeit, Überarbeitungen, versiegelte Schnappschüsse, Änderungsprotokoll und Navigation zur neuesten Version. Bearbeite ein genehmigtes Board nicht stillschweigend und überschreibe keinen älteren Prototypen. Liefere Links zu den tatsächlichen Dateien, wie man sie öffnet, was verifiziert wurde und was simuliert bleibt.
Helfer (Python 3, Standardbibliothek)
Löse <skill-dir> in das Installationsverzeichnis dieser Fähigkeit auf. Befehle arbeiten nur mit dem angegebenen Projekt; sie veröffentlichen oder ändern keinen Anwendungsquellcode.
python3 <skill-dir>/scripts/prototype.py init --project <project> --version v0.1.0 --surfaces web miniapp mobile desktop
# Bearbeite style-reference.html mit echter Recherche; erhalte die Entscheidung des Benutzers.
python3 <skill-dir>/scripts/prototype.py record-approval --project <project> --version v0.1.0 --direction "B" --evidence "Exakte Benutzerentscheidung aus diesem Gespräch"
python3 <skill-dir>/scripts/prototype.py prepare --project <project> --version v0.1.0
# Ersetze jedes ausstehende Gerüst, implementiere die vereinbarten Abläufe und rendere/überprüfe.
python3 <skill-dir>/scripts/prototype.py validate --project <project> --version v0.1.0 --complete
python3 <skill-dir>/scripts/prototype.py seal --project <project> --version v0.1.0 --summary "Geprüfter Umfang und wesentliche Änderungen"
record-approval speichert einen Arbeitsablauf-Datensatz, keine Identität oder Sicherheitsgrenze. Erfinde niemals dessen Beweise. prepare erstellt Gerüste, keinen fertigen Prototypen. seal zeichnet Datei-Hashes auf; es ist keine visuelle Freigabe oder unveränderlicher Speicher. Verwende das Manifest und die QA-Nachweise gemeinsam.