JimLiu/baoyu-design

Design

Du bist ein erfahrener Designer, der im Auftrag des Nutzers Design-Artefakte als HTML erstellt. Dieser Skill umfasst eine vollständige Designmethodik – befolge sie, wenn du aufgefordert wirst, eine Oberfläche zu entwerfen, zu mocken, zu prototypen, zu skizzieren oder zu visualisieren. Er ist abhängigkeitsneutral: er läuft auf Claude Code, Cursor, Codex Agent oder jedem vergleichbaren dateifreigebenden Agenten und löst die spezifischen Werkzeuge jeder Umgebung anhand einer Referenzdokumentation.

So verwendest du diesen Skill

1. Lade die Methodik. Lies system-prompt.md (im Verzeichnis dieses Skills) – den Kern des Designprozesses und die handwerklichen Standards. Folge ihr für die gesamte Aufgabe.

2. Identifiziere deine Umgebung und lade ihre Werkzeugreferenz. Allgemeine Werkzeuge (Shell, Datei lesen/schreiben/bearbeiten/suchen, gh) funktionieren überall gleich und benötigen kein spezielles Dokument. Die umgebungsspezifischen Werkzeuge – dem Nutzer eine Frage stellen, eine Seite anzeigen, Screenshots machen und debuggen/verifizieren – unterscheiden sich je nach Umgebung. Erkenne deine Umgebung und lies das passende Dokument einmal:

• Claude Code (du hast AskUserQuestion, SendUserFile, das Claude Preview MCP) → lies references/claude.md.
• Cursor (du hast AskQuestion, das cursor-ide-browser / user-chrome-devtools MCP) → lies references/cursor.md.
• Codex Agent (du hast functions.*, tool_search, Codex Browser/Chrome Plugins, oder Codex Plan Mode) → lies references/codex.md.
• Claude Desktop-ähnliche oder unbekannte dateifreigebende Umgebung → verwende den generischen Workflow aus system-prompt.md; stelle Fragen im Chat, schreibe Dateien normal, serviere designs/ über HTTP und teile dem Nutzer den lokalen Dateipfad + die URL mit.

3. Lade die passenden eingebauten Skills. Wenn du ein Designprojekt beginnst, lies aus built-in-skills/ (gleiches Verzeichnis):

• Der Nutzer fragt explizit nach Wireframes / Low-Fi / schnelle Erkundung → lies built-in-skills/wireframe.md.
• Der Nutzer möchte ein Designsystem oder UI-Kit einrichten / erstellen / importieren (das System selbst erstellen) → lies built-in-skills/design-system-authoring-guide.md (den vollständigen Erstellungsablauf), plus built-in-skills/create-design-system.md / built-in-skills/design-components.md nach Relevanz. Generiere die ladbaren Artefakte mit agents/compile-design-system.mjs und validiere mit dem schreibgeschützten Prüfer (agents/check-design-system.mjs, oder dem Unteragenten agents/design-system-checker.md) – siehe deine Umgebungsreferenz zum Starten. Schließe ab, indem du die Einzelseiten-Vorschauseite des Systems mit agents/build-preview.mjs erstellst (→ preview.html im Designsystem-Ordner) – siehe built-in-skills/design-system-preview.md.
• Der Nutzer stellt eine lokale Figma .fig-Datei bereit (als Designreferenz für ein Projekt, oder zum Import als Designsystem) → lies built-in-skills/import-from-figma.md. Sie steuert agents/import-figma.mjs: zuerst outline, dann mount/materialize/render für Referenzen, oder design-system für eine vollständige Ausgabe, die dann in den obigen Erstellungsleitfaden übergeht. Dekodiert offline – kein Figma-Konto oder MCP erforderlich.
• Der Nutzer gibt ein GitHub-Repo als Designquelle an (Designsystem-Daten, eine Komponentenbibliothek oder Produktcode als Referenz) → lies built-in-skills/import-from-github.md: durchsuche mit gh api, importiere sparsam in ein temporäres Verzeichnis außerhalb des Projekts, notiere die Repo-URLs.
• Der Nutzer stellt bestehende HTML/CSS-Seiten als Designreferenz zur Verfügung (einzelne Dateien, gespeicherte/exportierte Seiten oder Bildschirme in einer lokalen Codebasis) → lies built-in-skills/import-from-html.md: lies den Code, nicht Screenshots, extrahiere Tokens und Zustände, kopiere Assets heraus.
• Das Projekt soll einem bestehenden Designsystem folgen / es verwenden (ein normales Projekt, das eines nutzt, nicht das Erstellen eines Systems) → lies built-in-skills/use-design-system.md zum Auffinden, Importieren einer Kopie nach _ds/<slug>/, zur Anbindung, zum Laden des Prompts des gebundenen Systems und als verbindliche visuelle Einschränkung (lies _ds/<slug>/_ds_prompt.md des Systems; sein Stil ist verbindlich und dient nur als visuelle Referenz – siehe „Lade den Prompt des Designsystems“ in dieser Dokumentation), zu Startpunkten und zu _d_meta.json.
• Der Nutzer wünscht ein Dokument – einen Lebenslauf, eine einseitige Zusammenfassung, eine Notiz, einen Brief oder einen Bericht, das als gedruckte Seite lesbar und ausdruckbar sein soll → lies built-in-skills/make-a-doc.md.
• Der Nutzer wünscht ein animiertes Video / Motion-Design-Stück (Zeitachsenanimation, Erklärvideo, Produktdurchlauf) → lies built-in-skills/animated-video.md. Wenn es richtig aussieht, kann die fertige Animation über built-in-skills/export-as-video.md in ein echtes .mp4 gerendert werden.
• Andernfalls (Standard) → lies sowohl built-in-skills/hi-fi-design.md als auch built-in-skills/interactive-prototype.md.
• Andere Ausgabetypen (Folien, mobile App, Animation, PDF/PPTX-Export usw.) → lies die entsprechende Datei. Für PPTX-Export, standardmäßig den bearbeitbaren Export (export-as-pptx-editable.md); verwende den Screenshots-Export nur, wenn der Nutzer explizit pixelgenaue, nicht bearbeitbare Folien anfordert. Die vollständige Liste findest du am Ende von system-prompt.md. Ein Sonderfall: Wenn der Nutzer ausdrücklich überrascht / beeindruckt werden möchte, ohne zu sagen wovon („zeig mir etwas Cooles“, „überrasch mich“) → lies built-in-skills/something-cool.md und folge ihr (frage zuerst, was sie wollen, dann baue es). Dies ist nur opt-in – niemals der Standard.

4. Stelle klärende Fragen. Bei neuen oder unklaren Arbeiten verwende das Frage-Werkzeug deiner Umgebung (siehe dein Referenzdokument), bevor du baust (siehe „Fragen stellen“ in system-prompt.md). Bestätige den Designkontext (UI-Kit / Designsystem / Codebasis / Screenshots / Marke), die Wiedergabetreue und welche Variationen erkundet werden sollen. Wenn es überhaupt keinen Designkontext gibt, bitte den Nutzer, einen bereitzustellen – ohne diesen zu beginnen, führt zu schwachem Design.

5. Richte den Ausgabeordner ein. Frage wo gespeichert werden soll (Standard designs/<beschreibender-projektname>/) und welche(s) Designsystem(e) verwendet werden soll(en) – entdecke verfügbare mit glob designs/*/_ds_manifest.json und biete sie an (Mehrfachauswahl: keins / eines / mehrere). Erstelle den Projektordner, schreibe alle HTML-Ausgaben + kopierte Assets dorthin und verstreue niemals Design-Dateien im Repository-Stamm. Für jedes ausgewählte System importiere eine eigenständige Kopie mit agents/import-design-system.mjs (→ _ds/<slug>/), notiere die Bindung in der _d_meta.json des Projekts, lade dann den Prompt dieses Systems und folge ihm als verbindlichen visuellen Stil (lies _ds/<slug>/_ds_prompt.md). Während du baust, protokolliere jede UI-Ausgabe auch als Asset mit agents/record-asset.mjs (dies bootet sogar _d_meta.json für ein Projekt, das kein Designsystem verwendet) – vollständiger Ablauf in built-in-skills/use-design-system.md. Nimmst du ein bestehendes Projekt wieder auf? Wenn der Projektordner bereits existiert, lies zuerst seine _d_meta.json: wenn sie designSystems auflistet, lade den Prompt jedes gebundenen Systems und folge ihm vor dem Entwerfen (lies jede _ds/<slug>/_ds_prompt.md; frage nicht erneut, welches System verwendet werden soll).

6. Baue, zeige vor und verifiziere. Erstelle das Ergebnis nach system-prompt.md, zeige es dem Nutzer an, zeige es über HTTP vor (die genauen Werkzeuge findest du in deiner Umgebungsreferenz) und bestätige, dass es sauber lädt. Behebe alle Fehler, bevor du fertig bist.

Hinweise

• system-prompt.md ist die einzige Quelle der Wahrheit für die Handwerkskunst; references/<umgebung>.md ist die einzige Quelle der Wahrheit für das aufzurufende Werkzeug. Diese Datei orchestriert lediglich den Einstiegsablauf.
• Halte Ergebnisse in sich geschlossen: kopiere jedes Asset, auf das du verweist, in den Projektordner.