Design Guard – Markenidentität

Erstelle eine vollständige DESIGN.md für ein Webprojekt mit Google Stitch.

Anleitung

0. Discover‑Check (MUSS vor allem anderen ausgeführt werden):
   • Prüfen, ob das Verzeichnis .dg-research/ existiert und JSON‑Dateien enthält.
   • WENN .dg-research/ NICHT existiert UND der Nutzer einen konkreten Firmennamen, ein Unternehmen, eine Marke, ein Café, Restaurant, Geschäft oder eine reale Entität genannt hat:
     • STOP. Teile dem Nutzer mit: „Ich empfehle, zuerst /dg-discover auszuführen, um [Firmenname] zu recherchieren. Das liefert eine DESIGN.md, die auf echten Markt‑ und Wettbewerbsdaten basiert, statt auf KI‑Standards. Möchtest du stattdessen /dg-discover ausführen?“
     • Fahre mit /dg-design nur fort, wenn der Nutzer explizit sagt, dass die Recherche übersprungen werden soll.
   • WENN .dg-research/ mit JSON‑Dateien existiert: Lese .dg-research/latest.json, um das Business‑Briefing, die Wettbewerbsanalyse und die Markenfarben zu erhalten. Diese Recherchedaten sind deine PRIMÄRE Quelle für den Business‑Kontext – verwende sie anstelle von Projekt‑Kontext aus der CLAUDE.md. Fahre mit Schritt 1 fort.
   • WENN die Nutzeranfrage generisch ist (kein konkretes Unternehmen genannt, z. B. „Erstelle eine Portfolio‑Seite“ oder „Baue ein SaaS‑Dashboard“): Fahre direkt mit Schritt 1 fort. Recherche ist für reale Unternehmen gedacht, nicht für generische Projekte.

Kontext‑Isolation (KRITISCH – vor dem Generieren lesen)

Beim Erzeugen einer DESIGN.md muss zwischen zwei Kontexten unterschieden werden:

1. Host‑Projekt – das Codebase, in dem du arbeitest (Design Guard). Die CLAUDE.md beschreibt DIESES Projekt. Sein Geschäftsmodell, seine Funktionen, CLI‑Befehle, Testanzahlen und technische Architektur beziehen sich auf Design Guard, NICHT auf das Zielunternehmen des Nutzers.

2. Zielunternehmen – das Unternehmen, für das der Nutzer eine DESIGN.md haben möchte. Dies stammt aus:

   • Dem Marken‑Briefing, das der Nutzer bereitstellt (Schritt 1)
   • Recherchedaten in .dg-research/latest.json (falls von /dg-discover verfügbar – dies ist deine PRIMÄRE Quelle)
   • WebSearch/WebFetch‑Ergebnissen über das Zielunternehmen

Regeln:

• WENN das Zielunternehmen VERSCHIEDEN von Design Guard ist:

  • Verwende KEINE Business‑Beschreibungen, Feature‑Listen, Statistiken oder technischen Details aus der CLAUDE.md
  • Verweise NICHT auf CLI‑Befehle, Testanzahlen, TypeScript, Node.js, MCP oder Stitch als Funktionen des Zielunternehmens
  • Beschreibe das Ziel NICHT als „Open Source“, „Design Intelligence“ oder mit einem anderen Begriff aus der Projektübersicht der CLAUDE.md
  • Jede Geschäftsinformation in der DESIGN.md muss aus dem Nutzer‑Briefing oder den Recherchedaten stammen
  • Falls bereits eine DESIGN.md im Projekt‑Root existiert, übernimm NICHT deren Farben, Schriftarten oder Business‑Kontext in die neue – generiere alles frisch aus dem Briefing und der Recherche

• WENN das Zielunternehmen Design Guard selbst ist:

  • Die CLAUDE.md ist eine gültige Quelle für den Business‑Kontext – verwende sie zusammen mit dem Nutzer‑Briefing

• BEFOLGE unabhängig vom Zielunternehmen IMMER die 8‑Sektionen‑Spezifikation und die Validierungsregeln aus der CLAUDE.md. Die FORMAT‑Regeln gelten immer; der BUSINESS‑Kontext wird isoliert.

1. Falls der Nutzer ein Marken‑Briefing als Argument übergeben hat, verwende es. Andernfalls frage nach:

   • Firmen‑/Produktname
   • Branche oder Domäne
   • Zielgruppe
   • Ästhetische Richtung (z. B. „premium corporate“, „verspieltes Startup“, „minimalistisches SaaS“)

2. Erstelle eine DESIGN.md mit genau diesen 8 Sektionen:

   1. Visuelles Thema & Atmosphäre – 2–3 atmosphärische Sätze, die das Gesamtgefühl beschreiben. Verwende konkrete Adjektive und Referenzen, keine allgemeinen Begriffe.
   2. Farbpalette & Rollen – Markdown‑Tabelle mit Spalten: Rolle, Name, Hex, Verwendung. Mindestens 5 Rollen (Primär, Sekundär, Oberfläche, Auf‑Oberfläche, Fehler). Alle Farben als Hex‑Werte, niemals Beschreibungen wie „vertrauenswürdiges Blau“. Gib jeder Farbe einen beschreibenden Namen (z. B. „Tiefseeblau“, nicht nur „Primär“).
   3. Typografie – Schriftfamilien von Google Fonts (vermeide Inter, Poppins als Primärschrift – sie signalisieren KI‑generiertes Design). Größen in rem/px, Gewichte als Zahlen (400/600/700), Zeilenhöhen. Enthalte Überschrift, Fließtext und Mono. Verwende eine Serifen‑/serifenlose Paarung für Kontrast.
   4. Abstände & Layout – Basiseinheit (z. B. 4px), Skala, maximale Inhaltsbreite, Rastersystem, Breakpoints.
   5. Komponenten‑Muster – Mindestens 3 Komponenten (Buttons, Karten, Eingabefelder usw.) mit Struktur und Stilregeln. Variiere border‑radius und Schattenstile.
   6. Ikonografie – Stil (Outline/Solid/Duotone), Standardgröße, Quellbibliothek.
   7. Bildrichtlinien – Fotostil, Illustrationsstil, Seitenverhältnisse. Sei konkret, welche Botschaft die Bilder vermitteln sollen.
   8. Do’s und Don’ts – Mindestens 3 von jeder Kategorie. MÜSSEN diese Anti‑Slop‑Standards enthalten:

   Do

   • Verwende asymmetrische oder nicht‑standardmäßige Layouts für mindestens einen Feature‑Bereich
   • Variiere Kartengrößen und Abstände, um einen visuellen Rhythmus zu erzeugen
   • Verwende ausschließlich die angegebene Farbpalette (keine KI‑gewählten Farben)
   • Achte auf hohen Kontrast (mindestens 4,5:1) für allen Text
   • Variiere die Abschnittshintergründe (wechsle zwischen hellen/dunklen Oberflächen)

   Don’t

   • Verwende Inter, Poppins oder system‑serifenlose Schrift als Primärschrift
   • Verwende irgendwo lila‑blaue Verläufe
   • Verwende bei allen Elementen einen einheitlichen border‑radius (>12px)
   • Verwende ein standardmäßiges dreispaltiges Icon‑Raster als zweiten Seitenabschnitt
   • Zentriere Fließtext, der länger als 2 Zeilen ist
   • Verwende generische Stock‑Foto‑Illustrationen (3D‑Blobs, abstrakte Formen)

3. Validierungsregeln:

   • Alle Farben müssen Hex‑Werte sein (#RRGGBB)
   • Schriftgrößen nur in rem oder px
   • Mindestens 5 Farbrollen, 3 Komponenten‑Muster, 3 Do’s und 3 Don’ts
   • Gesamtlänge unter ~3000 Tokens (Stitch liest sie bei jeder Generierung als Kontext)

4. Falls DESIGN.md bereits existiert, frage vor dem Überschreiben.

5. Schreibe die Datei als DESIGN.md im Projekt‑Root.

6. Überprüfe nach dem Schreiben, ob ein Stitch‑Designsystem existiert, mit mcp__stitch__list_design_systems. Falls der Nutzer ein Stitch‑Projekt hat:

   • Biete an, ein Designsystem mit mcp__stitch__create_design_system zu erstellen
   • Oder ein bestehendes mit mcp__stitch__update_design_system zu aktualisieren
   • Wende es mit mcp__stitch__apply_design_system auf das Projekt an, damit alle zukünftigen Generierungen es respektieren

7. Nächster Schritt: Schlage vor, /dg-generate auszuführen, um den ersten Bildschirm mit dem neuen Designsystem zu erstellen.

Referenz: Siehe docs/design-md-guide.md für die vollständige Spezifikation.