Design-Demo (Produkt-UI-Demo)

Design-Demo (faux Produkt-UI)

Lade zuerst design-lean. Dessen Richtlinien, Gestaltungsregeln, Tokens und Komponenten-Gate gelten hier; dieses Skill fügt hinzu, was eine Produktaufnahme benötigt. Die Demo-Arbeit befindet sich in Builds Schritt 5, wenn eine Seite eine Produktvorschau benötigt, oder läuft eigenständig, wenn die Demo die gesamte Aufgabe ist.

Gates für einen Demo-Durchlauf

Gate	Bestehensbedingung	Hinterlassener Nachweis	Cap	Bei Fehler am Cap
D1 Planung	Platzierung, Fokusobjekt, Aktion, Nutzen und was weggelassen wird, werden vor dem Code festgehalten	Der Plan	—	—
D2 Bildausschnitt	Ein Standbild in der angezeigten Breite und bei 390 ist nicht leer, flach oder eingerahmt	Zwei Standbilder	2 Neuausschnitte	Übergabe mit Nennung des Bildausschnittfehlers
D3 Probe	Poster-Frame gesetzt; Kontaktabzüge in beiden Breiten zeigen keinen Fehler aus der Liste am Ende	Kontaktabzüge	3 Filmrunden	Übergabe mit Auflistung der verbleibenden Fehler
D4 Host-Gate	gate.js besteht auf den eigenen Steuerelementen der Host-Seite, einschließlich Pause	Gate-Gesamtsummen	2 Korrekturversuche pro Prüfung	Als offenes Issue melden

Einrichtung (extrahieren, nicht neu tippen; das Basisverzeichnis wird beim Laden jedes Skills angezeigt):

mkdir -p .design && for f in "<design-lean Basisverzeichnis>/SKILL.md" "<design-demo Basisverzeichnis>/SKILL.md"; do python3 - "$f" <<'PY'
import re, sys
for name, code in re.findall(r"`{3}js\n// file: (\S+)\n(.*?)`{3}", open(sys.argv[1]).read(), re.S):
    open(".design/" + name, "w").write("// file: " + name + "\n" + code); print("wrote .design/" + name)
PY
done

Miniatur-Produkt-UI: eine glaubwürdige Oberfläche, in ihrem Raum eingerahmt, als Standbild oder kurze Animation, in der eine Sache passiert. Der Betrachter erkennt den Bildschirm und sieht die Sache geschehen. Es handelt sich um gestaltete Illustrationen, nicht um Browser-Automatisierung: Das Skript zeichnet den Cursor beim Drücken und ändert die Szene. Die Gestaltungsregeln und Tokens von design-lean gelten weiterhin; dieser Abschnitt fügt hinzu, was eine Produktaufnahme benötigt, und überschreibt design-lean's Motion, wo sie abweichen.

Die eine Idee: Es liest sich wie ein echtes Produkt, vereinfacht auf das, was der Betrachter braucht, mit Absicht eingerahmt, und jede Bewegung hat eine Ursache.

Fünf Arten, wie es fehlschlägt:

• Zu viel. Echter Text in jeder Zeile, Zahlen überall, alles vollgestopft. Je mehr Details, desto generierter wirkt es.
• Drahtgitter. Zwei graue Klumpen und ein Button. Zu klein gebaut oder dessen entledigt, was es erkennbar gemacht hat.
• Eingerahmt. Ein ganzes Fenster auf eine Karte mit gleichmäßigen Rändern geschrumpft: ein Screenshot, eingefügt, keine Produktaufnahme.
• Flach. Jedes Objekt hat das gleiche Gewicht in der gleichen umrandeten Karte. Das Auge hat keinen Ruhepunkt.
• Langweilig. Ein graues Fenster mit einem Cursor, egal was das Briefing sagte. Der Look und die Energie des Briefings (ein Bauplan, Glas über Farbe, eine Dynamic Island, ein Maskottchen) sind der Punkt; baue, wonach es fragt, nach diesen Regeln.

Die Lösung: Ein voller, strukturierter Bildschirm in ruhigen Grautönen, echte Wörter nur dort, worum es in der Geschichte geht, Platzhalterbalken für den Rest, Raum zum Atmen, ein Bildausschnitt, der das Auge dorthin lenkt, wo die Geschichte ist. Vereinfache die Wörter, nicht den Kontext. Eine leere Ecke, ein Leerraum unter einer Liste, Reihen, die sich ausdehnen, um einen Bereich zu füllen, ein auf einer Platte schwebendes Fenster: unfertig, nicht ruhig.

Wie hart du drücken musst. Baue es wie eine Startseite, an der du gemessen wirst. Betrachte dann den Rahmen so, wie es der genaueste Designer, den du kennst, tun würde, derjenige, der die eine falsche Sache screenshottet und mit "Was ist das?" zurückschickt: ein Punkt, der von seinem Avatar abweicht, eine Einheit in einer eigenen Zeile, Kopie, die eine Karte berührt. Wenn du dir diesen Screenshot vorstellen kannst, hast du die nächste Korrektur gefunden.

Das Stage-Show-Kit

Wenn es verfügbar ist, verwende es: React-Komponenten (Stage, Window, Phone, Row, Bar, Text, Roll, Count, Collapse, Fly, Connector und mehr, mit einer Act-Script-API), etwa 70 Goldbeispiele und Produktstudien, und scripts/film.mjs, das einen Kontaktabzug filmt und Bildausschnitts- und Bewegungsfehler kennzeichnet. Suche nach einem stageshow-Skill-Ordner oder einem kit/ mit stageshow.css im Projekt. Andernfalls, mit Netzwerkzugriff, installiere es (npx skills add benjitaylor/skills --skill stageshow) oder klone https://github.com/benjitaylor/skills und arbeite von stageshow/. Dann sind dessen SKILL.md, references/ und das nächste Goldbeispiel die detaillierten Regeln; dieser Abschnitt ist die Zusammenfassung. Die Installation führt die eigenen Paketskripte dieses Repos aus, was eine Sandbox blockieren kann. Ohne das Kit baue in einfachem React oder HTML und CSS nach den folgenden Regeln und filme mit dem Skript unter Filmen ohne das Kit.

Ablauf

Der Großteil der Qualität wird vor jeglichem Code entschieden. Schreibe zuerst den Plan: wo es sitzt, das Fokusobjekt, die Aktion, der Nutzen, was weggelassen werden kann.

1. Medium und Platz. Standbild oder Animation (Schleife, einmal im Blickfeld oder bei Hover). Die Seite, ihr Hintergrund, ihre Breite. Gestalte in der Größe, in der es gesehen wird, und zeige es im Maßstab 1:1: etwa 720 × 340 für einen Helden neben Text, 900 bis 1100 breit für einen vollbreiten Helden, 400 × 300 für eine Karte. Niemals unter etwa 320 breit für eine Demo; eine Bento-Kachel oder Satellitenkarte kann kleiner sein. Alles, was in einer Telefonspalte sitzen kann, erhält ein kompaktes Design bei 358 Breite: eine Neugestaltung (engerer Beschnitt, Satellit fallengelassen oder gestapelt), keine Quetschung.
2. Look. Mit dem Produktcode oder der Website zur Hand, nimm seine echten Tokens, Icons, Chrome und Wörter. Ohne solche, führe design-lean's Direction dafür aus. Wähle eine Genauigkeit: minimal (alles Balken), Standard (Wörter, wo sie Bedeutung tragen, Balken anderswo, der Standard), realistisch (echter Inhalt überall; für Heldengröße, ein benanntes echtes Produkt oder ein Standbild, dessen Gegenstand eine Liste oder Seite ist). Ein Briefing mit einem Stil (Kawaii, Papier, eine Plakatfarbe) erhält diesen Stil vollständig, dennoch nach diesen Regeln gebaut.
3. Die Geschichte. Wähle ihre Form aus dem, wofür das Produkt geschätzt wird: wie es sich anfühlt zu verwenden (ein Cursor tut eine befriedigende Sache und das Ergebnis erscheint unter seiner Hand), ein Ablauf (ein paar Bildschirme, erzählt als ein zusammenhängendes Objekt, Nutzen auf dem letzten), oder was das System tut (die Konsequenz landet woanders, die Verbindung sichtbar, normalerweise kein Cursor). Drei bis fünf Beats und ein Nutzen, 10 bis 16 Sekunden. Zwischen einer reicheren Geschichte und einem ruhigeren Rahmen, wähle den Rahmen.
4. Starte von einem Gold, dann rahme es ein. Mit dem Kit, filme das nächste Goldbeispiel und kopiere seinen Ordner als Start; behalte seine Bühnengröße, Beschnitt, Zeilen- und Typgrößen, Abstände und Beats, ersetze dann seinen Look und Inhalt mit dem Produkt des Briefings. Eine Kopie, die nur den Namen ändert, ist nicht fertig. Ohne das Kit, wähle ein Layout aus der Tabelle unten und halte dich auf die gleiche Weise daran. Rahme vor jeder Bewegung ein: filme ein Standbild in beiden Breiten; wenn es leerer, flacher oder eingerahmter ist als es sein sollte, korrigiere zuerst den Rahmen.
5. Der Bildschirm. Zähle die echten Zeichenfolgen, normalerweise 3 bis 7: ein Budget für Wörter, nicht für Elemente. Passe den Text jedes Steuerelements an, bevor es sich bewegt. Miss, was der Cursor berührt, aus dem DOM; niemals Positionen fest codieren.
6. Choreografieren. Behalte, was gemountet erscheint, und schalte es um, damit Ausgänge animieren. Anime die Beziehung, nicht nur das Objekt: Eine neue Zeile trägt die Zeilen darunter; eine sich verändernde Oberfläche dehnt niemals ihren Text. Beats überlappen, Gruppen staffeln sich, der Nutzen hält, die Schleife endet dort, wo sie begann, oder setzt mit einer sichtbaren Ursache zurück.
7. Probe. Setze zuerst den Poster-Frame: den Beat, der die Geschichte für sich erzählt, niemals einen, der mitten in einer Änderung erwischt wurde, das Ergebnis bleibt auf dem Bildschirm. Filme dann die Schleife, nicht nur ein Standbild: einen Kontaktabzug in der angezeigten Breite und bei 390, und gehe Bild für Bild durch jeden Druck, jedes Menü, jede Morphing und die Schleifennaht. Ein Standbild kann keinen Pop zeigen. Korrigiere zuerst den größten sichtbaren Fehler (Bildausschnitt, dann Hierarchie, dann Bewegung, dann Feinschliff) und filme neu. Cap: drei Filmrunden; danach Übergabe mit Auflistung der verbleibenden Fehler. Frage: Worauf fällt das Auge zuerst, und ist es das Ergebnis? Führt ein Fenster, eine Kachel oder ein Gerät klar? Jedes Nein ist der größte Fehler. Ein bestandenes Skript ist notwendig, nicht ausreichend. Übergabe mit einer kurzen Notiz: das Gold oder Layout, von dem du gestartet bist, was du geändert hast, was du nicht überprüft hast.

Bildausschnitt

• Ein Heldenobjekt, höchstens ein oder zwei Satelliten (eine Quittung, ein Telefon, eine Detailkarte), die den Punkt tragen. Behalte, was das Produkt identifiziert: einen Titel, das echte Chrome, die Zeilen, die der Aktion einen Grund geben. Logo und Navigation sind optional.
• Beschneide nur Füllmaterial. Der Nutzen, die Aktion, was der Cursor berührt, und jedes echte Wort bleiben ganz. Eine Platzhalteraktion, die der Beschnitt durchschneiden würde, wird entfernt, nicht angeschnitten. Ein Button, Chip oder Schatten, der von der Bühnenecke angeschnitten wird, ist der übliche Fehler.
• Beschneide 10 bis 40% des Helden von der Bühne. Das Fenster oder Telefon füllt mindestens zwei Drittel der Bühnenbreite und läuft über eine Kante. Die Bühne maskiert alles (overflow: hidden).
• Die Seite ist der Hintergrund. Auf einer weißen oder dunklen Seite keine Platte hinter dem Fenster und kein ganzes Fenster mit Luft auf vier Seiten; das schwebt. Nicht eingerahmt (ganz, zentriert, ein gleichmäßiger Rand mindestens so tief wie der Schatten) nur, wenn der Entwickler es verlangt.
• Eine Rinne, gemessen im endgültigen Beschnitt: Jeder Kantenabstand stimmt mit ihr überein, eine ganze Rinne oder weit darüber. Sie um weniger als 24 Pixel zu überschreiten oder ein paar Pixel zu kurz zu stoppen, ist ein Fehler.
• Satelliten überlappen die Heldenkante, etwa zur Hälfte außerhalb, über Chrome (einer Seitenleiste, Kopfzeile oder Rand), niemals über Inhalt. Zwei Satelliten sind zwei Arten und Größen (eine Karte und eine Benachrichtigung in Originalgröße), niemals zwei gleiche Karten übereinander. Verankerte UI (Popover, Menü, Toast) ist kein Satellit: Sie sitzt dort, wo das Produkt sie hinsetzt.
• Ein Fenster behält die Form seines Geräts: ganz bei 1,25:1 oder breiter; blutend, was gezeigt wird, ist mindestens quadratisch. Korrigiere durch Beschnitt, niemals durch Quetschen.
• Was die Geschichte öffnet, bleibt im Rahmen, eine Rinne von jeder Kante in jedem Bild; platziere den Auslöser so, dass das Overlay Platz hat. Keine toten Ecken im Ruhezustand oder irgendwo in der Schleife.
• Starte flach und frontal. Tiefe durch Schatten, Z-Reihenfolge, Skalierung und Deckkraft; Neigung nur, wo sie sich lohnt (ein loser Papierstapel), Perspektive nur, wenn gefragt.
• Telefone: Ein Satellitentelefon beginnt bei 40% der sichtbaren Fensterbreite und mindestens 220px; lass es eher über den unteren Rand laufen, als es zu schrumpfen. Benachrichtigungen bleiben im echten iOS-Verhältnis und werden niemals abgeschnitten. Ein Telefon, das oben beschnitten ist, verliert gleichzeitig seine Statusleiste und Navigationsleiste. Zeichne niemals eine Statusleiste oder Home-Indikator von Hand; nimm den Rahmen aus dem Kit oder einer echten Referenz.

Layout	Held	Verwendung für
Fixiert, unterer Rand blutend	8–12% links, rechts und oben eingesetzt; 15–35% über den unteren Rand	Feature-Karten und Bento-Kacheln
Eckenblutung	10% oben und links eingesetzt; 15–35% über rechten und unteren Rand; Satellit am linken oder unteren Rand	Helden neben Text
Bühne mit Rinnen	8–20% auf jeder Seite auf einer farbigen Bühne eingesetzt, über den unteren Rand	Markenmomente
Satellitenfokus	Held stark beschnitten; ein großer Satellit (30–40% der Heldenbreite) trägt die Geschichte	Eine kleine Sache: eine Benachrichtigung, eine Quittung, ein Diff
Breiter Held	Ein 900–1100px Fenster bei 1:1, über den unteren Rand; realistische Genauigkeit	Homepage-Helden in voller Breite
Gerätepaar	Desktop 75–80% breit, über den unteren Rand; Telefon überlappt die rechte Kante, ein Drittel außerhalb	Geräteübergreifende Geschichten
Viele von einer	Ein Raster einer Sache über jede Kante; eine Kachel im Fokus durch Tiefe, die einzige mit Wörtern	Maßstab gezeigt als Wiederholung
Überblendungsbeschnitt	Fenster oben und an den Seiten eingesetzt, über seinem letzten Drittel maskiert, nur Füllmaterial unter der Überblendung	Wenn eine Kante das Fenster an einer willkürlichen Linie schneiden würde
Nahaufnahme	Das ganze Fenster bei 1,3–1,6x, Chrome und alles, die betreffende Zeile ganz	Eine Karte über ein Steuerelement
Panel über Produkt	Ein Einstellungspanel über dem Rand des Produkts, ein neutraler Führer zu dem, was es geändert hat	Eine Einstellung und ihre Wirkung
Gegenüberliegende Ecken	Kopie unten links; das Produkt von der oberen rechten Ecke hängend	Bento-Kacheln mit einer Zeile Kopie

Ein Bento-Raster ist ein Satz: eine Heldenkachel, dann ein Fenster, eine Statistik, ein Objekt und ein Diagramm, jede eine andere Art; plane das Raster vor jeder Kachel.

Das Standbild

• Zurückhaltung. Echte Zeichenfolgen auf dem Titel, der Sache, an der gehandelt wird, was getippt wird, dem Ergebnis; der Rest sind Balken. Balken sind Füllmaterial an den Rändern; Balken, wo das Auge landet, lesen sich unfertig. Wo die Geschichte eine Liste berührt, zwei oder drei echte Zeilen. In einer kleinen Oberfläche ist eine Zeile eine Linie: Avatar, Name, Wert. Platzhalterbreiten variieren von Zeile zu Zeile (60, 45, 70, 52). Label und Wert passen zueinander: beide Wörter oder beide Balken. Eine Zahl darf groß sein. Sage das Signal der Funktion einmal, nicht in Kopfzeile, Satellit und jeder Zeile.
• Behalte den signifikanten Inhalt der Domäne: Albumcover, Thumbnails, Avatare (jeder benannte Avatar seine eigene Farbe). Ausgetauscht, ist es eine generische Liste.
• Kein Masthead für einen fiktiven Namen und kein Produktname auf dem Bildschirm, es sei denn, das Briefing stützt sich darauf und das echte Produkt würde es dort zeigen. Der Titel einer Fake-App ist ein div, niemals h1 bis h6: Die Demo lebt innerhalb der Seitenstruktur eines anderen.
• Typ: Echte 11 bis 15px UI-Größen, skaliert durch die Bühne, niemals 7px. Kleine Textzeilenhöhe mindestens 1,3. Monospace nur für Code, Bezeichner und ausgerichtete Zahlen.
• Abstände: Wörter halten einen 12px Inset von jeder Fenster-, Karten-, Panel- oder Hover-Zeilenkante (niemals unter 8); Balken dürfen bluten, Wörter nicht. Zeilenabstand 12px, 8 für eine dichte Liste. Ein Titel über seinem Untertitel sitzt 4 bis 6px auseinander. Ein Button hält 8px oder mehr vom Feld darüber entfernt. Keine Fast-Tangenten: Kanten 1 bis 3px auseinander lesen sich als Unfälle; richte genau aus oder trenne sie um mindestens 8.
• Optische Zentrierung: Zentriere ein Label auf seinen Buchstaben (text-box: trim-both cap alphabetic) in Pillen, Buttons und Avataren. Ein zentrierter Betrag zentriert seine Ziffern, mit dem Währungssymbol außerhalb bei right: 100%.
• Icons stammen aus einem Set, niemals von deiner Hand: zuerst das eigene Paket des Produkts, sonst ein Set, das mit Bedacht ausgewählt wurde (SF-Stil für Apple Chrome, Material Symbols für Android, sonst Phosphor, Iconoir, Radix, Tabler, Heroicons oder Lucide), eine Größe (14–16px) und Strichstärke pro Szene, gefüllt bei 14px und darunter. Emojis sind Inhalt, niemals Icons. Logos anderer Produkte sind ihre echten Marken in Originalproportionen, niemals ein Nachbau.
• KI-Funktionen: kein Glitzer, Zauberstab oder Stern und kein Lila als KI-Farbe; zeige, was die KI tut (die gesendete Frage, das Denken, die Antwort, die mit ihrer Höhe eintröpfelt, Quellen zum Schluss). Das eigene Icon des Produkts ist in Ordnung, auch wenn es ein Glitzer ist.
• Keine erfundenen Geräte oder Browser-Chrome; wenn kein Kit vorhanden ist, sind schwebende Fenster mit abgerundeten Ecken (10–14px), einer Titelleiste mit drei Punkten (12–14px Kreis) und einer Browser-Symbolleiste akzeptabel.

Bewegung

Überschreibt die Motion-Regeln von design-lean.

• Eine Sache passiert. Ein Cursor klickt einmal und etwas erscheint. Ein Cursor schwebt, zwei Optionen erscheinen, er wählt eine aus, die UI ändert sich. Ein Systemereignis sendet eine Benachrichtigung, sie erscheint, der Benutzer tippt darauf, die App öffnet sich. Wenn die Kamera läuft, ist die Aktion vorbei, das Ergebnis bleibt sichtbar. Keine Kameraschwenks. Keine Zooms.
• Ursache und Wirkung. Die Bewegung wird durch die Interaktion des Benutzers ausgelöst (Cursorbewegung, Tippen, Scrollen) oder durch ein Systemereignis (eine eingegangene Benachrichtigung, ein geladener Bildschirm). Das Ergebnis ist das, was sich als Folge ändert. Keine zufälligen Animationen.
• Die Bewegung dauert 0,3 bis 1,5 Sekunden. Länger als 2 Sekunden ist zu langsam. Kürzer als 0,2 Sekunden ist zu schnell. Ein Popover erscheint in 0,15 Sekunden, eine Bildschirmtransformation in 0,4 Sekunden, ein Ergebnis nach einem Klick in 0,8 Sekunden, eine Nachricht, die eintröpfelt, mit 0,3 Sekunden pro Teil.
• Ergebnisse bleiben bestehen. Die Schleife endet mit dem Ergebnis auf dem Bildschirm, das die Geschichte erzählt. Die Schleife kehrt innerhalb von 0,5 bis 1 Sekunde zum Anfang zurück, mit einer sichtbaren Ursache (der Cursor bewegt sich zurück, die Benachrichtigung verschwindet, die App schließt sich).
• Gruppen staffeln sich. Wenn mehrere Dinge passieren (z. B. Zeilen erscheinen), erscheint jede um 0,1 bis 0,2 Sekunden versetzt, nicht alle gleichzeitig. Die Staffelung erfolgt in der Reihenfolge der Wichtigkeit: zuerst das Ergebnis, dann der Kontext, dann die Details.
• Nur bewegliche Dinge ändern die Deckkraft. Alles andere behält 100% Deckkraft. Ein Fenster erscheint nicht durch Einblenden, es gleitet herein. Ein Cursor erscheint durch Einblenden, er bewegt sich dann.
• Keine Bewegung ohne Grund. Ein Cursor, der sich um seiner selbst willen bewegt, ist unnötig. Ein Fenster, das sich um seiner selbst willen dreht, ist unnötig. Die Bewegung dient der Geschichte, nicht der Show.

Filmen ohne das Kit

Wenn das Stage-Show-Kit nicht verfügbar ist, filme mit diesem Skript:

// film.js – Ein Skript zum Filmen einer Demo ohne das Stage-Show-Kit
// Führe es im Browser aus, während die Demo läuft.

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();

  // Öffne die Demo-Seite
  await page.goto('http://localhost:3000'); // Passe die URL an

  // Warte, bis die Demo geladen ist
  await page.waitForTimeout(1000);

  // Setze die Größe des Viewports auf die gewünschte Breite
  await page.setViewportSize({ width: 720, height: 500 });

  // Warte, bis die Animation abgeschlossen ist
  await page.waitForTimeout(2000);

  // Mache einen Screenshot des Standbilds
  await page.screenshot({ path: 'still-720.png' });

  // Ändere die Größe auf 390
  await page.setViewportSize({ width: 390, height: 800 });
  await page.waitForTimeout(2000);
  await page.screenshot({ path: 'still-390.png' });

  // Film die Schleife als Sequenz von Screenshots
  for (let i = 0; i < 60; i++) {
    await page.screenshot({ path: `frame-${i}.png` });
    await page.waitForTimeout(100);
  }

  await browser.close();
})();

Das Host-Gate

Das Host-Gate stellt sicher, dass die Demo auf der Zielseite funktioniert:

// gate.js – Überprüft, ob die Demo auf der Host-Seite funktioniert

function checkHostGate() {
  const results = [];

  // Prüfe, ob die Demo im Viewport sichtbar ist
  const demo = document.querySelector('.design-demo');
  if (!demo) {
    results.push({ check: 'Demo-Vorhandensein', pass: false, message: 'Demo-Element nicht gefunden' });
  } else {
    const rect = demo.getBoundingClientRect();
    if (rect.width === 0 || rect.height === 0) {
      results.push({ check: 'Demo-Größe', pass: false, message: 'Demo hat keine Größe' });
    } else {
      results.push({ check: 'Demo-Größe', pass: true, message: `Demo ist ${rect.width}x${rect.height}` });
    }
  }

  // Prüfe, ob das Gate-Skript selbst vorhanden ist (Pause-Funktion usw.)
  if (typeof window.__designDemoGate !== 'undefined') {
    results.push({ check: 'Gate-Skript', pass: true, message: 'Gate-Skript vorhanden' });
  } else {
    results.push({ check: 'Gate-Skript', pass: false, message: 'Gate-Skript nicht gefunden' });
  }

  return results;
}

Beispiel: Helden-Demo

Hier ist ein minimales Beispiel einer Helden-Demo:

<!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Helden-Demo</title>
  <style>
    .hero {
      width: 720px;
      height: 340px;
      background: #f5f5f5;
      position: relative;
      overflow: hidden;
    }
    .window {
      position: absolute;
      top: 15%;
      left: 10%;
      width: 80%;
      height: 70%;
      background: white;
      border-radius: 12px;
      box-shadow: 0 4px 20px rgba(0,0,0,0.1);
    }
    /* Weitere Stile... */
  </style>
</head>
<body>
  <div class="hero">
    <div class="window">
      <!-- Inhalt, Platzhalter, Symbole -->
    </div>
  </div>
</body>
</html>

Abschluss

Dieses Skill erstellt Demos, die wie echte Produkte aussehen, nach strengen Regeln zur Qualitätssicherung. Folge den Gates, verwende das Kit, wenn möglich, und halte dich an die Gestaltungs- und Bewegungsregeln. Das Ziel ist eine glaubwürdige, fokussierte und aussagekräftige Produkt-UI-Demo.