yg2224/app-shell-ui

App Shell UI

Du implementierst App Shell UI: eine wiederverwendbare Frontend-Design-Skill mit zwei Modi. Wähle die Oberfläche, bevor du Pixel setzt. Verwandle nicht jede Anfrage in eine Desktop-Shell und nicht jede App in eine generische Marketingseite.

Wähle zuerst die Oberfläche

Modus	Verwendung für	Standardstruktur	Nicht verwenden für
App-Modus	Eingeloggte Tools, Einstellungen, Konsolen, Chat, Mail, Arbeitsbereiche, operative Abläufe	Permanente linke Navigation + Aufgabenleinwand	Öffentliches Marketing, Lesen, E-Commerce oder Portfolio-Oberflächen
Website-Modus	Marketing-Websites, Produkteinführungen, Portfolios, redaktionelle Seiten, Kataloge, Doku, öffentliche Inhalte	Eine seiten-spezifische Makrostruktur, ausgewählt aus der User Journey	Eine generische Hero + drei Karten + CTA-Vorlage oder eine fake App Shell

Wenn die Anfrage beide Oberflächen umfasst, gestalte sie getrennt: Website-Modus für Akquise oder öffentliche Informationen, App-Modus für das eingeloggte Produkt. Teile Marken-Tokens wo angemessen, erzwinge aber nicht dasselbe Layout oder dieselbe Dichte für beide.

Pre-Flight (beide Modi)

Bevor du visuelle Entscheidungen in einem bestehenden Projekt triffst, überprüfe die Route und ihre nächste visuelle Quelle der Wahrheit: aktuelle Tokens, Typografie, Theme-Mechanismus, Assets, Framework, Komponenten-Primitive und installierte Icon-/Motion-Bibliotheken. Bewahre ein etabliertes System, es sei denn, der Benutzer bittet um ein Redesign. Überprüfe package.json, bevor du eine Abhängigkeit hinzufügst; gehe nicht davon aus, dass eine Bibliothek existiert, oder mische zwei unabhängige Designsysteme in einer Oberfläche.

Wenn das Briefing wirklich zwischen zwei materiell unterschiedlichen Ergebnissen mehrdeutig ist, stelle genau eine kurze Frage. Ansonsten gib die Schlussfolgerung in einem Satz an und fahre fort. Verwandle eine kleine Implementierungsanfrage nicht in ein Anforderungsinterview.

App-Modus Workflow

1. Wähle ein Layout-Template (erforderlich vor Pixeln):
   • Einstellungstyp — schmale linke Navigation + Formular / Toggle-Liste
   • Konsolentyp — linke Navigation + Kartenraster / Statusliste
   • Arbeitsbereichstyp — Sitzungsbaum + zentrierter leerer Zustand + Composer-Karte
   • IM / Dreispaltiger Typ — Icon-Leiste + Liste + Detail
2. Setze das Viewport-Budget — definiere den Ziel-Desktop-Viewport (mindestens 1280×800) und die eine primäre Aufgabe für die Route, bevor du Inhalte hinzufügst. Siehe references/layouts.md → Viewport budget / 单页容量.
3. Lege duale Theme-Tokens fest — verwende references/tokens.md (hell + dunkel sind standardmäßig beide erforderlich).
4. Komponiere aus Rezepten — verwende references/components.md (Navigationselement, Karte, Listenzeile, Toggle, Pille, leerer Zustand/Composer). Rezepte sind themaunabhängig; nur Variablen ändern sich.
5. Implementiere mit CSS-Variablen + data-theme="light"|"dark"; füge einen Theme-Umschalter hinzu; Tailwind/shadcn-Mapping optional.
6. Selbstprüfung — führe die Checkliste am Ende dieser Datei in beiden Themen und im Ziel-Viewport durch, bevor du auslieferst.

Standard-Stack, wenn frei wählbar:

Schicht	Standard
Markup	Semantisches HTML oder React
Stil	CSS-Variablen + leichtes Utility/Tailwind
Komponenten	shadcn / @coss style (New York + zinkähnliche Neutrale)
Icons	Lucide-Stil 1.5–2px Strich, nur eine Familie
Theme	Hell + Dunkel (Umschalter + optional OS prefers-color-scheme)

Bevorzuge ein einzelnes eigenständiges HTML für Demos, es sei denn, der Benutzer möchte eine Projektintegration.

App-Modus Architektur

L0  Fensterrahmen (optional Traffic-Lights / Titelleiste / obere Werkzeuge + Theme-Umschalter)
L1  Seitenleiste oder Icon-Leiste
L2  Inhaltsleinwand (weiches Grau hell / weiches Holzkohle dunkel)
L3  Oberflächen (erhöhte Karten, Panels, Listen)

Seitenleistenbreite: 220–260px (Text-Navigation) oder 48–56px (Icon-Leiste). Inhaltspadding: 20–28px. Abstand auf 4px Raster.

Standard-Seitenbudget: Der anfängliche Desktop-Zustand sollte seine primäre Aufgabe in einem Viewport erledigen, nachdem der Shell-Rahmen enthalten ist. Lasse unten etwas kleine Atemfreiheit; lasse die gesamte Seite nicht vertikal scrollen, nur um routinemäßige sekundäre Inhalte zu enthüllen. Lange Sammlungen dürfen eine begrenzte innere Scroll-Region verwenden, wenn das Produkt es wirklich benötigt. 中文偏好：每个页面尽量一屏完成，内容达到首屏容量就停止继续堆叠。

App-Modus Nicht-Verhandelbares

1. Zwei Themen: liefere helle und dunkle Token-Sets aus, es sei denn, der Benutzer möchte explizit nur eines.
2. Eine Marken-Primärfarbe für: primäre Buttons, Toggle EIN, Fortschrittsfüllung, ausgewählter Rand/Hintergrund, Links. Die dunkle Primärfarbe kann ein etwas hellerer Zwilling sein (z. B. #007AFF → #0A84FF).
3. Oberflächenleiter (beide Themen): App-Hintergrund → Seitenleisten-Hintergrund → erhöhte Oberfläche (schwacher Kontrast). Hell: weiches Grau + weiße Karten. Dunkel: weiches Holzkohle + erhöhte graue Karten — nicht reines #000 Seite + reines #fff Karten.
4. Textleiter: primär / sekundär / tertiär (Werte unterscheiden sich pro Thema).
5. Hierarchie zuerst über 1px Ränder; Schatten optional und themaspezifisch.
6. Radiusleiter: 8 / 12 / 16 / 999 (gemeinsam über Themen hinweg).
7. Kopiermuster: Titel + eine gedämpfte Untertitelzeile.
8. Bewegung: 150–200ms Farbe/Hintergrund nur; kein Bounce-Theater.
9. Theme-Umschalter: data-theme auf Root + sichtbarer Button; mit localStorage persistieren, wenn möglich.
10. Icon-Zurückhaltung (Inhalt): Standardmäßig rechte Hand Inhalte = Text + Strich-Icons + Status-Pillen. Emoji/Illustration sind nur optionale Akzente — niemals der Standard für jede Listenzeile oder Karte. Bevorzuge null Emojis in dichten Listen; höchstens ein dekoratives Zeichen in einem Banner oder leeren Zustand.
11. Gleiche Höhe nebeneinander: Jedes nebeneinanderliegende Inhalts paar (Liste + Composer, Panel + Panel, Stats-Geschwister, die ein Paar Karten in einer Zeile bilden) muss dieselbe äußere Unterkante teilen. Verwende Grid/Flex stretch + Column-Flex + flex: 1 auf Oberflächen — niemals align-items: start, das eine kurze Karte hinterlässt. Siehe references/layouts.md → Equal-height side-by-side columns.
12. Ein-Viewport-Inhaltsbudget: Auf dem Desktop darf die Standard-Route kein vertikales Scrollen auf Seitenebene erfordern. Fülle die nutzbare Leinwand mit priorisierten Inhalten, aber höre auf, bevor der erste Viewport überschritten wird. Wenn der Inhalt nicht passt, entferne, kürze, paginiere, klappe auf, tabuliere oder teile ihn auf eine andere Route; schneide niemals Steuerelemente ab oder verkleinere Text unter Lesbarkeit. Auf Mobilgeräten halte die primäre Aktion und den Status im ersten Viewport; natürliches Scrollen ist wirklich langen Inhalten vorbehalten.

App-Modus Tun / Nicht Tun

Tun	Nicht tun
Linke Navigation + rechter Inhalt	Vollflächige Hero-Art als ganze App
Weiche Leinwand + erhöhte Karten in beiden Themen	Neon-Cyber-Dunkel oder reines OLED-Schwarz als Standard
Einzelner Akzent (gepaart hell/dunkel)	Regenbogen-Navigations-Icons als mehrere Primärfarben
Strich-Icons (Lucide-Stil) in Navigation + Inhalt	Gemischte gefüllte + Strich-Icon-Sets
Text-zuerst Karten/Listen; Pille für Status	Emoji in jeder Zeile / Karte / Abschnittsüberschrift
Status als kleine Pillen / gedämpfter Text	Laute vollbreite Alert-Banner für normale Zustände
Theme-Umschalter im Rahmen	Dunkelmodus via filter: invert()
Randtrennung via Tokens	Hartcodierte #fff / #000 Rahmenfarben
Luftige Abstände	Dichte Tabellenkalkulations-Packung
≤1 Emoji-Akzent pro Hauptregion (oder keins)	Banner + Karten + Listen alle Emoji-lastig
Nebeneinanderliegende Karten gleiche Höhe (stretch)	Eine große / eine kurze (align-items: start)
Ein-Bildschirm-Route mit priorisierten Blöcken	Unbegrenztes Seiten-Scrollen für Routine-Inhalte
Begrenztes inneres Scrollen für lange Sammlungen	Ausblenden oder Abschneiden von Inhalten mit festen Höhen

App-Modus Seitenaufbau-Reihenfolge

1. Shell (Fenster + Seitenleiste + Hauptbereich)
2. Markenblock in der Seitenleiste
3. Navigationsgruppen + aktives Element
4. Seitenkopf (H1 + gedämpfte Untertitel + Aktionen)
5. Theme-Umschalter in Titelleiste oder Einstellungen (erforderlich für Demos)
6. Optionale Werkzeugleiste (Suche + Segmentierter Filter)
7. Inhaltsblöcke nach Priorität: Banner → Statistiken → primäres Raster/Liste → sekundäre zweispaltig. Stoppe, wenn das Viewport-Budget voll ist; verschiebe Blöcke niedrigerer Priorität auf Tabs, Aufklappmechanismen, Paginierung oder eine andere Route.
8. Für jede zweispaltige Peer-Zeile: wende gleiche-Höhe-Rezept an (stretch + Flex-Oberflächen), ohne Überlauf zu erzwingen.
9. Verkabelte Interaktion: Navigationswechsel, Auswahl, Toggles, Filter, Theme-Umschalter

App-Modus Implementierungshinweise

• Setze helle Tokens auf :root, :root[data-theme="light"] und dunkle auf :root[data-theme="dark"] (siehe references/tokens.md).
• Komponenten konsumieren nur Variablen — keine hartcodierten Marken-/Oberflächen-Hex in Komponentenregeln.
• Ausgewählte Navigation: weicher Primärfarbe-Wasch + Primärtext, Radius 8px (Wasch-Mischung unterscheidet sich pro Thema).
• Karten: --bg-surface + 1px --border + Radius 12; ausgewählt: Primärring/-rand. Führendes Zeichen = Strich-Icon in gedämpfter Platte oder kein Zeichen — standardmäßig nicht Emoji.
• Einstellungs-/Feed-Zeilen: 16–18px Strich-Icon (optional weiche Platte) + Titel + gedämpfte Beschreibung + rechts Steuerung. Vermeide Emoji-Listen-Icons.
• Leerer / neuer Zustand: zentrierter Titel + großer abgerundeter Composer; Chips + primärer CTA. Leeres Wasserzeichen darf ein schwaches Strich-Icon oder ein einzelnes dezentes Glyph sein — kein Stapel von Emojis.
• Banner: Text-zuerst; optional maximal ein kleiner Akzent-Kachel (oft keins).
• Gestrichelte Hinzufügen-Zone für "leere Sammlung + erstellen" (Pluszeichen, kein Emoji).
• Sekundäre Buttons, Segment-Tracks, Toggle AUS-Tracks müssen Theme-Tokens verwenden (--secondary-btn-bg, --seg-track, --toggle-off) — hellgraues rgba funktioniert nicht auf dunklem.
• Halte die Seiten-Shell standardmäßig fixiert (min-height: 0; overflow: hidden). Wenn eine Liste, ein Log, eine Tabelle oder ein Nachrichtenverlauf von Natur aus lang ist, setze Scrollen auf eine begrenzte untergeordnete Region mit einem klaren Höhenbudget; mache den Dokumenten-Body oder die gesamte Inhaltsleinwand nicht zum Standard-Scroll-Container.
• Validiere den Erstladezustand bei einem Desktop-Viewport von mindestens 1280×800 (und einem schmalen mobilen Viewport). Überprüfe, dass die primäre Aufgabe, Steuerelemente und Status ohne Seiten-Scrollen sichtbar sind und dass kein Text oder Steuerelement abgeschnitten wird.

Theme-API (kanonisch)

// data-theme = "light" | "dark"
// localStorage key: "app-shell-theme"
// toggle flips attribute; init reads storage then prefers-color-scheme

Minimaler CSS-Token-Block

Kopiere den Dual-Theme-Block aus references/tokens.md.

Minimales HTML-Skelett

<html data-theme="light">
…
<div class="window">
  <header class="titlebar">
    …
    <button type="button" data-theme-toggle aria-label="Helles/Dunkles Theme umschalten">…</button>
  </header>
  <div class="shell">
    <aside class="sidebar">…</aside>
    <main class="main">…</main>
  </div>
</div>

App-Modus Prompt-Saat

Hell

macOS Desktop-Dienstprogramm helles UI: 240px weichgraue Seitenleiste (Strich-Icons + Label, ausgewählt = heller Primärfarben-Wasch + 8px Radius), Hauptleinwand weichgrau mit weißen abgerundeten Karten; einzelne Primärfarbe #007AFF für Buttons, Toggles, Fortschritt, Auswahlring; drei Textgrautöne; Radius 8–16px; fast kein Schatten, 1px helle Ränder; Einstellungs/Listen-Zeilen mit kleinen Strich-Icons (nicht Emoji) + Titel/Beschreibung + rechts Toggle oder Status-Pille; Inhaltsbereich Text-zuerst, minimal oder kein Emoji; leerer Zustand = zentrierter Titel + großer abgerundeter Composer.

Dunkel

Gleiche Shell im Dunkelmodus: weiche Holzkohle-Leinwand #1C1C1E, Seitenleiste #161617, erhöhte Karten #2C2C2E, Ränder Weiß 8% Alpha, Text #F5F5F7 / #A1A1A6 / #6C6C70, Primärfarbe #0A84FF, ausgewählte Navigation = Primärfarbe 22% gemischt in Kartenoberfläche; keine reine schwarze Seite; kein Invert-Filter; Theme-Umschalter enthalten.

Tausche nur Geschäfts-Nomen aus; behalte Shell + Dual-Theme-Regeln.

Website-Modus Workflow

Der Website-Modus ist für öffentlichkeitsgerichtete Webarbeit. Er darf normales Dokument-Scrollen verwenden und sollte weder die feste Leinwand, die Seitenleiste, den künstlichen Fensterrahmen noch das Ein-Viewport-Inhaltslimit des App-Modus erben. Lese references/web-frontend.md, bevor du den Website-Modus implementierst.

1. Führe ein Design-Reading durch — gib die Seitenart, Zielgruppe, primäre Aufgabe und einen konkreten Ton an. „Sauber und modern" ist keine Richtung. Erschließe sie aus der Aufgabenstellung und der bestehenden Marke; stelle nur eine kurze Frage, wenn zwei Richtungen materiell unterschiedliche Arbeit produzieren würden.
2. Wähle den Oberflächenmodus — Überzeugen für eine Conversion-Seite oder Einführung, Lesen für Doku oder redaktionelle Inhalte, Erleben für Portfolio/Galerie/Event-Arbeit oder Katalog zum Stöbern und Kaufen. Das eingeloggte Produkt bleibt im App-Modus.
3. Wähle eine Makrostruktur vor Komponenten — wähle eine Seitenform, die zur Aufgabe passt, wie Produktvorstellung, evidenzgeführte Geschichte, redaktionelle Erzählung, Arbeitsindex, Katalog, Leseleitfaden oder Kampagnenposter. Standardmäßig nicht auf zentrierte Hero → drei gleiche Karten → CTA zurückgreifen.
4. Lege ein visuelles System fest — lege eine Palette, Typografie-Rollen, Abstands-/Radiusregeln, Bildbehandlung und ein sichtbares Unterscheidungsmerkmal fest. Wiederverwende bestehende Marken-Tokens; definiere andernfalls semantische CSS-Variablen und konsumiere sie, anstatt Farben oder Schriftarten pro Abschnitt zu improvisieren.
5. Plane Wahrheit und Medien — verwende gelieferte Fakten, echte Screenshots/Produktzustände, lizenzierte Assets oder generierte Bitmap-Visuals, die der Aufgabenstellung entsprechen. Erfinde keine Kunden, Metriken, Testimonials, Logos, Fake-Dashboards, Browser-Chrome oder Platzhalterdaten, die als echt gelesen werden. Unbekannte Behauptungen bleiben sichtbar als Platzhalter markiert oder werden weggelassen.
6. Baue die Informationsreise — verwende semantische Auszeichnung und eine Hierarchie, die die nächste Aktion offensichtlich macht. Lasse Abschnitte in ihrer Komposition variieren, wenn ihre Aufgaben unterschiedlich sind; Karten sind für wiederholte, begrenzte Elemente gedacht und nicht als Standard-Seitenabschnitts-Wrapper.
7. Implementiere vollständiges Verhalten — verwende native Steuerelemente und Links, sichtbaren Fokus, Lade-, Leer-, Fehler-, Deaktiviert- und Erfolgszustände, wenn relevant. Bewegung muss Feedback oder räumliche Veränderung erklären, transform/opacity verwenden, prefers-reduced-motion respektieren und darf sich nicht in hochfrequenten Abläufen befinden, es sei denn, sie ist effektiv sofortig.
8. Überprüfe gerenderte Ausgabe — validiere Desktop- und Mobile-Screenshots, echte Inhaltsextreme, Kontrast, Tastaturnavigation, Ladebildabmessungen, Überlauf und den ersten Viewport. Die Proposition der Hero, die primäre Aktion und der visuelle Brennpunkt müssen bei 1280x800 passen; Seiten-Scrollen darunter ist für eine Website normal.

Website-Modus Nicht-Verhandelbares

1. Verpacke keine öffentliche Website in App-Modus-Chrome, es sei denn, der Benutzer bittet explizit um eine Produktvorschau oder eine eingeloggte Anwendungsroute.
2. Gib jeder öffentlichen

…

[gekürzt zur Übersetzung]

Checkliste (beide Modi)

• Modus basierend auf User-Journey und Inhaltstyp ausgewählt
• Viewport-Budget definiert und eingehalten
• Helle + dunkle Theme-Tokens gesperrt (es sei denn, nur eines explizit)
• Komponenten konsumieren nur CSS-Variablen (keine hartcodierten Hex-Werte)
• Theme-Umschalter vorhanden und funktionsfähig
• Nebeneinanderliegende Elemente haben gleiche Höhe (keine unvollendeten Peers)
• Ein-Viewport-Inhaltsbudget eingehalten (App-Modus)
• Icon-Konsistenz: eine Familie, Strich-Icons bevorzugt, kein Emoji-Overload
• Bewegung respektiert prefers-reduced-motion (optional, aber empfohlen)
• Barrierefreiheit: semantischer HTML, sichtbarer Fokus, Tastaturnavigation