Unified Design System
Ein zentraler Einstiegspunkt, der alle Designbereiche abdeckt.
Regeln zum Laden von Ressourcen
Lade zu Beginn das Manifest. Lade in jeder Phase die Ressourcen, die für diese Phase benötigt werden. Die Generierung erfolgt nicht über Benutzerpräferenzprofile; die Skill-Architektur findest du in
skill-architecture.html, den Workflow inskill-workflow.htmlund die Versionsänderungen inCHANGELOG.md.
Wird beim Start geladen
| Ressource | Warum |
|---|---|
manifest.md | Um zu wissen, welche Bereiche und Ressourcen es gibt |
Ladebudget (Harte Obergrenze)
Dieses Skill hat 125 Dateien; alles zu lesen, bevor du anfängst = Aufgabe fehlgeschlagen.
| Einschränkung | Wert |
|---|---|
| Startladevorgang (nicht im Budget) | manifest.md – Manifest ist Pflicht, zählt nicht zum Kontingent |
| Maximal zusätzliche Regeldateien außerhalb der Hauptdatei | 4 |
| Gesamtumfang dieser Dateien | ≤1200 Zeilen (echte Obergrenze) |
| Einzeldatei >400 Zeilen | Nur die genannten §-Abschnitte lesen, nicht den gesamten Text |
Warum 4: Die tatsächlichen Kosten sind die Anzahl der Zeilen, nicht die Anzahl der Dateien (die 3 Pflichtdateien der Web-Linie machen nur 37% der 1200 Zeilen aus). Die Dateianzahl-Obergrenze ist eine Heuristik, um „hier ein bisschen, da ein bisschen lesen“ zu vermeiden – 4 Dateien × durchschnittlich 300 Zeilen ≈ 1200 Zeilen, die beiden Einschränkungen sind konsistent. Betrachte das 4. Kontingent nicht als standardmäßigen Puffer, den du frei ausgeben kannst; bevor du es ausgibst, führe die unten stehende Entscheidung für die Ablage durch.
Das Budget wird in der folgenden Reihenfolge ausgegeben: ① Bereichs-Hauptdatei (domains/web/distilled-playbook.md / domains/poster/MODE.md / domains/brand/MODE.md) ② Im Bereich als „obligatorisch“ gekennzeichnete Datei (z. B. domains/web/anti-slop/MODE.md) ③ Nur bei Bedarf an konkreten Werten den entsprechenden §-Abschnitt in shared/ lesen.
Nach der aktuellen Struktur sind für eine Web-Aufgabe 3 Dateien Pflicht: distilled-playbook.md + domains/web/anti-slop/MODE.md + references/flow.md. Materielldateien in drei Stufen, lokale Schriftartenliste, Engineering-Fallstricke P1–P11 sind alle in dieser Datei enthalten, kein tieferes Eintauchen nötig. Zweck des 4. Kontingents: In Phase ④ shared/react-bits-assets.md lesen (§0 + §3, vollständiges Lesen der 1626 Zeilen ist verboten). In allen anderen Fällen ist es ein Puffer (wenn eine 4. Datei wirklich benötigt wird, siehe „Wo neue Regeln abgelegt werden“).
Bereichsprinzipien sind bereichsspezifisch unterteilt (Referenzebene, zählen nicht zum Pflichtkontingent): Bereichsübergreifender gemeinsamer Kern shared/design-principles.md (§1.1–§1.12) + Bereichs-Teilmengen shared/design-principles-web.md / shared/design-principles-brand.md / shared/design-principles-poster.md. Lademethode: Je nach aktuellem Bereich nur die entsprechende Teilmenge laden, bei Bedarf verwenden (z. B. in Phase ① Wettbewerbsanalyse / Phase ③ Merkmal-Design einer Web-Aufgabe erst die entsprechenden Abschnitte von design-principles-web.md lesen), Referenzebene, zählt nicht zu den 3 Pflichtkontingenten, der vollständige gemeinsame Kern muss nicht vollständig gelesen werden.
references/gates.md und constraints.md sind optionale Referenzen (Entscheidungsdetails / Grenzfälle), sie zählen nicht zu den 3 Kontingenten – bei Bedarf nachschlagen, sonst überspringen.
Verboten: „Um einen vollständigen Überblick zu bekommen“ alle verwiesenen Dateien vollständig lesen; vollständiges Lesen von shared/react-bits-assets.md (1626 Zeilen; Komponentenauswahl siehe §3 Kategorisierung / §5 Details) oder shared/design-philosophies.md (Philosophieauswahl siehe §Auswahlhilfe); mehr als 4 Dateien hintereinander lesen, ohne mit der Arbeit zu beginnen.
Wo neue Regeln abgelegt werden (Entscheidung für die Ablage, zuerst hier entlang, dann das Budget verwenden)
Wenn eine neue Regel hinzugefügt wird, in der Reihenfolge prüfen. Wenn die ersten drei Schritte zutreffen, darf keine neue Datei erstellt werden:
- Wird von allen Bereichen und allen Aufgaben benötigt? → In die Hauptdatei ablegen (Hauptdateien zählen nicht zum Budget – das sind die korrekten Kosten für eine Regel auf Muss-Ebene: Wenn sie jedes Mal verwendet wird, sollte sie jedes Mal da sein). Kriterium: Wenn eine Poster-Aufgabe und eine Web-Aufgabe ohne sie Fehler machen würden.
- Gehört es nur zum Ablauf eines bestimmten Bereichs? → In die bereits vorhandene Pflichtdatei dieses Bereichs einfügen (z. B. bei Web in
distilled-playbook.md), keine neue Datei erstellen. SSoT: Besser mit Untertiteln trennen als eine neue Datei zu öffnen. - Nur Werte / Details / Nachschlagetabelle? → In die entsprechende Datei in
shared/, bleibt Referenzebene (zählt nicht zum Pflichtkontingent, wird nur bei Bedarf nachgeschlagen). Wenn die Hauptdatei relevant ist, einen Zeiger hinterlassen. - Nichts von oben, und wirklich jedes Mal erforderlich? → Dann darf eine neue 4. Pflichtdatei hinzugefügt werden. In diesem Fall in der „Bereichs-Schnellübersicht“ vermerken, zu welcher Bereichslinie sie gehört, und bestätigen, dass die 1200-Zeilen-Grenze noch eingehalten wird (aktuell verwendet die Web-Linie 439/1200).
Warnlinie für Hauptdateien: ≤400 Zeilen. Wenn sie überschritten wird, zuerst Inhalte, die „nicht jedes Mal benötigt werden“, gemäß den Kriterien zurück in die Referenzen verschieben (einen Satz als Kriterium hinterlassen), anstatt die Datei weiter aufzublähen – jede Zeile, die in der Hauptdatei hinzukommt, wird von jeder Aufgabe einmal bezahlt.
Wenn das Budget aufgebraucht ist, anhalten: Mit den bereits gelesenen Inhalten ausliefern und bei der Auslieferung eine Zeile hinzufügen: „X (Ladebudget) übersprungen“. Ein vollständiger Plan basierend auf 3 Dateien ist besser als 10 Dateien zu lesen und keine Ausgabe zu haben.
Selbstprüfung vor der Auslieferung (zählt nicht zum Ladebudget)
Nachdem das HTML erstellt wurde, empfiehlt es sich, einen Headless-Browser-Renderingdurchlauf durchzuführen (npx playwright screenshot / lokales Chrome·Edge --headless --screenshot), zumindest in den beiden Breiten 1440 und 390 einen Screenshot zu machen und drei Dinge zu überprüfen:
- Ist der erste Bildschirm leer? – Wenn Animationen nur durch JS/IntersectionObserver sichtbar werden, können sie bei langsamen Rechnern und in Screenshot-Szenarien komplett weiß sein; der Inhalt des ersten Bildschirms muss direkt sichtbar sein.
- Gibt es horizontalen Overflow oder kleben Texte am Rand? – Überprüfe, ob die
padding-Kurzschreibweise der Blöcke den linken und rechten Innenabstand des Containers abdeckt. - Überlaufen Überschriften? – Wenn eine Überschrift auf Desktop-Breite mehr als 3 Zeilen hat, ist die
clamp()-Obergrenze oder Schriftgröße falsch.
Probleme sofort beheben, keine ungerenderten Seiten ausliefern. Diese drei Arten von Problemen sind mit dem bloßen Anschauen des Codes nicht erkennbar.
Selbstprüfungs-Budget (mit Obergrenze, um zu verhindern, dass die Selbstprüfung zu einer endlosen Nachbesserung wird): Maximal 2 Runden, jede Runde 2 Screenshots (1440 / 390), eine einzelne Runde ≤90 Sekunden. Wenn nach zwei Runden immer noch Probleme bestehen, aufhören und die verbleibenden Probleme in den Auslieferungshinweis aufnehmen – Die Selbstprüfung ist ein Mittel, um drei Arten von strukturellen Problemen zu finden, nicht um die Seite perfekt zu machen.
7 Kern-Designprinzipien
Diese 7 Prinzipien sind der seelische Leitfaden des Designs. Keine Checkliste, sondern Denkrichtungen.
| Prinzip | Kernfrage | Bedeutung |
|---|---|---|
| Fundiert | Weiß, für wen du entwirfst und welches Problem du löst | Kläre vor dem Handeln: Wer ist die Zielgruppe? Was sollen sie nach dem Betrachten der Seite tun? Was ist die eine Kernbotschaft? Design ohne Fundament = Selbstbeweihräucherung |
| Charaktervoll | Hat einen übergreifenden Ton, dem alle Entscheidungen dienen | „Wenn diese Seite ein Mensch wäre, welches Temperament hätte sie?“. Definiere es mit einem Wort (z. B. „elegant“/„kraftvoll“/„rebellisch“). Die folgenden Farben, Schriftarten, Abstände und Animationen drehen sich um dieses Wort |
| Systematisch | Alle Elemente gehorchen derselben visuellen Grammatik | Farbe, Schrift, Abstand, Animationsdauer, Interaktionsfeedback – erstelle einheitliche Regeln, dann erbt jedes neue Element automatisch dieses System, keine Einzelentscheidungen nötig. Siehe shared/system-design.md §2 Auswahl des Design-Ausgangspunkts + §3 Drei-Parameter-Einflussmatrix |
| Merkwürdig | Mindestens ein Detail, das zum Innehalten einlädt | Das kann eine einzigartige Interaktion, eine besondere Materialität, eine Textbehandlung oder eine räumliche Beziehung sein. Es muss nicht komplex sein – eine sorgfältig ausgeführte einfache Idee ist besser als zehn grobe, komplexe Effekte |
| Mit Temperatur | Vermittelt Emotion, häuft nicht nur Informationen an | Welches Gefühl vermittelt die Seite? Ruhig, lebendig, warm, geheimnisvoll, technisch, natürlich? Emotion ist keine Dekoration, sondern die treibende Kraft des Designs |
| Qualitativ hochwertig | Die Auslieferung muss vollständig und nutzbar sein, kein halbfertiges Produkt | Jeder Zustand ist berücksichtigt (loading/empty/error/success), die mobile Ansicht ist vollständig, prefers-reduced-motion wird unterstützt, CSS-Variablen werden verwendet |
| Mit Hingabe | Hast du dieses Design ernsthaft angegangen? | Keine wichtigen Inhalte auslassen, nicht schludern, nicht mittelmäßig liefern, keine schnelle Lösung. Jedes Detail wird ernst genommen, mit vollem Einsatz, ohne Abstriche |
Single Source of Truth Vertrag (SSoT · Vor Änderung dieser Datei lesen)
Bisherige Hauptfehlerart dieser Datei: Dieselbe Regel wurde an 3–4 Stellen kopiert – einmal im Prozess-Ablauf, einmal im harten Checkpoint, einmal im Qualitäts-Gate und noch einmal in den Constraints. Die Folge war nicht „mehr Sicherheit“, sondern wurde als leere Wiederholung abgehakt: Einmal abgehakt galt es als erledigt, die Regel war tatsächlich unwirksam. Das ist der Mechanismus hinter „schriftliche Befolgung ≠ code-level Befolgung“.
Schichtenverantwortung (Neue Inhalte danach zuordnen, Fehlplatzierung gilt als Mangel):
| Schicht | Position | Enthält nur | Enthält nicht |
|---|---|---|---|
| Definitionsschicht | Constraints 0–9 im Abschnitt „Arbeitsweise Constraints“, „Gemeinsame Untergrenze“ | Die einzige Definition der Regel | — |
| Prozessschicht | Tabellen der Phasen im Anpassungs-Designprozess | Was wann tun + Welche Datei nachschlagen + Zeiger („gemäß Constraint X“) | Das Wiederholen der Constraint-Definition ist verboten |
| Gate-Schicht | Ausführungs-Gate, Qualitäts-Gate, Engineering-Fallstrick-Gates in Phase ④ | Überprüfungsaktion / PASS-Schwellenwert / Check-Fragen | Das Wiederholen von systemischen Definitionen ist verboten |
Zuordnungstest (Beim Hinzufügen einer Regel immer fragen): Definiert diese Regel, oder überprüft sie eine Regel? → Die Definition kommt in die Definitionsschicht, die Überprüfung in die Gate-Schicht, eine Regel kann nur an einem Ort landen. → Weiter: Beurteilungsbasierte Regeln (Geschmack, Kohärenz, Reichhaltigkeit, nicht mechanisch prüfbar) gehen in das Qualitäts-Gate; faktenbasierte Regeln (mit grep/ls/Assertion überprüfbar) gehen in das Engineering-Fallstrick-Gate. Falsche Zuordnung macht die Regel unwirksam.
Designprozess (6 Phasen)
| Phase | Was tun | Liefergegenstand |
|---|---|---|
| ① Recherche & Anforderung | Implizite Anforderungen extrahieren, Bereich bestimmen, drei Parameter festlegen | Anforderungs-Zusammenfassung (für CP1) + Drei Parameter |
| ①.5 Aktive Deduktion | Eine einzeilige Anforderung zu einem vollständigen Brief erweitern | Überarbeitetes Brief |
| ② Ideenfixierung | Direkt 1 höchste Richtung festlegen (eine von vier Achsen) | Richtung + Kernspannung (für CP2) |
| ③ Konzeption & Narration | Informationsarchitektur, Scroll-Narration, Intentions-Mapping | Intention Map (zwingend; ohne diese darf Phase ④ nicht betreten werden) |
| ④ Systemdesign | Design-Grammatik, Animations-Bestandsaufnahme, Fähigkeits-Bestandsaufnahme; Animations-/Interaktionskomponenten zuerst in shared/react-bits-assets.md §0 (Einlösungsstatus: 11 lokal ✅, Rest 🌐 erfordert Internet) + §3 Auswahl prüfen, nur ✅ oder selbst erstellte Äquivalente verwenden | Systemdesign-Tabelle + Fähigkeitsliste ≥8–10 Punkte (Quelle der Komponente muss angegeben werden: react-bits ✅ / 🌐 / selbst erstellt) |
| ⑤ Visuelle Umsetzung | Schrift / Farbe / Layout / Material umsetzen | Seitenprodukt (HTML/CSS/JS, Form siehe shared/code-generation-strategy.md §3.1; einschließlich Erklärung zur Umsetzung oder Deaktivierung von Schrift und Material) |
| ⑥ Interaktion & Auslieferung | Interaktion, Performance, drei Gates | Fertigprodukt, das die Gates passiert hat (für CP4) + Eine Zeile an usage-log.md anhängen (Datum / Aufgabe / Seed / Maus-Fraktion / Komponente) |
Erst wenn eine Phase erreicht ist, den entsprechenden Abschnitt von
references/flow.mdlesen – kein vollständiges Lesen nötig. Jeder Abschnitt enthält die drei Spalten „Was tun / Spezifischer Inhalt / Was nachschlagen“.
Bereichsverzweigungen (wichtig): Die obigen 7 Schritte sind der vollständige Ablauf für Web. Die anderen beiden Bereiche folgen ihrer eigenen Linie und wenden nicht die Phasen und Gates von Web an:
- Poster →
domains/poster/MODE.md§8 5 Schritte: Größe festlegen → Aussage festlegen → Familie wählen → Drei Schichten anordnen → Selbstprüfung mit Miniaturansicht - Marke →
domains/brand/MODE.mdB1–B5: Strategie (9-Fragen-Methode) → Visuelles Muster → Logo → Markenboard → Ausgabe
Video → domains/video/MODE.md: Zuerst entscheiden, ob es verwendet werden soll (§1) → Rolle und Volumen bestimmen (§2) → Route wählen (§3) → Fusion durchführen (§4, 90% der Brüche sind an den Nähten) → V1–V9 Liefercheck durchführen.
Werkzeuge sind Nebenwege, nicht im Hauptkreislauf: PPT / Videoexport / Redesign-Audit / Design Thinking werden jeweils unabhängig ausgelöst (siehe „Bereichs-Schnellübersicht“), laufen parallel zu den 6 Phasen und haben keine Phasennummer.
Arbeitsweise Constraints 0–9 (Schnellübersicht)
| # | Regel | Kriterium / Ausnahme |
|---|---|---|
| 0 | Explizite Benutzeranweisung > Allgemeiner Standard | Bei Konflikt mit harten Regeln darauf hinweisen und Alternative anbieten; wenn der Benutzer darauf besteht, befolgen |
| 1 | Direkt die höchste Richtung festlegen, keine parallelen Optionen anbieten | Eine der vier Achsen (extreme Zurückhaltung / Dichte / Bewegung / Material) bis zum Ende verfolgen; Schwierigkeit der Umsetzung ist kein Grund für eine Herabstufung (Schwierigkeit beeinflusst nur den Umsetzungsweg, nicht die Lösung) |
| 2 | = Szenarioerweiterung von Constraint 1 | „Egal“ → 1 Lösung; „Gib mir 2–3 zum Vergleichen“ erst dann mehrere Lösungen |
| 3 | Bei Änderungen immer nur eine Frage stellen | Mehrere Fragen = Benutzer kann nichts zuordnen |
| 4 | Feinheit vor Geschwindigkeit | Animation ohne Motivation / Rhythmus völlig flach / fehlende Zustände → Anhalten und reparieren |
| 5 | Anzahl der Sections wird durch die Planung bestimmt | Weniger als 5 müssen begründen, „warum Minimalismus für dieses Brief geeignet ist“; Auffüllen oder Faulheit verboten |
| 6 | Das Muster ist ein Samen, kein Gerüst | „Stil auswählen → Gerüst überstülpen“ verboten, muss vor Ort neu zusammengesetzt werden |
| 7 | Samengetriebener Kohärenzvertrag | Jede Dimension muss entweder mit dem Samen mitschwingen oder es muss ein „bewusst weggelassen“ notiert werden |
| 8 | Disziplin gegen konservative Generierung | ≥3 technische Sprachen; Interaktion muss real sein; Text muss sich auch bewegen |
| 9 | Disziplin bei der Nutzung der Materialbibliothek | Zuerst Samen festlegen → Gleiche Familie auf dieser Seite ≤1 → Nutzungserklärung schreiben |
| 10 | Lösung einfrieren, nicht bequem auf Vorhandenes zurückgreifen | Erst „Was braucht die Lösung“ auflisten, dann „Was habe ich“ prüfen; bei Ersatz muss „Geplant / Tatsächlich gemacht / Warum nicht äquivalent“ notiert werden, stiller Ersatz = Fehler |
Vollständige Regeln, Randfälle und Begründungen (einschließlich der Konfliktentscheidungsdetails zu Constraint 0) finden sich in
references/constraints.md. Constraint 0 hat die höchste Priorität und überschreibt die übrigen Constraints und Gates (mit Ausnahme der Engineering-Untergrenze).
Gates-Schnellübersicht (Vor der Auslieferung obligatorisch)
| Gate | Zeitpunkt | Was prüfen | Was tun, wenn nicht bestanden |
|---|---|---|---|
| Ausführungs-Gate | Vor Phase ⑤ | Fähigkeitsliste ≥8–10 Punkte (muss ≥1 Text-Animation / ≥1 WebGL·Canvas / ≥1 GSAP·Scroll-Orchestrierung enthalten); Wiederholung derselben Familie muss einen Samen-Grund haben (siehe usage-log.md); Aufzeichnung der Netzwerkabrufe (Was abgerufen → Von wo → Ergebnis, A3); Wenn die Lieferform eingeschränkt ist, die maximale erreichbare Anzahl angeben und den Grund für die Einschränkung notieren; keine fingierten Inhalte und keine stillschweigenden Lücken | Liste ergänzen, dann Phase ⑤ betreten |
| Qualitäts-Gate 7 Prinzipien | Ende Phase ⑤ · Vor Phase ⑥ | Die Lieferung muss eine PASS/HOLD-Entscheidung enthalten (taste-rules.md §8, kein „insgesamt gut“ als Freigabe); Critique 10 Dimensionen + Medien/Animation/Layout: „zurückhaltend und reichhaltig“? + Samenkohärenz + 7 Fragen gegen Konservatismus | Zur entsprechenden Phase zurückkehren und ändern, keine Auslieferung von Halbfertigprodukten |
| Engineering-Fallstrick-Gate P1–P11 | Vor der Auslieferung | Mechanische Überprüfung mit grep / ls: Schrift-Einbindung, CDN-Fallback, horizontaler Overflow, kursive Unterlängen… | Bis zum PASS reparieren, Lieferung mit FAIL ist verboten |
Die Detailkriterien für das Ausführungs-Gate und das Qualitäts-Gate finden sich in
references/gates.md; die Engineering-Fallstricke P1–P11 sind unten aufgeführt, werden jedes Mal verwendet und werden nicht weiter nach unten verschoben.
Engineering-Fallstrick-Gate P1–P11 (Vor der Auslieferung einzeln durchlaufen)
Abgrenzung zum obigen Qualitäts-Gate (entscheidend): Das Qualitäts-Gate beurteilt „Ist es gut?“ – Geschmack, Kohärenz, Reichhaltigkeit, gehören zur beurteilungsbasierten Kategorie, hängen vom ästhetischen Empfinden ab und können nicht mechanisch geprüft werden. Dieses Gate prüft „Ist etwas kaputt?“ – Bekannte Engineering-Mängel, die die Benutzbarkeit oder das Erscheinungsbild tatsächlich beeinträchtigen, gehören zur faktenbasierten Kategorie und können durch Überprüfung geprüft werden. Aufnahmeprinzip: Es werden nur Punkte aufgenommen, die mechanisch mit grep / ls / Laufzeit-Assertionen überprüft werden können. Beurteilungsbasierte Regeln gehören nicht in dieses Gate (bleiben im Qualitäts-Gate), da sie sonst zu einem leeren „Selbstbestätigungs“-Häkchen verkommen. Ausführung: Vor der Auslieferung einzeln durchlaufen; bei FAIL eines beliebigen Punktes → reparieren und erneut prüfen, Lieferung mit FAIL ist verboten.
| # | Falle (echt erlebt) | Überprüfungsmethode | PASS-Bedingung |
|---|---|---|---|
| P1 | Nur Hintergrund bewegt sich, Inhalt nicht (häufigster, schädlichster für den „Gesamteindruck“) | Mit grep jedes Inhalts-Section auf Scroll-Animation-Bindung prüfen | Inhaltscontainer haben eine Scroll-verknüpfte translateZ/scale/rotate, nicht nur opacity/clip-path; und Hintergrund und Inhalt werden vom gleichen Progress gesteuert |
| P2 | Tiefen-/Dekorations-Ebene drückt den Inhalt | Prüfe z-index-Stapelung + pointer-events | Nah-/Deko-/Rauschebene haben z-index niedriger als die Inhaltsebene, und alle haben pointer-events:none |
| P3 | Übergangsblitzen/-Flackern blendet | Prüfe den opacity-Spitzenwert und die duration des flackernden Elements | Spitzenwert ≤ .4 und Dauer ≥ .3s (quantifizierbarer Schwellenwert, darüber hinaus blendend) |
| P4 | prefers-reduced-motion nicht wirklich deaktiviert | Mit grep den Medienabfrage-Zweig prüfen | Es existiert ein Zweig, der WebGL/schwere Animationen/Blinken abschaltet, nicht nur die Dauer verkürzt |
| P5 | Schriftart/JS referenziert, aber Datei nicht abgelegt | ls Ausgabeverzeichnis assets/fonts/ und .js | Die src von @font-face und die von <script src> referenzierten Dateien existieren physisch (Ausnahme bei Einzeldatei-Lieferung: Stattdessen prüfen, ob die Lieferung das @font-face-Fragment + eine TTF-Liste enthält); wenn interactive-editing.js verwendet wird, muss die Datei ebenfalls vorhanden sein und die Seite muss umfassend CSS-Variablen verwenden (sonst kann das Panel die Parameter nicht anpassen) (zusammen mit Qualitäts-Gate 6 geprüft, hier der Überprüfungsvorgang) |
| P6 | CDN-Abhängigkeit ohne Fallback, Bibliothek fehlt = weißer Bildschirm/kein Cursor | Prüfe mit grep, ob das CDN <script> einen Fallback-Zweig hat | Bei Fehlschlagen des Ladens kritischer Bibliotheken muss die Seite noch lesbar sein, der Cursor darf nicht verschwinden (Ausblenden des Systemcursors nur nach Bestätigung der JS-Bereitschaft) |
| P7 | Animation animiert Nicht-GPU-Eigenschaften | Prüfe mit grep transition/animation/GSAP-Eigenschaften | Nur transform/opacity/filter (+ Kameraparameter), kein width/top/left |
| P8 | Mobile Ansicht nicht deaktiviert | Prüfe WebGL-Schalter am Breakpoint | Bei ≤820px schwere WebGL deaktivieren, auf CSS 3D-Downgrade umsteigen |
| P9 | AI-Slop-Schriftart verwendet | Prüfe mit grep font-family / @font-face | Die angezeigte Schriftart ist nicht Inter / Fraunces / Instrument Serif (diese drei sind überbeansprucht, siehe anti-slop MODE.md) |
| P10 | Animationsdauer aus dem Rahmen / Kurve aus der Familie | grep -oE "transition:[^;]*[0-9]+m?s" und grep -oE "cubic-bezier\([^)]*\)"; wenn transition: all vorkommt, als Problem vermerken | Alle Dauern liegen innerhalb der 4 Stufen von motion-rules.md §1, alle Kurven ⊆ 4 Familien von §2, kein all |
| P11 | Fokus nicht sichtbar / Steuerelemente semantisch mangelhaft | Tab einmal durchgehen (oder nach page.keyboard.press("Tab") im Headless-Modus Screenshot machen); mit grep prüfen: outline:s*none / role="dialog" (muss aria-modal haben) / <th (muss scope haben) | Jedes Element hat focus-visible (≥2px, Kontrast 3:1); Dialog hat Fokusfalle + Esc; Tabellenkopf hat scope/caption (WCAG 2.4.7 / 1.3.1) |
Rückkopplungsschleife (Damit das Gate sich selbst weiterentwickelt): Jedes Mal, wenn ein Engineering-Fallstrick behoben wird, ihn sofort in eine überprüfbare Assertion umwandeln und in diese Tabelle aufnehmen (Überprüfungsmethode + PASS-Schwellenwert klar angeben), anstatt nur zu sagen „nächstes Mal darauf achten“. Beurteilungsbasierte Lektionen kommen in das Qualitäts-Gate, faktenbasierte Lektionen in dieses Gate – wenn die Kategorisierung falsch ist, wird die Regel unwirksam.
Bekannte Einschränkung (ehrlich markiert): Dieses Gate kann nur bekannte und überprüfbare Fallstricke abfangen, nicht geschmackliche Fehler und völlig neue Fallstricke. Geschmack wird durch das Qualitäts-Gate + menschliche Abnahme abgedeckt; völlig neue Fallstricke werden nach und nach durch die obige Rückkopplungsschleife aufgenommen.
Nach der Lieferung: Feedback → In welche Phase zurückkehren
Dies ist der Rückpfad des Kreislaufs. Zuerst bestimmen, „welche Schicht falsch war“, dann entscheiden, wie viele Schritte zurückgegangen wird – direkt von vorne zu beginnen ist der teuerste Fehler.
| Benutzer-Feedback | Wo liegt das eigentliche Problem | Zurück zu |
|---|---|---|
| „Nicht das, was ich wollte / Falsch verstanden“ | Anforderung | ① Neu ausrichten |
| „Zu flach / Zu konservativ / Wie eine Vorlage“ | Unzureichende Richtungsfestlegung | ② Höchste Richtung neu festlegen (eine von vier Achsen) |
| „Struktur chaotisch / Weiß nicht, wohin ich schauen soll“ | Informationsarchitektur und Narration | ③ Intention Map neu erstellen |
| „Nicht stimmig / Die Abschnitte wirken nicht wie ein Set“ | Systemdesign (Grammatik nicht einheitlich) | ④ Design-Grammatik neu aufbauen |
| „Sieht einfach nicht gut aus“ | Visuelle Ausführung | ⑤ Schrift/Farbe/Layout/Material anpassen |
| „Neu machen / Nochmal von vorne / Neu designen / Anderen Vorschlag“ | Explizite Anforderung einer neuen Version | Komplett neu machen (siehe drei harte Regeln unten) |
Nur Farbe / Schriftart / Abstand ändern → Nicht in die Phase zurückkehren, direkt ändern und das Ausführungs-Gate von ④ überspringen (siehe references/gates.md Punkt D).
Mehrere Runden von Mikro-Änderungen (gleiche Aufgabe fortgesetzt): Nach der ersten Lieferung sagt der Benutzer „nochmal anpassen / ein anderes Gefühl“, das gehört zur Fortsetzung derselben Aufgabe – direkt in die entsprechende Phase gehen (Farbe anpassen → ⑤, Richtung ändern → ② neu festlegen), nicht Phase ① wiederholen und auch nicht CP1 wiederholen; die Änderungen aus mehreren Runden zusammenfassen und dann einheitlich ausliefern, um zu vermeiden, dass der Benutzer durch jede Runde der Bestätigung genervt wird.
Große Richtungsänderung während des Prozesses (nach Phase ③): Benutzer sagt „Stil wechseln / Richtung falsch“ → Zurück zu ② neu festlegen (Anforderung hat sich nicht geändert, nur die Richtung war falsch, nicht zurück zu ①); bereits geschriebener Code muss gemäß der neuen Richtung neu strukturiert, nicht repariert werden; es ist verboten, auf der falschen Richtung weiter Details zu stapeln (wenn man „Richtung zu flach“ als „sieht nicht gut aus“ behandelt und die Schriftgröße anpasst, wird es auch nach zehn Runden nicht richtig).
Die Kosten einer Fehleinschätzung: Wenn man „Richtung zu flach“ als „sieht nicht gut aus“ behandelt und die Schriftgröße anpasst, wird es auch nach zehn Runden nicht richtig – Zuerst die Ursache finden, dann handeln.
Neu machen vs. Reparieren (Drei harte Regeln)
① Explizite Aufforderung zum Neumachen → Muss eine komplett neue Version sein, kein Austausch des Äußeren Wenn der Benutzer sagt „Neu machen / Nochmal von vorne / Neu designen / Anderen Vorschlag“:
- Muss ein neuer Samen ausgewählt werden (Constraint 7), eine neue Intention Map geschrieben werden, der Code aus der vorherigen Version darf nicht wiederverwendet werden
- Der Auslieferungshinweis muss eine „Liste der Probleme der vorherigen Version“ enthalten: Welche Punkte waren in der vorherigen Version falsch → Wie diese Version sie vermeidet, als Nachweis, dass es sich nicht um die gleiche Lösung mit anderem Farbschema handelt
- Kriterium: Wenn zwei der drei Punkte „Layout-Familie / Anzahl der Animationsebenen / Schriftarten-Rolle“ zwischen alter und neuer Version identisch sind → Dies ist eine Reparatur, kein Neumachen, muss neu gemacht werden
② „Nicht bestanden“ ohne Angabe von Gründen → Drei Optionen anbieten, keine offene Frage stellen Wenn der Benutzer nur sagt „Nicht bestanden / Nicht zufrieden / Geht nicht“, frage nicht „Welches Gefühl möchtest du?“ (Der Benutzer kann es nicht beantworten). Gib ihm drei Optionen zur Auswahl:
- Richtung falsch (Ausstrahlung falsch) → Zurück zu ② Samen neu festlegen
- Struktur falsch (Das, was man sehen soll, ist nicht sichtbar) → Zurück zu ③ Informationsarchitektur und Narration neu machen
- Ausführung nicht gut (Richtung richtig, nur nicht detailliert genug) → Zurück zu ⑤ Punkt für Punkt anpassen gemäß
shared/taste-rules.md§1 sechs Variablen
Stelle immer nur diese eine Frage (Constraint 3), sobald der Benutzer seine Wahl getroffen hat, direkt in die entsprechende Phase gehen.
③ Reparatur-Obergrenze: 2 Runden maximal, danach zwingend neu machen Wenn die Reparatur derselben Seite nach 2 Runden immer noch als „nicht bestanden“ gilt → Die dritte Reparatur ist verboten, es muss zwingend auf Neumachen hochgestuft werden. Grund: Wenn zwei Reparaturrunden das Problem nicht gelöst haben, liegt es auf der Ebene der Richtung oder Struktur, weiter an der Optik zu schrauben ist nur Verschwendung – „Richtung zu flach als siehst nicht gut aus behandeln und zehn Runden lang daran herumdoktern“ ist ein dokumentiertes Fehlermuster.
🛑 CHECKPOINT (Nur das Nötigste fragen)
Dieses Skill fragt standardmäßig nicht nach der Richtung (Constraint 1), aber an diesen 5 Punkten muss angehalten werden. Darüber hinaus keine Zwischenfragen – häufiges Unterbrechen ist eine andere Form von Pflichtverletzung.
| # | Punkt | Grund zum Anhalten | Was gibst du dem Benutzer | Was du nicht tun sollst |
|---|---|---|---|---|
| CP1 | Nach Abschluss der Anforderungsinterpretation | Fehlinterpretation hat die höchsten Kosten | Eine Zusammenfassung der Anforderung: Seitentyp + Zielgruppe + Ton + Drei Parameter (oder Standard 8/6/5) | Den Benutzer zwischen 2–3 Optionen wählen lassen (verstößt gegen Constraint 1) |
| CP2 | Nach Festlegung der höchsten Richtung | Falsche Richtung macht alles danach nutzlos | Bildhafte Beschreibung der einen Richtung (≤3 Sätze), frage „Ist diese Richtung richtig?“ | Nur Fachbegriffe nennen (Schriftartname/Farbwert), die der Benutzer nicht versteht |
| CP3 | Wenn der Benutzer Änderungen wünscht | Einmal mehrere Dinge ändern = keine Zuordnung möglich | Immer nur eine Frage stellen, bestätigen, dann die nächste (Constraint 3) | Alle 5 Fragen auf einmal stellen |
| CP4 | Vor der Auslieferung | Ohne bestandene Gates keine Auslieferung | Ergebnisse der Überprüfung durch das Qualitäts-Gate 7 und Engineering-Fallstrick-Gate P1–P11 (welche PASS, welche übersprungen wurden und warum) | Mündlich behaupten „wurde geprüft“, ohne Ergebnisse zu liefern |
| CP5 | Wenn der Benutzer sagt „es ist gut / reicht so“ | Dann aufhören | Ein abschließender Satz + was noch fehlt (falls vorhanden) | Weitermachen, selbst eine nächste Optimierungsrunde starten |
Warnsignal (Selbstprüfung): Wenn es 3 aufeinanderfolgende Phasen ohne eine einzige Benutzereingabe gab und du nicht bei CP1/CP2 angehalten hast – das bedeutet, du triffst Entscheidungen für den Benutzer, gehe zurück zu CP1.
Was kein Checkpoint ist (fragen macht es schlimmer): Welche Schriftart wählen, welchen Farbwert verwenden, wie viele Sections, welche Animationskomponente – das sind deine Entscheidungen, nicht die Aufgabe des Benutzers.
Benutzerintention Routing
| Was der Benutzer sagt | Startpunkt | Erklärung |
|---|---|---|
| „Schreibe eine Seite/eine Komponente“ (klare Anforderung) | ① Anforderungsinterpretation → ② Richtung festlegen → ③ Intention Map → ④ Systemdesign → Auslieferung | Das Brief basiert auf den expliziten Anforderungen des Benutzers; allgemeine Constraints (einschließlich Constraint 8) greifen nur in den Dimensionen, die der Benutzer nicht spezifiziert hat, und überschreiben keine expliziten Anweisungen (Constraint 0) |
| „Schnell etwas liefern“ / „Vorgefertigtes Thema verwenden“ / „Skin wechseln / Thema wechseln“ | Schnelle Themenlinie: Schnellübersicht in assets/themes/README.md lesen (Hell/Dunkel → Szenario → Akzentfarbe in drei Schritten) → 1 Set auswählen → dessen :root-Variablen kopieren → --accent gemäß Marke leicht anpassen → Auslieferung | Nur wenn der Benutzer explizit danach fragt oder klar sagt, dass es eilt; in diesem Fall Constraint 6 explizit ausnehmen (gemäß Constraint 0: Benutzeranweisung > Allgemeiner Standard). In der Auslieferung angeben, welches Thema verwendet und welche Variable geändert wurde. Flaggschiff-Aufgaben gehen standardmäßig nicht diesen Weg |
| „Hilf mir, eine Landing Page zu designen“ (Richtung muss erkundet werden) | Nach ①② direkt die höchste Richtung festlegen und weitermachen | Die Richtung muss nicht vom Benutzer bestätigt werden |
| „Ändere den Stil dieser Seite“ (Code bereits vorhanden) | Ab Phase ⑤ Visuelles Design | Diagnose + minimale Änderung; bei neuen/ersetzten Animationen eine „lokale Intention Map-Motivationstabelle“ (nur die geänderten Sections abdecken) ergänzen; reine Farb-/Schrift-/Abstandsänderungen sind vom Ausführungs-Gate der Phase ④ freigestellt (siehe references/gates.md Punkt D) |
| „Ich weiß nicht, welchen Stil ich nehmen soll“ | ①② direkt die höchste Richtungslösung angeben | Nicht 2–3 parallele Richtungen zur Auswahl stellen (Constraint 1) |
| „Markendesign machen“ / „Plakat machen“ | Entsprechende Bereichsdatei laden | Marke → domains/brand/MODE.md; Plakat → domains/poster/MODE.md |
| „Ein Hintergrundvideo / ein Video im Hero-Bereich einfügen“ | domains/video/MODE.md laden | Zuerst §1 prüfen (ob Video zwingend nötig ist) → §2 Rolle und Volumenobergrenze → §4 Fusion → §9 V1–V9 Prüfung |
| „Ein Backend / Admin-Panel / Daten-Dashboard erstellen“ | Zuerst das Gerüst und die Tabelle festlegen, nicht das Dashboard | design-patterns.md §6.4 Lieferreihenfolge: Gerüst → Tabellenfilter → Formular-Dialog → Dashboard |
| Unsicher | Den Benutzer fragen | Neu designen / Vorhandenes ändern / Stilberatung benötigt |
Bereichs-Schnellübersicht
Ein Überblick über die Werkzeugklasse (Review / Redesign / Thinking / Präsentation / Videoexport) und die Auswahl findest du in
tools/README.md.
| Bereich | Auslöser | Ladepfad |
|---|---|---|
| Web-Seite | Landing Page / Webseite / Marketingseite | domains/web/distilled-playbook.md (Argumentationsebene, zuerst lesen) + domains/web/anti-slop/MODE.md (Anti-AI-Baseline); domains/web/integrated-rules.md (Regelverzeichnis → shared/) + domains/web/common-exceptions.md (Ausnahmeentscheidung); genaue Werte in shared/ nachschlagen, CSS in domains/web/design-patterns.md / shared/css-patterns.md |
| Backend / Admin-Panel | Backend / Admin-Panel / Dashboard / Daten-Dashboard / CRM | domains/web/design-patterns.md §4 Steuerungsspezifikation + §6 Backend-Interface (Gerüst/vier Vorlagentypen/Dichte) + domains/web/integrated-rules.md §4 Token-Vertrag + shared/interaction-rules.md §7 Tastatureffizienz |
| Markendesign | Logo / Markenboard / Markendesign | domains/brand/MODE.md + domains/brand/brand-protocol.md + domains/brand/logo-concept-methods.md + domains/brand/visual-modes.md |
| Plakatdesign | Plakat / Poster / Werbebild / Aufsteller | domains/poster/MODE.md (zuerst Größe §1 → Aussage → Familie §3 wählen → Drei Schichten §4 anordnen) |
| Web-eingebettetes Video | Hintergrundvideo / Hero-Video / Produktdemonstrationsvideo / Scroll-Video | domains/video/MODE.md (zuerst §1 prüfen, ob Video verwendet werden sollte → §2 Rolle → §3 Route → §4 Fusion → §9 Liefercheck) |
| Design-Review | Review / Critique / Bewertung | tools/critique.md |
…
[aus Gründen der Kürze abgeschnitten]