Design Pro

Was macht Design Pro?

Eine Routing-Ebene über 328 Design-Playbooks aus sieben veröffentlichten Sammlungen, mit einer orchestrierten Pipeline für UI-Builds darüber. Jedes Playbook ist eine eigenständige Referenzdatei. Lies nur diejenigen, die die Aufgabe erfordert – lade nie die gesamte Bibliothek.

Erste Verzweigung: Handelt es sich um einen UI-Build?

Bevor du klassifizierst, entscheide, welchen der beiden Pfade die Anfrage verfolgt. Das richtig zu machen, unterscheidet herausragende von generischen Ergebnissen.

Pfad A – Erstellen / Entwerfen / Verbessern einer UI-Oberfläche (eine Seite, ein Bildschirm, eine Komponente, eine Landing Page, eine Marketing-Website, eine App-Ansicht oder ein Dashboard – und du wirst sie tatsächlich erstellen oder ändern):

→ Lies references/process/orchestrate.md und folge ihm. Es ist die obligatorische Pipeline. Sie treibt die gebündelte Anti-Generic-Engine (tastemaker) als Rückgrat an, leitet die anderen Bereiche in deren Dienst und erzwingt eine finale Anti-Slop-Prüfung. Gib einen UI-Build nicht direkt an ein einzelnes Playbook weiter – das ist der passive-Schaltbrett-Pfad, der „das hätte jede KI gebaut“ hervorbringt.

Pfad B – alles andere (Kritik ohne Änderung, Forschung und Strategie, eine reine Three.js-/Shader-Szene, ein Motion-Showreel, ein Spielsystem, eine SVG-Illustration, „welches Skill deckt X ab“):

→ Verwende das folgende Switchboard.

Switchboard (Pfad B)

1. Klassifiziere die Anfrage in einen der fünf unten stehenden Bereiche.
2. Lies die INDEX.md dieses Bereichs. Sie listet jedes Playbook im Bereich mit seiner vollständigen Trigger-Beschreibung auf.
3. Lies das eine oder die zwei Playbooks, die passen. Folge ihnen wie geschrieben – sie sind die Expertise; diese Datei ist nur das Switchboard.
4. Wenn nichts passt, sage dies und fahre mit deinem eigenen Urteil fort, anstatt eine schlechte Passung zu erzwingen.

Das Lesen von zwei Playbooks aus verschiedenen Bereichen ist normal und korrekt. Das Lesen von sechs ist ein Zeichen, dass die Anfrage in Phasen aufgeteilt werden muss.

Die fünf Bereiche

Bereich	Lies, wenn die Arbeit betrifft	Index
ui-craft (82)	Feinschliff, Typografie, Farbsysteme, Barrierefreiheit, Layout, Oberflächentexte, Interaktionsmuster, Animation und Bewegungsgefühl, visuelle Kritik. Die „sieht und fühlt sich das richtig an“-Ebene.	references/ui-craft/INDEX.md
web-build (121)	Landing Pages, Marketing-Websites, Design-Engineering, Scroll- und GSAP-Storytelling, Umwandlung von Referenzen oder Bildschirmaufnahmen in Prompts, Seitenaufnahme, Artikel- und Bildgenerierung. Die „baue die Seite“-Ebene.	references/web-build/INDEX.md
process (63)	Nutzerforschung, Interviews, Personas, JTBD, Journey Maps, Umfragen, Usability-Tests, Designsystem-Governance, Tokens, Design-Ops, Übergabespezifikationen, Stakeholder- und Verhandlungsarbeit. Die „wie die Arbeit entschieden wird“-Ebene.	references/process/INDEX.md
motion-3d (36)	Three.js-Szenen, Materialien, Beleuchtung, Wasser, God Rays, virtuelle Touren, Motion-Showreels, Web-Videopräsentationen und handgeschriebene SVG-Illustrationsstile.	references/motion-3d/INDEX.md
games (26)	Spielarchitektur, Gameplay-Loops, Kampfsysteme, Fähigkeiten-VFX, Gameplay-QA.	references/games/INDEX.md

Routing-Hinweise

Dies sind die Aufrufe, die leicht falsch gemacht werden können:

• „Mach es besser aussehen“ / „das sieht KI-generiert aus“ – wenn du die UI tatsächlich änderst, ist das Pfad A → references/process/orchestrate.md. Wenn es nur eine Kritik ist, dann ui-craft (tastemaker audit-Verb / better-interface).
• „Überprüfe diese Oberfläche“ (keine Änderung) → ui-craft (better-interface gibt einen einzigen bewerteten Bericht über alle sechs Linsen hinweg).
• Erstellen einer neuen Marketing-Seite → Pfad A → references/process/orchestrate.md. Leite nicht direkt an web-build + ui-craft als zwei separate Engines weiter; der Orchestrator führt eine Engine aus, fundiert und abgesichert.
• Eine Animation fühlt sich falsch an, aber du kannst nicht sagen, warum → ui-craft, die Animations-Playbooks. Easing und Dauer sind normalerweise die Ursache.
• „Sollten wir das überhaupt bauen“ → process, nicht ui-craft. Forschung und Strategie gehen dem Handwerk voraus.
• Ein statisches Design, das zu einem Video werden soll → motion-3d.
• Alles mit einer Figma-Datei als Eingabe → web-build (build-design).

Unterstützende Dateien

Einige Playbooks liefern Skripte und Referenzmaterial neben sich, in einem Geschwisterordner namens <playbook>.files/. Wenn ein Playbook auf seine eigenen Referenzen oder Skripte verweist, suche dort. Demos (Videos, Screenshots, Texturen) wurden nicht gebündelt – wenn ein Playbook auf eines verweist, behandle es als illustrativ und fahre fort.

Herkunft

Jedes Playbook trägt einen Header, der sein Quell-Repository und seinen Autor nennt. Alle sieben Sammlungen sind MIT-lizenziert und bis auf diesen Header unverändert gebündelt:

Sammlung	Autor	Playbooks
MengTo/Skills	Meng To	178
Owl-Listener/designer-skills	MC Dean	111
emilkowalski/skills	Emil Kowalski	15
jakubkrehel/skills	Jakub Krehel	14
ConardLi/garden-skills	ConardLi	6
codeswithroh/tastemaker	codeswithroh	2
elayadesign/ai-design-skills	Elaya	2

Behalte die Zuschreibung bei, wenn du den Inhalt eines Playbooks in kundenorientierte Arbeit zitierst.