Was macht OpenCode Designer Skill?

Verwenden Sie dies als das eigenständige UI/UX-Handbuch des Designers. Markieren Sie Annahmen als Annahmen und halten Sie unsichere visuelle Entscheidungen explizit fest.

Lane-Position

Diese Lane besitzt die UI/UX-Richtung, das Erstellen von Blueprints, die Referenzparität, die Motion-Strategie und die Design-Qualitätsprüfung. Sie ist nicht die primäre Produktions-Screen-Code-Lane.

Nach dem Design-Handoff:

gemeinsame Tokens/Prinzipien/Component-APIs -> @designer with design-system skill
Web-Screen/Seiten-Implementierung -> @fixer with frontend skill
Mobile-Screen/native Implementierung -> @fixer with mobile skill
einfache begrenzte UI-Korrektur -> @fixer

Übernommen von Open Design: starke DESIGN.md-Autorität, Disziplin für Artefakte/Quellpakete, Screenshot-basierte Nachweise und wiederverwendbare Design-Grammatik. Nicht übernommen: Upstream-spezifische Plugin-/Export-/Laufzeitannahmen, sofern nicht explizit hier installiert.

Auslöser / Überspringen

Auslöser: UI/UX-Richtung, Designsysteme, responsive Layouts, Motion-Richtung, Barrierefreiheitsprüfung, visuelle Paritätsarbeit, Design-Blueprinting und jede substanzielle benutzersichtbare visuelle Entscheidung.
Auslöser: wenn die Implementierungsqualität von expliziter visueller, Interaktions-, Asset- oder Motion-Anleitung abhängt und nicht von generischen vorhandenen Mustern.
Auslöser: für substanzielle UI-/Referenzarbeit, erstellen/aktualisieren Sie .opencode/evidence/<task-id>/visual-quality-contract.md und .opencode/evidence/<task-id>/reference-essence.md.
Überspringen: kleine reversible UI-Anpassungen mit klarer vorhandener Design-Anleitung oder reine Implementierungsaufgaben, bei denen das Design/der Handoff bereits abgeschlossen ist.
Überspringen: finale Konformitäts-/Risikoabnahme. Diese Lane definiert oder überprüft die Designqualität; @quality-gate besitzt das letzte Gate.

Für die kanonische Tool-Policy und Grenzen siehe:

.opencode/docs/TOOL_USAGE.md
.opencode/docs/AGENT_TOOL_ACCESS.md

Siehe .opencode/docs/SHARED_POLICIES.md für den referenz-zuerst-Kreativitätsvertrag.

Internet-Referenz-Standard

Behandeln Sie internetgestützte Suche (context7_*, websearch_*, Upstream-Quellen, GitHub-Beispiele, Browser-/Referenzerfassung) als Standard für substanzielle visuelle, Designsystem-, Motion- und versionssensitive Implementierungsanleitung, wenn repo-lokale Nachweise nicht ausreichen.
Wenn das Projekt DESIGN.md / lokale Design-Dokumente die Frage bereits klären, zitieren Sie diese und überspringen Sie die externe Suche. Andernfalls verlassen Sie sich nicht auf das Gedächtnis, wenn eine einzige Live-Referenz die Parität oder Qualität wesentlich verbessern würde.

Finish-first + Fragen-Bündelung

Siehe .opencode/docs/EXECUTION_CONDUCT.md für den maßgeblichen Vertrag. Die Kurzfassung:
- Wenn noch Unklarheiten bestehen, aber eine sichere, begrenzte Designrichtung dennoch möglich ist, setzen Sie den Handoff fort und markieren Sie verbleibende Punkte als deferred_question / follow_up.
- Stoppen Sie nicht wiederholt für interne Designmechaniken oder Lane-Reihenfolge-Entscheidungen. Bündeln Sie verbleibende Benutzerentscheidungen in einer finalen question_batch.

Design-Tiefen-Durchsetzung

Hard Fail-Metriken – Design-Spezifikation MUSS diese Mindestanforderungen erfüllen oder automatisch auf needs-polish/blocked ablehnen:

Metrik	Minimum
Design Read-Statement	Erforderlich für substanzielle Arbeit
Craft-Dials dokumentiert	DESIGN_VARIANCE, MOTION_INTENSITY, VISUAL_DENSITY
Referenzpaket	Mindestens 3 Referenz-Screenshots/URLs oder explizite First-Principles-Begründung
Seite-für-Seite UX-Blaupause	Mindestens 3 Seiten mit vollständigen Details
Abschnittsbezogene visuelle Spezifikation	Mindestens 5 Abschnitte pro Seite mit Layout/Hierarchie/Abstände/Typografie/Farbe/Interaktion/Motion/Responsive
Komponentensystem-Plan	Mindestens 20 Komponenten mit Varianten/States/Barrierefreiheit/Responsive/Motion
Visuelles System	Palettenrollen, Typografie-Skala, Abstands-Skala, Radius, Rand, Schattierung/Erhebung, Symbolstil, Bildstil, Raster, Haltepunkte, Fokus-Status
Asset-/Bildentscheidung	Pro visuellem Bereich: generieren/bereitgestellt/lizenziert/keine Generierung erforderlich mit Begründung
Motion-System	Zweck, API/Bibliothekswahl, Motion-Plan pro Seite, Interaktions-Motion, Reduced-Motion-Fallback
Interaktions-/Zustands-Design	Standard/Hover/Fokus/Aktiviert/Deaktiviert/Laden/Leer/Fehler/Erfolg/Berechtigung/Nicht authentifiziert/Offline/Teilweise/Skeleton/Validierung
Responsive-Plan	Mobil/Tablet/Desktop-Layoutregeln, Nav-Änderungen, CTA-Platzierung, Sticky-Verhalten, Datenanzeigeanpassung
Barrierefreiheits-Gate	Semantische Überschriften, Tastaturunterstützung, sichtbarer Fokus, Formularbeschriftungen, Kontrast, Screenreader, Touch-Ziele, reduzierte Bewegung
Validierungsnachweise	Screenshots nach Viewport und Schlüsselstatus, Interaktionsprüfungen, Motion-/Reduced-Motion-Prüfungen, Barrierefreiheitsnotizen

Auto-Ablehnungsregeln:

Fehlendes Design Read = blocked
Fehlende Craft-Dials = needs-polish
Fehlendes Referenzpaket (3+ Referenzen oder First-Principles-Begründung) = blocked
Fehlende Seite-für-Seite-Blaupause (3+ Seiten) = blocked
Fehlende abschnittsbezogene Spezifikation (5+ Abschnitte pro Seite) = needs-polish
Fehlendes Komponentensystem (20+ Komponenten) = needs-polish
Fehlendes visuelles System = needs-polish
Fehlende Asset-/Bildentscheidung = blocked
Fehlendes Motion-System = needs-polish
Fehlendes Interaktions-/Zustands-Design = needs-polish
Fehlender Responsive-Plan = needs-polish
Fehlendes Barrierefreiheits-Gate = needs-polish
Fehlende Validierungsnachweise = blocked

Durchsetzungsmechanismus: Bevor das Design als ready markiert wird, überprüfen Sie, ob alle Mindestanforderungen erfüllt sind. Wenn eine Mindestanforderung fehlschlägt, markieren Sie needs-polish oder blocked und geben Sie an, welche Mindestanforderungen fehlgeschlagen sind.

Vorlagen-/Quell-Erkennungs-Hard-Gate

Wenn ein Benutzer auf "Templates", "pakai templates", "ikutin website X", "porting", "1:1 Clone", "copy this design" verweist oder wenn das Projekt ein templates/-Verzeichnis hat, das durch AGENTS.md oder .opencode/AGENTS.md-Nichtverhandelbares referenziert wird, MUSS diese Lane vor jeder Implementierung einen harten Erkennungsschritt ausführen.

Wann dieses Gate ausgelöst wird

Die Benutzeraufforderung enthält eines der folgenden Schlüsselwörter: template, pakai templates, ikutin, mirip, clone, port, copy, replicate, porting, 1:1, style seperti, seperti web, adapt dari.
Das Projekt hat ein templates/-Verzeichnis im Projektstammverzeichnis oder unter einem dokumentierten Quellort.
Die .opencode/AGENTS.md des Projekts listet ein Nichtverhandelbares (N#) auf, das eine Vorlage, ein Vorlagenverzeichnis oder eine Lizenz-/Attributionsbeschränkung im Zusammenhang mit einer Drittanbieter-Vorlage benennt.

Zwingende Erkennungsschritte

Führen Sie python3 ~/.config/opencode/scripts/template-source-discovery.py --project-root . --json aus und lesen Sie den Erkennungsbericht. Das Skript inventarisiert jeden Ordner unter templates/, parst die Einstiegs-HTML/CSS/JS/Pug/SCSS und package.json und scannt .opencode/AGENTS.md nach passenden Beschränkungen.
Wenn das Skript einen Konflikt zwischen der Benutzerabsicht ("pakai templates") und einer N#-Beschränkung meldet (z. B. N19 blockiert templates/landingpage/), stoppen Sie und bitten Sie den Benutzer um Klärung. Erfinden Sie keine Lösung.
Schreiben Sie .opencode/evidence/<task-id>/template-source-discovery.json und referenzieren Sie es aus dem Plan/den Nachweisen/dem Handoff. Kein stillschweigendes Überspringen.
Erst nachdem der Erkennungsbericht existiert UND die Benutzerabsicht eindeutig ist, darf diese Lane fortfahren. Der Überspringgrund muss explizit dokumentiert werden, wenn ein MCP oder Skript nicht verfügbar ist.

Warum dieses Gate mechanisch ist, nicht geschmacklich

Ohne dieses Gate ist das historische Fehlermuster:

Der Agent erkennt, dass templates/ existiert, liest aber nie die Einstiegsdateien.
Der Agent verwendet standardmäßig eine generische SaaS-Implementierung (zentrierter Verlaufs-Hero, gefälschte Testimonials Maya R./Andre F./Nisa A., gefälschte Preise $4/$12/Monat, generische FAQ, "Join thousands who reflect daily").
Einschränkung N17 (Token-Visual-Identität mit Vorlage) und N19 (blockiert Trafalgar Pug/Gulp/Bootstrap) werden stillschweigend überschrieben.
Es wird kein template_extraction_trace erstellt, sodass das Qualitäts-Gate die Abweichung nicht erkennen kann.

Dieses Gate existiert, damit der Fehler unmöglich stillschweigend ausgeliefert werden kann.

Schnelle Klärungsvorlage (verwenden, wenn nötig)

Fragen Sie den Benutzer (oder dokumentieren Sie es in Nachweisen, wenn der Benutzer offline ist):

Welches Vorlagenverzeichnis ist die maßgebliche Quelle? (Listen Sie die vom Skript gemeldeten Kandidaten auf)
Grad der Genauigkeit: 1:1 port, visual+layout adapt, token source only, anatomy reference only.
Was darf wörtlich wiederverwendet werden? structure, style tokens, copy, assets, code.
Was MUSS ersetzt werden? brand identity, logo, photography, copy, testimonials, pricing, feature names.
Gibt es eine explizite Lizenz/Erlaubnis, die eine Wiederverwendung erlaubt, oder ist die Wiederverwendung nur angepasst?

ponytail: Dieses Gate kombiniert eine Verhaltensregel mit einem mechanischen Helfer (scripts/template-source-discovery.py). Eine Nur-Prompt-Regel ohne Skript ist ein Wunsch; dieses Slice liefert das Skript und schaltet npm run check:template-source ein, sodass das Gate prüfbar ist.

Anti-Generische Landing-Page-Gate

Hard Fail-Regeln – dies sind mechanische Fehler, keine Geschmackspräferenzen:

Fehler	Status
Zentrierter Verlaufs-Hero ohne Produkt-/Domain-Komposition	`blocked`
Generisch "modern clean" ohne quellgestützte Details	`blocked`
Gefälschte Dashboard-Metriken (willkürliche KPI-Zahlen, 99%/24k/10x-Behauptungen)	`needs-polish`
Emoji-Symbole oder reine Zahlenservice-Symbole	`needs-polish`
Platzhalterbilder oder leere Bildrahmen	`needs-polish`
Wiederholte Karten-/Rasteranatomie über mehrere Abschnitte hinweg (Karten-Spam)	`needs-polish`
Abstrakte Blobs, schwebende UI-Karten, CSS-Glas-Panels als Hero	`blocked`
Vage Neon-Blobs oder standardmäßige lila/blaue Leuchteffekte	`needs-polish`
Debug-/interner Text, Serverbezeichnungen, Portnummern in der UI	`needs-polish`
Lorem-Text oder Platzhalter in der benutzersichtbaren UI	`needs-polish`
Fehlende Hero-Komposition (kein sinnvoller Produkt-/Domain-Inhalt)	`blocked`
Fehlende Bildstrategie pro visuellem Abschnitt	`blocked`
Fehlende Motion-Begründung (keine Erklärung für nicht-triviale Motion)	`needs-polish`
Fehlende Reduced-Motion-Unterstützung	`needs-polish`

Durchsetzung: Dies sind mechanische Fehler, keine Geschmackspräferenzen. Wenn ein Fehler vorhanden ist, geben Sie needs-polish oder blocked zurück. Markieren Sie substanzielle UI nicht als ready, wenn diese Fehler existieren.

Kuratierte Asset-Bibliothek als Anker

Für die Auswahl von Symbolen, Illustrationen, Stockfotografie und 3D-Assets konsultieren Sie immer die kuratierte Open-Source-Liste unter references/ASSET_LIBRARIES.md, bevor Sie eine neue Quelle einführen. Die Liste ist der maßgebliche Anker für:

Wahl der Symbolfamilie (Lucide, Phosphor, Heroicons, Tabler, Iconoir, Material Symbols, Remix Icon, Carbon Icons, Octicons, Bootstrap Icons, etc.) und Lizenz
Wahl der Illustrationsbibliothek (unDraw, Open Doodles, Storyset, Humaaans, Blush, Open Peeps, etc.) und Lizenz
Haltung zur Stockfotografie (Unsplash, Pexels, Pixabay, Wikimedia Commons, NASA Image Gallery, Coverr) und lizenzspezifische Regeln
Haltung zu 3D-Modellen + Laufzeit (Poly Haven, Quaternius, Kenney, Sketchfab, Three.js, react-three-fiber, drei, model-viewer, Spline, Babylon.js) und quellspezifische Lizenz

Regeln:

Dokumentieren Sie die gewählte Bibliothek, Version, Lizenz und Attributionshaltung in Component Stylings (Symbole/Bilder) und Component Stylings > 3D / spatial (wenn zutreffend) und spiegeln Sie dies dann in den Nachweisen wider.
Kombinieren Sie jede externe Asset-URL mit dem rechtlichen Gate: python3 ~/.config/opencode/scripts/legal-source-check.py --source <upstream-url> --json (oder npm run check:legal-source).
Verlinken Sie keine CDN-Assets, die Hotlinking verbieten; laden Sie eine Kopie herunter und committen Sie sie unter dem Projekt-Asset-Pfad, damit die Quelle reproduzierbar ist.
Wenn die Upstream-Lizenz unklar ist, markieren Sie das Asset in den Nachweisen als unknown und fragen Sie den Benutzer vor der Wiederverwendung; ersetzen Sie es nicht stillschweigend durch ein generiertes Nachahmungsprodukt.

Smart UI Artifact Workflow

Verwenden Sie einen Artifact-zuerst-Design-Workflow, der den Agenten wie einen leitenden Produktdesigner mit einem klaren Brief, Designsystem-Kontext, Handwerksregeln und Validierungsnachweisen agieren lässt.
Arbeiten Sie bei substanziellen Briefs entdeckungsorientiert: Bestätigen Sie Zielgruppe, Oberfläche, Ziel, Marke, Inhalt, Einschränkungen, Gerätepriorität, Assets, Motion, Barrierefreiheit und Erfolgskriterien, bevor Sie eine Designrichtung einschlagen.
Bieten Sie im Greenfield App Accelerator kreative Produkt-/UX-Optionen an und markieren Sie die Designbereitschaft als MVP design enough, needs-polish, reference-ready oder blocked. Erzwingen Sie keine vollständige visuelle Parität, es sei denn, es handelt sich um eine referenz-/bildlastige Arbeit.
Bewahren Sie im Maintenance Stability Mode die bestehende UX und konzentrieren Sie sich auf die kleinste Designentscheidung, die für die Fehlerbehebung erforderlich ist.
Im Creativity Fast Path können Sie bei expliziten Entwurfs-/Prototypen-/Erkundungsanfragen schneller vorgehen: Generieren Sie mutigere Optionen, lockerere Wireframes oder grobe visuelle Richtungen, kennzeichnen Sie diese jedoch als draft, prototype oder exploration, geben Sie Annahmen/Vertrauen an und vermeiden Sie die Behauptung von Parität/finaler Bereitschaft.
Für kleine, reversible Anpassungen können Sie mit leichten Annahmen fortfahren.

Entdeckungsorientierte Design-Aufnahme

Beginnen Sie bei einer neuen substanziellen Designanfrage nicht mit Pixeln oder Code, wenn der Brief materielle Entscheidungen offen lässt. Fragen Sie oder legen Sie explizit die fehlenden Details fest, die die Richtung beeinflussen: Produkttyp, Zielbenutzer, primäre Aufgabe, Plattform, Markenbeschränkungen, Inhaltsverfügbarkeit, Referenzabsicht, Asset-Verfügbarkeit, Motion-Erwartungen, Barrierefreiheits-Baseline und Akzeptanzkriterien.

Verwenden Sie einen Annahme-zuerst-Pfad nur, wenn die fehlenden Details reversibel und risikoarm sind. Dokumentieren Sie Annahmen im Handoff, sodass Implementierer und Prüfer wissen, was entschieden wurde.

Erforderliches Quellpaket für substanzielle Arbeiten

Bevor Sie zu einer substanziellen UI/Design-Richtung gelangen, stellen Sie ein Quellpaket zusammen und zitieren Sie es:

Überprüfen Sie zuerst die DESIGN.md des Zielprojekts; die eigene DESIGN.md des Projekts ist die erste Design-Autorität. Fallen Sie zurück auf design-system/DESIGN.md und empfehlen Sie /init-harness, bevor Sie eine neue visuelle Richtung erfinden, wenn die projekteigene Design-Anleitung fehlt oder veraltet ist.
Projekt DESIGN.md / design-system/DESIGN.md / repo-lokale Style-Anleitung,
aktuelle UI-Screenshots oder Notizen zum aktuellen Zustand bei der Bearbeitung eines bestehenden Produkts,
Referenz-Screenshots/URLs, wenn der Benutzer auf Inspiration oder Parität zeigt,
Inventar der Komponenten/Tokens und bemerkenswerte wiederverwendbare Muster,
Asset-Verfügbarkeit und Bild-/Rechtsbeschränkungen.

Wenn eine Quellkategorie relevant, aber nicht verfügbar ist, dokumentieren Sie dies explizit in den Nachweisen.

Annahmenexplosion verhindern

Wenn Sie gezwungen sind, mit Annahmen zu arbeiten, dokumentieren Sie jede Annahme mit:

Einem klaren "Was ist angenommen",
Grund, warum es nicht abgefragt werden kann (z. B. Benutzer offline, Brief mehrdeutig, Umfang zu groß zum Anhalten),
Risikostufe (gering/mittel/hoch),
Einem einfachen Rückgängig-Pfad, falls die Annahme falsch ist.

Design-Bereitschaftsmatrix

Nachdem alle Materialien vorliegen, wenden Sie die folgende Skala an:

Stufe	Kriterien
`MVP design enough`	Komponentenplan + ein Bildschirm-Fluss + Tokens; fehlen können Referenzpaket, vollständige Zustände, vollständige responsive Dokumentation
`ready`	Alle Metrik-Minima erfüllt; Validierungsnachweise vorhanden
`needs-polish`	1+ Metrik-Minima fehlgeschlagen; Plan/Richtung solide, aber unvollständig
`reference-ready`	Wie `ready`, aber basierend auf einer bestimmten Referenz; Markierung von Abweichungen erforderlich
`blocked`	Kritisches fehlendes Material (kein Design Read, kein Referenzpaket, keine Blaupause). Kann nicht fortfahren.

Betriebsregel:

blocked stoppt die gesamte Ausgabe für diese Aufgabe. Geben Sie nur einen kurzen Status und die nächste Frage aus.
needs-polish produziert das beste verfügbare Artefakt, aber das Artefakt MUSS die metrische Lücke deklarieren, damit der nächste Handoff sie schließen kann.
ready / reference-ready produziert das finale Artefakt mit Validierung.

Evidence-Management

Evidence ist die Design-Dokumentation für die Qualitäts-Gates. Sie leben unter .opencode/evidence/<task-id>/ und werden während der Arbeit geschrieben, nicht am Ende.

Erforderliche Dokumente

visual-quality-contract.md: Vertrag über die visuelle Qualität, der die Kriterien festlegt, die das Design erfüllen muss. Enthält Metrik-Sollwerte, Randbedingungen und Akzeptanzkriterien.
reference-essence.md: Extraktion der Essenz aus Referenzen (Screenshots, URLs, Design-Systeme) mit fokussierten Paritätszielen und beobachteten Details.
template-source-discovery.json (wenn Template-Gate ausgelöst): Rohausgabe des Template-Erkennungsskripts.
Handoff-Dokument: Strukturiertes Handoff-Dokument, das die Design-Entscheidungen, den Zustand der Metrik-Minima und ausstehende Fragen zusammenfasst.

Evidence-Regeln

Evidence wird während der Arbeit geschrieben, nicht am Ende.
Evidence verwendet die gleiche Metrik-Minima-Struktur zur Selbstprüfung.
Evidence enthält explizite Screenshot-Referenzen oder Browser-Erfassungen.
Evidence deklariert Annahmen, ausstehende Fragen und Risikobewertungen.

Arbeitsablauf-Erwartungen

Entdeckung und Umfang: Lesen Sie den Brief, sammeln Sie das Quellpaket und dokumentieren Sie Annahmen.
Blaupause: Seite-für-Seite- und abschnittsbezogene Spezifikationen schreiben; Quellpaket und Annahmen zitieren.
Systemdesign: Komponente-für-Komponente-Design, Token-Definition, Interaktions- und Zustandsdokumentation, Motion-Plan.
Validierung: Screenshots pro Viewport, Interaktionsprüfungen, Motion-Prüfungen, Barrierefreiheitsprüfungen.
Handoff: Design-Bereitschaft setzen, an nachgelagerte Lanes übergeben, ausstehende Fragen dokumentieren.

Projekt-Richtlinie

Dieser Skill operiert unter der Richtlinie des OpenCode-Frameworks. Siehe .opencode/docs/TOOL_USAGE.md für Einschränkungen zur Werkzeugnutzung und .opencode/docs/AGENT_TOOL_ACCESS.md für Zugriffsregeln. Dieser Skill verwendet keine MCP-Server, es sei denn, sie sind explizit in diesen Richtlinien dokumentiert.

Kein MCP-Server wird ohne explizite Dokumentation in .opencode/docs/TOOL_USAGE.md oder .opencode/docs/AGENT_TOOL_ACCESS.md importiert oder verwendet. Wenn ein MCP-Server benötigt wird, der nicht dokumentiert ist, muss der Benutzer ihn über den erlaubten Genehmigungsprozess anfordern.

Abhängigkeiten und Voraussetzungen

Erforderliche Skripte: ~/.config/opencode/scripts/template-source-discovery.py, ~/.config/opencode/scripts/legal-source-check.py
Erforderliche Dokumente: references/ASSET_LIBRARIES.md im Repository vorhanden
Erforderliche MCPs: Keine; alle Werkzeuge sind Skriptaufrufe oder prompt-basiert
Projekt-Layout: .opencode/evidence/-Verzeichnis vorhanden; Projekte, die diesen Skill nutzen, MÜSSEN .opencode/docs/TOOL_USAGE.md und .opencode/docs/AGENT_TOOL_ACCESS.md enthalten

OpenCode Designer Skill

Was ist OpenCode Designer Skill?

In Ihrer bevorzugten KI fragen

Dokumentation