HTML-Mockup-Skizzierer

Skizze

Verwenden Sie diese Fähigkeit, wenn der Benutzer eine Designrichtung sehen möchte, bevor er sich festlegt – eine UI/UX-Idee als Einweg-HTML-Mockups erkunden. Der Zweck ist, 2-3 interaktive Varianten zu generieren, damit der Benutzer visuelle Richtungen nebeneinander vergleichen kann, nicht um lieferbaren Code zu produzieren.

Laden Sie diese Fähigkeit, wenn der Benutzer Dinge sagt wie „skizziere diesen Bildschirm“, „zeig mir, wie X aussehen könnte“, „vergleiche Layout A mit B“, „gib mir 2-3 Varianten dieser UI“, „lass mich ein paar Varianten sehen“, „mockup dies, bevor ich baue“.

Wann diese Fähigkeit NICHT verwendet werden sollte

• Benutzer möchte eine Produktionskomponente — verwenden Sie claude-design oder bauen Sie es ordnungsgemäß
• Benutzer möchte ein ausgefeiltes Einweg-HTML-Artefakt (Landing Page, Präsentation) — claude-design
• Benutzer möchte ein Diagramm — excalidraw, architecture-diagram
• Das Design ist bereits festgelegt — einfach bauen

Wenn der Benutzer das vollständige GSD-System installiert hat

Wenn gsd-sketch als eine Schwester-Fähigkeit erscheint (installiert über npx get-shit-done-cc --hermes), bevorzugen Sie gsd-sketch für den vollständigen Workflow: persistentes .planning/sketches/ mit MANIFEST, Frontier-Modus-Analyse, Konsistenzprüfungen über vergangene Skizzen hinweg und Integration mit dem Rest von GSD. Diese Fähigkeit ist die leichtgewichtige eigenständige Version — einmaliges Skizzieren ohne die Zustandsmaschinerie.

Kernmethode

intake  →  variants  →  head-to-head  →  pick winner (or iterate)

1. Aufnahme (überspringen, wenn der Benutzer bereits genug gegeben hat)

Bevor Sie Varianten generieren, holen Sie drei Dinge ein — eine Frage nach der anderen, nicht alle auf einmal:

1. Gefühl. „Wie soll sich das anfühlen? Adjektive, Emotionen, eine Stimmung.“ — „ruhig, editorisch, wie Linear“ sagt mehr als „minimal“.
2. Referenzen. „Welche Apps, Websites oder Produkte fangen das Gefühl ein, das du dir vorstellst?“ — echte Referenzen schlagen abstrakte Beschreibungen.
3. Kernaktion. „Was ist die wichtigste Sache, die ein Benutzer auf diesem Bildschirm tut?“ — die Varianten sollten dies alle gut bedienen; wenn nicht, sind sie nur Dekoration.

Reflektieren Sie jede Antwort kurz vor der nächsten Frage. Wenn der Benutzer alle drei bereits im Voraus gegeben hat, springen Sie direkt zu den Varianten.

2. Varianten (2-3, niemals 1, selten 4+)

Produzieren Sie 2-3 Varianten auf einmal. Jede Variante ist eine vollständige, eigenständige HTML-Datei. Beschreiben Sie die Varianten nicht — bauen Sie sie. Der Zweck ist der Vergleich.

Jede Variante sollte eine andere Designhaltung einnehmen, nicht unterschiedliche Pixelwerte. Drei gute Achsen für Varianten:

• Dichte: kompakt / luftig / ultradicht (wählen Sie zwei gegensätzliche Pole)
• Schwerpunkt: inhaltsorientiert / aktionsorientiert / werkzeugorientiert
• Ästhetik: editorisch / nützlich / verspielt
• Layout: einspaltig / Seitenleiste / geteilte Ansicht
• Fundierung: kartenbasiert / reiner Inhalt / Dokumentenstil

Wählen Sie eine Achse und ziehen Sie sie auseinander. Zwei Varianten, die sich nur in der Akzentfarbe unterscheiden, sind verschwendete Mühe — der Benutzer kann sie nicht unterscheiden.

Variantenbenennung: beschreiben Sie die Haltung, nicht die Nummer.

sketches/
├── 001-calm-editorial/
│   ├── index.html
│   └── README.md
├── 001-utilitarian-dense/
│   ├── index.html
│   └── README.md
└── 001-playful-split/
    ├── index.html
    └── README.md

3. Machen Sie sie zu echtem HTML

Jede Variante ist eine einzelne in sich geschlossene HTML-Datei:

• Inline <style> — kein Build-Schritt, kein externes CSS
• Systemschriften oder eine Google-Schriftart über <link>
• Rückenwind über CDN (<script src="https://cdn.tailwindcss.com"></script>) ist in Ordnung
• Realistischer Fake-Inhalt — echte Sätze, echte Namen, nicht "Lorem ipsum"
• Interaktiv: Links anklickbar, Hover-Effekte echt, mindestens ein Zustandsübergang (öffnen/schließen, filtern, umschalten). Ein eingefrorenes statisches Bild ist ein schlechterer Spike als ein schlampiges animiertes.

Öffnen Sie es in einem Browser. Wenn es kaputt aussieht, reparieren Sie es, bevor Sie es dem Benutzer zeigen.

Überprüfen Sie die Varianten visuell — verwenden Sie die Browser-Werkzeuge von Hermes. Schreiben Sie nicht einfach HTML und hoffen, dass es gerendert wird; laden Sie jede Variante und sehen Sie sie sich an:

browser_navigate(url="file:///absolute/path/to/sketches/001-calm-editorial/index.html")
browser_vision(question="Does this layout look clean and readable? Any visible bugs (overlapping text, unstyled elements, broken images)?")

browser_vision gibt eine KI-Beschreibung dessen zurück, was tatsächlich auf der Seite ist, plus einen Screenshot-Pfad — fängt Layoutfehler ab, die eine reine Quelltextinspektion übersieht (z.B. ein Schriftartenimport, der stillschweigend fehlschlug, ein Flex-Container, der kollabiert ist). Reparieren und neu navigieren, bis jede Variante gut aussieht.

Standard-CSS-Reset + Systemschriftarten-Stapel für schnelle Starts:

<style>
  * { box-sizing: border-box; margin: 0; padding: 0; }
  body {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
                 "Helvetica Neue", Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
    color: #1a1a1a;
    background: #fafafa;
    line-height: 1.5;
  }
</style>

4. Varianten-README

Jede README.md der Variante beantwortet:

## Variant: {stance name}

### Design stance
One sentence on the principle driving this variant.

### Key choices
- Layout: ...
- Typography: ...
- Color: ...
- Interaction: ...

### Trade-offs
- Strong at: ...
- Weak at: ...

### Best for
- The kind of user or use case this variant actually serves

5. Kopf-an-Kopf

Nachdem alle Varianten gebaut sind, präsentieren Sie sie als Vergleich. Nicht nur auflisten — meinungsstark sein:

## Three takes on the home screen

| Dimension | Calm editorial | Utilitarian dense | Playful split |
|-----------|----------------|-------------------|---------------|
| Density   | Low            | High              | Medium        |
| Primary action visibility | Low | High | Medium |
| Scan-ability | High | Medium | Low |
| Feel | Calm, trusted | Sharp, tool-like | Inviting, energetic |

**My take:** Utilitarian dense for power users, calm editorial for content-forward audiences. Playful split is weakest — tries to do both and commits to neither.

Lassen Sie den Benutzer einen Gewinner wählen, oder kombinieren Sie zwei zu einem Hybrid, oder fragen Sie nach einer weiteren Runde.

Theming (wenn das Projekt eine visuelle Identität hat)

Wenn der Benutzer ein bestehendes Theme hat (Farben, Schriften, Tokens), legen Sie gemeinsame Tokens in sketches/themes/tokens.css ab und importieren Sie sie mit @import in jede Variante. Halten Sie die Tokens minimal:

/* sketches/themes/tokens.css */
:root {
  --color-bg: #fafafa;
  --color-fg: #1a1a1a;
  --color-accent: #0066ff;
  --color-muted: #666;
  --radius: 8px;
  --font-display: "Inter", sans-serif;
  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}

Übertokenisieren Sie eine Wegwerf-Skizze nicht — drei Farben und eine Schriftart sind normalerweise genug.

Interaktivitätsgrad

Eine Skizze ist interaktiv genug, wenn der Benutzer:

1. Eine primäre Aktion anklicken und etwas Sichtbares passiert (Zustandsänderung, Modal, Toast, Navigations-finö)
2. Einen sinnvollen Zustandsübergang sehen (eine Liste filtern, einen Modus umschalten, ein Panel öffnen/schließen)
3. Über erkennbare Affordanzen hovern (Schaltflächen, Zeilen, Tabs)

Mehr als das ist Über-Engineering eines Wegwerfartikels. Weniger als das ist ein Screenshot.

Frontier-Modus (Auswahl, was als nächstes skizziert werden soll)

Wenn bereits Skizzen existieren und der Benutzer sagt: „Was soll ich als nächstes skizzieren?“:

• Konsistenzlücken — zwei Gewinnervarianten aus verschiedenen Skizzen haben unabhängige Entscheidungen getroffen, die noch nicht zusammengeführt wurden
• Nicht skizzierte Bildschirme — referenziert, aber nie erkundet
• Zustandsabdeckung — der glückliche Pfad ist skizziert, aber nicht leer / laden / Fehler / 1000 Elemente
• Responsive Lücken — bei einem Viewport validiert; hält es bei Mobilgeräten / Ultrabreit?
• Interaktionsmuster — statische Layouts existieren; Übergänge, Ziehen, Scrollverhalten nicht

Schlagen Sie 2-4 benannte Kandidaten vor. Lassen Sie den Benutzer wählen.

Ausgabe

• Erstellen Sie sketches/ (oder .planning/sketches/, wenn der Benutzer GSD-Konventionen verwendet) im Repo-Stamm
• Ein Unterverzeichnis pro Variante: NNN-stance-name/index.html + README.md
• Sagen Sie dem Benutzer, wie er sie öffnen kann: open sketches/001-calm-editorial/index.html auf macOS, xdg-open auf Linux, start auf Windows
• Halten Sie Varianten wegwerfbar — eine Skizze, bei der Sie das Bedürfnis verspürten, sie zu bewahren, sollte in echten Projektcode befördert werden, nicht als Asset kuratiert werden

Typische Werkzeugabfolge für eine Variante:

terminal("mkdir -p sketches/001-calm-editorial")
write_file("sketches/001-calm-editorial/index.html", "<!doctype html>...")
write_file("sketches/001-calm-editorial/README.md", "## Variant: Calm editorial\n...")
browser_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="How does this look? Any obvious layout issues?")

Wiederholen Sie dies für jede Variante und präsentieren Sie dann die Vergleichstabelle.

Zuordnung

Angepasst vom /gsd-sketch-Workflow des GSD (Erledige den Kram)-Projekts — MIT © 2025 Lex Christopherson (gsd-build/erledige-den-kram). Das vollständige GSD-System liefert einen persistenten Skizzenzustand, Theme-/Variantenmusterreferenzen und Konsistenzprüfungs-Workflows; Installation mit npx get-shit-done-cc --hermes --global.