Website-Erstellung
Erstelle unverwechselbare, produktionsreife Websites, bei denen jede Seite ANDERS aussieht. Jede Wahl – Schriftart, Farbe, Bewegung, Layout – muss sich aus dem Thema ableiten. Führe den Palettengenerator (bun run shared/generate-palette.ts "Schlüsselwörter") aus, um ein einzigartiges Farbschema für jedes Projekt zu erstellen. Verwende NIEMALS dieselbe Palette für mehrere Websites.
Dieser Skill deckt alles für Webprojekte ab. Lies die Unterdateien in diesem Verzeichnis je nach Projekttyp. Für Webanwendungen lies auch skills/GENERAL-KNOWLEDGE-WORKER/website-building/webapp/SKILL.md.
Universelle Designprinzipien (Farbphilosophie, Standardpalette, Schriftauswahl) werden über design-foundations mit anderen Skills geteilt. Die gemeinsamen Dateien dieses Skills erweitern diese Grundlagen um webspezifische Implementierungen (CSS-Variablen, responsive Tokens, Basis-Stylesheets). Du musst design-foundations nicht separat laden – die webspezifischen Versionen in shared/ sind umfassend.
Verwende read mit dem vollständigen Pfad, z.B. skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md
Projekttyp-Routing
Schritt 1: Identifiziere den Projekttyp und lade die domänenspezifische Anleitung:
| Projekttyp | Aktion | Beispiele |
|---|---|---|
| Informationsseiten | read skills/GENERAL-KNOWLEDGE-WORKER/website-building/informational/informational.md | Persönliche Seiten, Portfolios, Redaktionelles/Blogs, kleine Unternehmen, Landing Pages |
| Webanwendungen | read skills/GENERAL-KNOWLEDGE-WORKER/website-building/webapp/SKILL.md | SaaS-Produkte, Dashboards, Admin-Panels, E-Commerce, Markenerlebnisse |
| Browsergames | read skills/GENERAL-KNOWLEDGE-WORKER/website-building/game/game.md + skills/GENERAL-KNOWLEDGE-WORKER/website-building/game/game-testing.md | 2D-Canvas-Spiele, Three.js/WebGL, HTML5-Spiele, interaktive 3D-Erlebnisse |
Schritt 2: Lies die gemeinsamen Dateien – lies zuerst skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md und skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/02-typography.md (Pflicht für ALLE Projekttypen, einschließlich Webanwendungen). Diese legen die Kortix-Designsystem-Standards und Typografieregeln fest, die universell gelten. Für Webanwendungen und Dashboards überspringe die unten mit † markierten Dateien – diese enthalten Implementierungsdetails, die in der Fullstack-Vorlage vorkonfiguriert sind.
Wenn der Benutzer nur „Website“ oder „Seite“ ohne Details sagt, frage nach dem Typ oder verwende standardmäßig Informationsseiten.
Unterdateien-Referenz
Gemeinsam (shared/) – Jedes Projekt
| Datei | Deckt ab | Laden |
|---|---|---|
shared/01-design-tokens.md | Schriftskala, Abstände, Kortix-Palette, base.css | Immer |
shared/02-typography.md | Schriftauswahl, Paarung, Laden, Blacklist | Immer |
shared/04-layout.md | Räumliche Komposition, responsiv, Mobile-First | Immer † |
shared/05-taste.md | Skeleton-Loader, Leer-/Fehlerzustände, Verfeinerung | Immer |
shared/08-standards.md | Barrierefreiheit, Leistung, Anti-Patterns | Immer |
shared/09-technical.md | Projektstruktur, Sandbox, Bereitstellung, Checkliste | Immer † |
shared/head-defaults.html | Attributionsblock für <head> | Immer † |
shared/03-motion.md | Scroll-Animationen, Motion-Bibliothek, GSAP-SVG-Plugins, Hover/Cursor | Wenn animiert |
shared/06-css-and-tailwind.md | Tailwind CSS v3, shadcn/ui, modernes CSS | Bei Verwendung von Tailwind |
shared/07-toolkit.md | CDN-Bibliotheken, React, Three.js, Icons, Karten, SVG-Muster/Filter, esm.sh | Bei der Auswahl von Bibliotheken |
shared/10-charts-and-dataviz.md | Chart.js, Recharts, D3, KPIs, Sparklines | Wenn Datenvisualisierung benötigt wird |
shared/11-web-technologies.md | Framework-Versionen, Browserkompatibilität | Bei Kompatibilitätsprüfung |
shared/12-playwright-interactive.md | Dauerhafte Playwright-Browser-QA, Screenshots, visuelles Testen | Beim Testen |
shared/19-backend.md | FastAPI/Express/Flask-Server, WebSocket, SSE, Port-Weiterleitung | Wenn Backend benötigt wird |
shared/20-llm-api.md | LLM/KI-API-Integrationsreferenz | Wenn die Website KI-APIs verwendet |
Alle Pfade sind relativ zu skills/GENERAL-KNOWLEDGE-WORKER/website-building/.
† Für Webanwendungen und Dashboards überspringen – Implementierungsdetails sind in der Fullstack-Vorlage vorkonfiguriert. Design-Tokens und Typografie werden NICHT übersprungen – sie liefern die maßgeblichen Designsystem-Standards und Schriftauswahl-Richtlinien für alle Projekttypen.
Domänenspezifisch – Eine laden
| Datei | Wann laden |
|---|---|
read skills/GENERAL-KNOWLEDGE-WORKER/website-building/webapp/SKILL.md | SaaS, Dashboard, Admin, E-Commerce, Markenerlebnis (Unter-Skill mit Fullstack-Vorlage) |
webapp/dashboards.md | Dashboard oder datenreiche Oberfläche (Begleitdatei zu webapp) |
informational/informational.md | Persönliche Seite, Portfolio, Redaktionelles, kleines Unternehmen, Landing |
game/game.md | Browsergame, Three.js, WebGL, interaktives 3D |
game/2d-canvas.md | 2D-Canvas-Spiel (Begleitdatei zu game.md) |
game/game-testing.md | Jedes Browsergame – zusammen mit game.md laden |
Interaktive QA: Lies skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/12-playwright-interactive.md für dauerhafte Browser-Automatisierung mit Playwright (Screenshots, funktionale Tests, visuelle Qualitätssicherung). Erforderlich für Spieletests, nützlich für jede komplexe Website.
Arbeitsablauf
Schritt 0: Lade ALLE Pflichtdateien (mache dies ZUERST, parallel)
Lies ALLE diese Dateien in einem Durchgang – sie sind für jedes Projekt Pflicht:
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/02-typography.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/04-layout.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/05-taste.md")
read("skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/08-standards.md")
Lade dann die domänenspezifische Datei (informational, webapp oder game) aus Schritt 1 unten.
Schritt 1: Erstelle eine einzigartige Palette
Führe den Palettengenerator mit Schlüsselwörtern aus, die das Thema beschreiben:
bun run skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/generate-palette.ts "Themen-Schlüsselwörter hier"
Wähle die beste Harmonie aus, passe bei Bedarf an.
Schritt 2: Design & Bauen
Erstelle die Website mit der generierten Palette und befolge dabei alle geladenen Designvorgaben.
Schritt 3: Vorschau
Zeige sie über einen statischen Server an: show(type: "url", url: "http://localhost:3211/open?path=/workspace/project/index.html")
Verwende jedes Werkzeug
- Recherchiere zuerst. Suche im Web nach Referenzseiten, Trends und Konkurrenzbeispielen, bevor du designt. Durchstöbere preisgekrönte Beispiele des spezifischen Seitentyps. Rufe alle URLs ab, die der Benutzer angibt.
- Erstelle echte Assets – großzügig. Generiere Bilder für Hero-Bereiche, Abschnittsillustrationen, redaktionelle Feature-Bilder, atmosphärische Hintergründe – nicht nur ein einzelnes Hero-Bild. Jede lange Seite sollte einen visuellen Rhythmus mit generierten Bildern haben, die zur künstlerischen Ausrichtung der Seite passen. Keine Platzhalter. Generiere für jedes Projekt ein benutzerdefiniertes SVG-Logo (siehe unten) – SVG ist nur für Logos, es sei denn, der Benutzer fordert ausdrücklich eine SVG-Ausgabe an. Speichere Web-Referenzbilder, die die Richtung informieren.
- Screenshot via Playwright. Lies
skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/12-playwright-interactive.md, um Screenshots auf dem Desktop (1280px+) und mobil (375px) zu machen. Vergleiche mit Referenzen. Dies ist Pflicht, nicht optional. Siehe Visuelle QA unten. - Schreibe direkt Produktionscode. HTML, CSS, JS, SVG. Verwende Bash für Build-Tools und Dateiverarbeitung.
SVG-Logo-Generierung
Jedes Projekt erhält ein benutzerdefiniertes Inline-SVG-Logo. Ersetze niemals eine stilisierte Textüberschrift.
- Verstehe die Marke – Zweck, Ton, ein definierendes Wort
- Schreibe direkt SVG – geometrische Formen, Schriftzüge oder abstrakte Zeichen. Eine einprägsame Form.
- Prinzipien: Geometrisch/minimal (Paul Rand, Vignelli). Funktioniert bei 24px und 200px. Monochrom zuerst – füge Farbe als Verbesserung hinzu. Verwende
currentColorfür Hell-/Dunkelmodus. - Implementiere inline mit
aria-label,viewBox,fill="none",currentColor-Strichen - Generiere ein Favicon – bei Bedarf eine vereinfachte 32x32-Version
Für SVG-Animationen (DrawSVG, MorphSVG) siehe shared/03-motion.md. Für SVG-Muster/Filter siehe shared/07-toolkit.md.
Visueller QA-Testprozess
Jede Bereitstellung muss die visuelle QA bestehen. Screenshots sind Qualitätstore.
Lies skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/12-playwright-interactive.md für die gesamte visuelle QA. Playwright bietet eine dauerhafte Browsersitzung für Screenshots, Interaktionstests und Viewport-Überprüfungen.
Zyklus: Bauen → Playwright-QA → Bewerten → Beheben → Wiederholen → Bereitstellen, wenn bereit
Stufe 1: Seitenweise QA
Nach dem Bau jeder Seite:
- Screenshot auf Desktop (1280px+) und mobil (375px) via Playwright
- Bewerte kritisch: Sieht es professionell designt aus (nicht KI-generiert)? Ist die Typografie unverwechselbar? Sind die Abstände großzügig? Gibt es eine klare visuelle Hierarchie?
- Behebe jedes Problem, bevor du fortfährst. Keine visuellen Schulden.
Stufe 2: Abschließende QA (vor der Veröffentlichung)
- Screenshot jeder Seite auf Desktop und mobil
- Überprüfe die seitenübergreifende Konsistenz (Abstände, Farbe, Schriftbehandlung)
- Überprüfe den Dunkelmodus (Screenshot beider Designs mindestens für die Startseite)
- Überprüfe interaktive Zustände: Hover, Fokus, aktiv, laden, leer, Fehler
- Kaltstart-Eindruckstest: Fühlt es sich ausgefeilt und absichtsvoll an?
QA-Fehler: Textüberlauf, inkonsistente Abstände, falsche Farben, fehlender Dunkelmodus, gequetschte mobile Ansicht, generisches KI-Aussehen, Platzhalter-Inhalt, fehlendes Logo.
Schritt 1: Kunstrichtung – Leite ab, bevor du fragst; frage, bevor du zum Standard greifst
Jede Website sollte eine visuelle Identität haben, die aus ihrem Inhalt abgeleitet ist. Überspringe nicht die Kortix-Fallback-Palette. Die Kortix-Palette ist ein letzter Ausweg, wenn sowohl Ableitung als auch Nachfragen fehlgeschlagen sind – nicht eine bequeme Standardeinstellung.
- Leite aus dem Thema ab. Eine Kaffeerösterei-Seite → erdige Brauntöne, warmes Creme, handgezeichnetes Gefühl. Ein Fintech-Dashboard → kühles Schiefergrau, scharfe serifenlose Schrift, datendicht. Eine Kinder-Lern-App → helle Grundfarben, abgerundete Schrift, verspielte Bewegung. Der Inhalt selbst sagt dir die Palette, Typografie und Abstände, bevor der Benutzer ein Wort sagt.
- Überprüfe die Tabellen zur Kunstrichtung. Jede Domänendatei (
informational.md,webapp/SKILL.md,game/game.md) enthält eine Tabelle zur Kunstrichtung, die Website-/Produkttypen konzeptgetriebenen Richtungen und Ausgangspunkten für Tokens zuordnet. Verwende diese als Sprungbrett. - Leite die fünf Säulen ab: Farbe (warm/kühl, Akzent aus dem Thema), Typografie (Serife/serifenlos, Ausdruckspersönlichkeit), Abstände (dicht/großzügig), Bewegung (minimal/ausdrucksstark), Bildsprache (Foto/Illustration/nur Schrift).
- Wenn das Thema wirklich nicht eindeutig ist, frage – „Welche Stimmung möchtest du erzeugen?“ und „Gibt es Referenzseiten?“ Eine Frage reicht.
- Kortix-Fallback – nur wenn Ableitung UND Nachfragen nichts ergeben. Wenn der Benutzer gefragt wurde und keine Richtung angegeben hat UND das Thema kein klares Signal gibt, dann greife auf die Kortix/Swiss-Standards zurück.
Der Fallback: Sauber & Swiss (Letzter Ausweg)
Wenn die Ableitung keine klare Richtung ergab UND der Benutzer gefragt wurde, aber keine Stilvorgaben gemacht hat, verwende die Standardeinstellungen aus skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/01-design-tokens.md mit:
- Typografie: Satoshi oder General Sans für Fließtext (Fontshare – bevorzugt), oder Inter/DM Sans. Gewichtskontrast statt Schriftkontrast. Maximal 3-4 Größen. Halte Text kompakt –
--text-3xl/--text-herosind nur für Heldenbereiche von Informationsseiten. - Farbe: Kortix-Palette. Neutrale Flächen + ein türkiser Akzent nur für CTAs.
- Layout: Rasterausgerichtet. Großzügige Ränder. Asymmetrisch, wo es interessant ist.
- Bewegung: Minimal, funktional. Nur sanfte Zustandsübergänge.
- Bildsprache: Generiere saubere, relevante Grafiken. Keine Stockfotos.
Kunstrichtung – Vermeide die KI-Ästhetik
Siehe skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/08-standards.md für die vollständige Liste der Anti-Patterns.
Schritt 2: Veröffentlichen
Verwende zuerst echte lokale Vorschau-Befehle und veröffentliche nur mit dem tatsächlichen Bereitstellungsworkflow des Zielprojekts. Siehe skills/GENERAL-KNOWLEDGE-WORKER/website-building/shared/09-technical.md für den empfohlenen Vorschau- und Lieferablauf.
Lieferung
- Überprüfe die Website immer zuerst lokal.
- Verwende
pty_spawnfür den Vorschau- oder Entwicklungs-Server. - Wenn das Ziel-Repository bereits einen Bereitstellungsworkflow hat, verwende genau diesen Workflow.
- Wenn es kein etabliertes Bereitstellungsziel gibt, liefere die Dateien und eine verifizierte lokale Vorschau, anstatt eine plattformspezifische Bereitstellungsgeschichte zu erfinden.