feat: Replace web project skeleton with AI briefing and framework documentation, and remove various development-related files.

This commit is contained in:
1elle1
2026-02-04 20:38:52 +01:00
parent 6c7ae06e58
commit 00dbf6b869
47 changed files with 812 additions and 4590 deletions

View File

@@ -1,21 +0,0 @@
# Environment Variables
# Copy this file to .env.local and fill in the values
# Node Environment
NODE_ENV=development
# Next.js
NEXT_PUBLIC_SITE_URL=http://localhost:3000
# Analytics (optional)
# NEXT_PUBLIC_GA_ID=
# CMS (optional)
# CMS_API_URL=
# CMS_API_KEY=
# Email (optional)
# SMTP_HOST=
# SMTP_PORT=
# SMTP_USER=
# SMTP_PASS=

45
.gitignore vendored
View File

@@ -1,32 +1,33 @@
# dependencies
node_modules
/node_modules
/.pnp
.pnp.js
# Dependencies
node_modules/
# testing
/coverage
# Build outputs
.next/
out/
dist/
build/
# next.js
/.next/
/out/
# IDE
.idea/
.vscode/
*.swp
*.swo
# production
/build
# misc
# OS
.DS_Store
*.pem
Thumbs.db
# debug
# Logs
*.log
npm-debug.log*
yarn-debug.log*
ts-debug.log*
# local env files
# Environment
.env
.env.local
.env*.local
.env.*.local
# vercel
.vercel
# TypeScript
*.tsbuildinfo
# Generated files
generated/

169
README.md
View File

@@ -1,146 +1,73 @@
# Website Skeleton
# WebsiteSkeleton
Minimalistisches Runtime-Skeleton für KI-generierte Websites.
## AI-First Website Generation System
Dieses Repository ist ein **Skeleton für die KI-gestützte Website-Generierung**. Es enthält keine lauffähige Website, sondern ausschließlich Markdown-Dateien, die der KI beschreiben, **was** erreicht werden soll.
Die KI entscheidet autonom über:
- Seitenarchitektur & Struktur
- Layout & Section-Reihenfolge
- Typografie & Spacing
- Komponentenwahl
- Visuelle Hierarchie
---
## Was ist das?
Dieses Repository ist **kein Website-Template**. Es enthält:
- Keine fertigen Layouts
- Keine UI-Komponenten
- Keine Design-Vorgaben
Es ist ein neutraler, stabiler Arbeitscontainer, mit dem KI individuelle Websites von Grund auf generiert.
---
## Für KI-Systeme
**Vor der Website-Generierung müssen folgende Dateien gelesen werden:**
1. `/skills/SYSTEM_SKILLS.md` - Grundregeln und Verbote
2. `/skills/UI_GUIDELINES.md` - Qualitätsstandards
3. `/skills/DEFINITION_OF_DONE.md` - Abnahmekriterien
4. `/spec/ProjectSpec.json` - Projektspezifikation
5. `/spec/design_tokens.json` - Design-System
6. `/prompts/master_prompt.md` - Workflow-Anleitung
---
## Tech-Stack
| Kategorie | Technologie |
|-----------|-------------|
| Framework | Next.js 15+ (App Router) |
| UI | React 19 |
| Sprache | TypeScript |
| Styling | Tailwind CSS v4 |
| Animation | framer-motion, lenis |
| Icons | lucide-react |
| Runtime | Node.js 20.x LTS |
---
## Projektstruktur
## Repository-Struktur
```
/
├── app/ # Next.js App Router
├── components/ # Fundament-Komponenten
│ ├── layout/ # Container, Section
│ └── ui/ # Button, Card
├── src/ # Projekt-spezifischer Code (Utils, Hooks)
├── skills/ # KI-Regeln und Guidelines
├── spec/ # Projektspezifikation & Design Tokens
├── theme/ # CSS Variables & Stylesheets
├── prompts/ # KI-Prompts
├── content/ # Inhalte (MDX, JSON)
├── assets/ # Medien (Bilder, Fonts)
├── meta/ # Generierungs-Logs
├── docker/ # Docker-Konfiguration
└── [config files] # package.json, tsconfig.json, etc.
/framework
FRAMEWORK.md # Technischer Stack (Next.js, TypeScript, Tailwind)
/ai
SYSTEM_RULES.md # Harte Qualitätsregeln
QUALITY_STANDARD.md # Definition von "launch-ready"
AI_DECISION_LOGIC.md # Entscheidungskompetenz der KI
/briefs
PROJECT_BRIEF.md # Projektübersicht
BUSINESS_CONTEXT.md # Firma, Markt, Positionierung
USER_CONTEXT.md # Zielgruppe, Bedürfnisse
CONTENT_INTENT.md # Inhalte, die überzeugen sollen
DESIGN_INTENT.md # Gewünschte Wirkung
SEO_INTENT.md # Keywords, Suchintention
CONSTRAINTS.md # No-Gos, rechtliche Anforderungen
/prompts
MASTER_PROMPT.md # Orchestrator-Prompt für die KI
README.md # Diese Datei
```
---
## Entwicklung
## Verwendung
### Voraussetzungen
### Für den Website Prototype Generator:
- Node.js 20.x oder höher
- npm
1. Clone dieses Repository
2. Befülle die `briefs/*.md` Dateien mit Kundeninformationen
3. Übergib das Repository an die KI zusammen mit `prompts/MASTER_PROMPT.md`
4. Die KI generiert eine vollständige, launch-ready Website
### Installation
### Wichtig:
```bash
npm install
```
### Development Server
```bash
npm run dev
```
Öffne [http://localhost:3000](http://localhost:3000).
### Production Build
```bash
npm run build
npm run start
```
- Die Dateien in `/ai` und `/framework` bleiben **unverändert**
- Nur die Dateien in `/briefs` werden pro Projekt angepasst
- Der `MASTER_PROMPT.md` orchestriert den gesamten Generierungsprozess
---
## Docker
## Philosophie
### Development
> Das Skeleton beschreibt **WAS**, nicht **WIE**.
```bash
cd docker
docker-compose up
```
Klassische Templates kontrollieren die KI durch vordefinierte Strukturen. Dieses System **befähigt** die KI, optimale Entscheidungen zu treffen.
### Production Build
```bash
docker build -f docker/Dockerfile -t website .
docker run -p 3000:3000 website
```
---
## Workflow für neue Projekte
1. **Spec ausfüllen**: `spec/ProjectSpec.json` mit Projektdaten füllen
2. **Tokens anpassen**: `spec/design_tokens.json` mit Farben, Fonts etc.
3. **KI starten**: Mit Verweis auf `/skills` und `/spec`
4. **Generieren**: KI erstellt Website basierend auf Specs
5. **Prüfen**: Definition of Done validieren
6. **Deployen**: Build erstellen und ausliefern
---
## Entwicklungshinweise
> **Build und Dev dürfen nicht gleichzeitig laufen.**
> Next.js kann CSS-Referenzen verlieren, wenn `npm run build` und `npm run dev` parallel ausgeführt werden.
> Nutze `npm run clean` um den `.next` Cache zu löschen, falls Styling-Probleme auftreten.
---
## Wichtig
- Dieses Skeleton erzwingt **kein Design**
- Alle Werte in `design_tokens.json` sind **Platzhalter**
- Die KI **muss** die Skills lesen bevor sie Code generiert
- Jede Website wird **individuell** erstellt
Das Ergebnis: Jeder Kunde erhält eine **einzigartige**, auf seinen Kontext zugeschnittene Website keine "gleich gebauten" Varianten desselben Templates.
---
## Lizenz
Proprietär - Nur für autorisierte Nutzung.
Copyright © EB Solutions

View File

@@ -1,56 +0,0 @@
# READ FIRST
## Pflicht-Lesereihenfolge
Bevor an diesem Projekt gearbeitet wird, müssen folgende Dateien gelesen und verstanden werden:
1. `skills/SYSTEM_SKILLS.md` Grundregeln und Verbote
2. `skills/UI_GUIDELINES.md` Qualitätsstandards für UI
3. `skills/DEFINITION_OF_DONE.md` Abnahmekriterien
4. `spec/ProjectSpec.json` Projektspezifikation
5. `spec/design_tokens.json` Design-Token-Definitionen
6. `prompts/master_prompt.md` Workflow-Anleitung
---
## Entwicklungswarnung
> **Build und Dev dürfen NICHT gleichzeitig laufen.**
>
> Wenn `npm run build` und `npm run dev` parallel ausgeführt werden, verliert Next.js CSS-Referenzen.
> Das führt zu fehlendem Styling und instabilem Hot-Reload.
>
> **Lösung bei Problemen:**
> ```bash
> npm run clean
> ```
> Dieser Befehl löscht den `.next` Cache und stellt einen sauberen Zustand her.
---
## Inline-Styling ist verboten
`style={{ ... }}` ist im gesamten Projekt verboten. Alle Styles müssen über:
- `theme/globals.css` CSS Variables (`:root`)
- `theme/stylesheet.css` Typografie & strukturelle Regeln
- `spec/design_tokens.json` Token-Definitionen
gesteuert werden.
---
## Architektur-Überblick
```
components/
├── layout/
│ ├── Container.tsx → Max-Width, horizontales Padding, responsive
│ └── Section.tsx → Vertikaler Rhythmus (Spacing)
└── ui/
├── Button.tsx → Varianten: primary / secondary / ghost
└── Card.tsx → Neutraler Wrapper (Radius, Border, Shadow)
```
Diese Komponenten verwenden ausschließlich CSS Variables aus `globals.css`.
Sie diktieren KEIN Design sie erzwingen Struktur.

View File

@@ -1,54 +0,0 @@
# Security Policy
## Unterstützte Versionen
| Version | Unterstützt |
|---------|-------------|
| 1.x | Ja |
## Sicherheitsrichtlinien
### Umgebungsvariablen
- **Niemals** sensible Daten in den Code committen
- `.env.local` ist in `.gitignore` aufgeführt
- Produktions-Secrets über sichere CI/CD-Variablen verwalten
### Dependencies
- Regelmäßig `npm audit` ausführen
- Kritische Vulnerabilities sofort beheben
- Dependencies aktuell halten
### Code-Sicherheit
- Input-Validierung für alle Benutzereingaben
- XSS-Prävention (React escaped standardmäßig)
- CSRF-Schutz bei Formularen
- Keine `dangerouslySetInnerHTML` ohne Sanitization
- Content Security Policy (CSP) konfigurieren
### API-Sicherheit
- Rate Limiting implementieren
- API-Keys niemals clientseitig exponieren
- HTTPS erzwingen
- CORS restriktiv konfigurieren
### Headers
Empfohlene Security Headers:
```
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin
Content-Security-Policy: [projektspezifisch]
```
## Vulnerability melden
Bei Sicherheitsproblemen bitte direkt an den Projektverantwortlichen wenden.
**Keine** öffentlichen Issues für Sicherheitslücken erstellen.

101
ai/AI_DECISION_LOGIC.md Normal file
View File

@@ -0,0 +1,101 @@
# AI Decision Logic
## Deine Rolle
Du bist nicht nur ein Ausführer von Anweisungen. Du bist der Architekt dieser Website.
---
## Was du entscheiden MUSST
Die folgenden Aspekte sind nicht vorgegeben und liegen vollständig in deiner Verantwortung:
### Seitenarchitektur
- Welche Seiten braucht die Website?
- Wie sind sie miteinander verknüpft?
- Was kommt in die Navigation?
### Section-Reihenfolge
- In welcher Reihenfolge erscheinen Inhalte?
- Was kommt zuerst, was später?
- Was braucht mehr Platz, was weniger?
### Visuelle Hierarchie
- Was ist die wichtigste Information?
- Wie lenke ich den Blick des Nutzers?
- Welche Elemente heben sich ab?
### Komponenteneinsatz
- Welche UI-Patterns sind angemessen?
- Cards, Listen, Grids, Hero-Sections?
- Animations, Transitions, Hover-States?
### Layout & Spacing
- Wie viel Whitespace ist richtig?
- Welche Spaltenaufteilung funktioniert?
- Mobile-First oder Desktop-First?
---
## Umgang mit Kundenangaben
Die Briefing-Dateien enthalten Informationen, keine Befehle.
### Wenn etwas explizit angegeben ist:
→ Berücksichtige es als starke Präferenz
### Wenn etwas unklar ist:
→ Triff eine fundierte Entscheidung basierend auf Kontext
### Wenn etwas fehlt:
→ Ergänze sinnvoll, ohne nachzufragen
### Wenn etwas bessser geht:
→ Mach es besser
---
## Kernprinzipien der Entscheidungsfindung
### 1. Weniger ist mehr
Lieber eine saubere Seite mit wenigem Inhalt als eine überladene mit allem.
### 2. Qualität über Vollständigkeit
Eine perfekte Hero-Section ist wertvoller als fünf halbfertige Sections.
### 3. Erst denken, dann bauen
Verstehe das Ziel, plane die Struktur, dann erst Code.
### 4. Der Nutzer zählt
Jede Entscheidung sollte dem Endnutzer dienen, nicht dem Client oder der KI selbst.
### 5. Konsistenz
Einmal getroffene Entscheidungen (Farben, Abstände, Patterns) durchgängig anwenden.
---
## Explizite Erlaubnis
Du DARFST und SOLLST:
- Von Vorschlägen abweichen, wenn du bessere Lösungen siehst
- Inhalte kürzen, wenn sie zu lang sind
- Sections weglassen, die keinen Wert bieten
- Strukturen vereinfachen
- Eigene kreative Entscheidungen treffen
Du bist der Experte. Handle entsprechend.

71
ai/QUALITY_STANDARD.md Normal file
View File

@@ -0,0 +1,71 @@
# Quality Standard
## Was bedeutet "Launch-Ready"?
Eine Website ist launch-ready, wenn sie ohne weitere Überarbeitung live gehen könnte. Das bedeutet nicht "fertig für später", sondern "fertig für jetzt".
---
## Visuelle Qualität
### Die Website wirkt:
- **Ruhig** Kein visuelles Chaos, klare Struktur
- **Hochwertig** Durchdachte Details, keine Provisorien
- **Konsistent** Gleiche Elemente sehen überall gleich aus
- **Zeitgemäß** Modernes Design, keine veralteten Muster
### Sie vermeidet:
- Überladene Layouts
- Zu viele Farben oder Schriften
- Inkonsistente Abstände
- Ablenkende Animationen
---
## Technische Qualität
### Performance
- Bilder sind optimiert (WebP, lazy loading)
- Keine unnötigen Dependencies
- Minimaler JavaScript-Footprint
- Schnelle Time-to-Interactive
### SEO
- Korrekte Meta-Tags (title, description, og:*)
- Strukturierte Überschriften-Hierarchie
- Semantisches HTML
- Valide sitemap.xml (falls relevant)
### GEO (Generative Engine Optimization)
- Klare, gut strukturierte Inhalte
- Beantwortung von Nutzerfragen im Content
- Schema.org Markup wo sinnvoll
---
## UX-Qualität
### Die Website ist:
- **Klar** Der Nutzer versteht sofort, worum es geht
- **Verständlich** Navigation und Struktur sind intuitiv
- **Nicht überladen** Jedes Element hat einen Zweck
- **Zielführend** Der Nutzer findet, was er sucht
### Sie vermeidet:
- Versteckte Navigation
- Zu viel Text ohne Struktur
- Unklare Call-to-Actions
- Verwirrende Nutzerführung
---
## Prüfmethodik
Die KI prüft ihre Arbeit selbst anhand dieser Kriterien, bevor sie die Website als "fertig" deklariert.

77
ai/SYSTEM_RULES.md Normal file
View File

@@ -0,0 +1,77 @@
# System Rules
## Nicht verhandelbare Prinzipien
Diese Regeln gelten für jede generierte Website. Sie sind keine Empfehlungen, sondern harte Anforderungen.
---
### 1. Kein Inline-Styling
Styles gehören in Tailwind-Klassen oder CSS-Module. Niemals `style={{ }}` in JSX.
**Warum**: Wartbarkeit, Konsistenz, Performance.
---
### 2. Accessibility ist Pflicht
- Semantisches HTML (`<nav>`, `<main>`, `<article>`, etc.)
- Alle interaktiven Elemente per Tastatur erreichbar
- Bilder haben aussagekräftige `alt`-Texte
- Ausreichende Farbkontraste
- ARIA-Labels wo nötig
**Warum**: Rechtliche Anforderungen, Nutzerfreundlichkeit, SEO.
---
### 3. Responsive Design
Jede Seite muss auf allen Bildschirmgrößen funktionieren:
- Mobile (ab 320px)
- Tablet
- Desktop (bis 1920px+)
**Warum**: Moderne Nutzergewohnheiten.
---
### 4. Saubere Typografie
- Klare Hierarchie (h1 → h6)
- Angemessene Zeilenhöhe
- Lesbare Schriftgrößen
- Konsistente Schriftfamilien
**Warum**: Professionalität, Lesbarkeit.
---
### 5. Kein "HTML-Look"
Die Website darf niemals aussehen wie:
- Unstyled HTML
- Bootstrap-Standard-Theme
- Template aus 2010
Sie muss zeitgemäß, poliert und einzigartig wirken.
---
### 6. Der Build muss funktionieren
- Keine TypeScript-Fehler
- Keine ungenutzten Imports
- Keine fehlenden Dependencies
- `npm run build` muss durchlaufen
---
### 7. Autonome Verbesserung
Wenn die KI einen besseren Weg findet, etwas umzusetzen, **soll sie ihn wählen** solange die anderen Regeln eingehalten werden.
Die Kundenangaben sind Richtlinien, keine unantastbaren Befehle.

View File

@@ -1,98 +0,0 @@
import type { Metadata, Viewport } from "next";
import "@/theme/globals.css";
/**
* Root Layout
*
* This layout is designed to work with the 9-category parameter system.
* It supports:
* - Dynamic locale (from spec.client.locale or content.defaultLanguage)
* - Google Fonts loading (from spec.brand.fonts)
* - Scroll behavior (from spec.interaction.scrollBehavior)
* - Meta tags for SEO
*
* CUSTOMIZATION INSTRUCTIONS:
* 1. Update `lang` attribute based on spec.client.locale (e.g., "de", "de-AT", "en")
* 2. Add Google Fonts import based on spec.brand.fonts.heading.family and body.family
* 3. Set scroll-behavior in globals.css based on spec.interaction.scrollBehavior
* 4. Update metadata based on spec.brand and spec.seo
*/
// TODO: Update these values based on ProjectSpec.json
// - title: from spec.brand.name or spec.meta.projectName
// - description: from spec.brand.description
// - keywords: from spec.seo.primaryKeywords
export const metadata: Metadata = {
title: "Website",
description: "Generated website",
robots: {
index: true,
follow: true,
},
// Open Graph tags - update based on spec
openGraph: {
type: "website",
locale: "de_DE",
// title, description, images will be set per project
},
};
export const viewport: Viewport = {
width: "device-width",
initialScale: 1,
// TODO: Update themeColor from spec.brand.colors.primary or design_tokens
themeColor: "#ffffff",
};
/**
* Font Loading
*
* To add Google Fonts based on spec.brand.fonts:
*
* 1. Import from next/font/google:
* import { Inter, Playfair_Display } from "next/font/google";
*
* 2. Configure fonts:
* const headingFont = Playfair_Display({
* subsets: ["latin"],
* variable: "--font-heading",
* display: "swap",
* });
*
* const bodyFont = Inter({
* subsets: ["latin"],
* variable: "--font-body",
* display: "swap",
* });
*
* 3. Apply to html element:
* <html lang="de" className={`${headingFont.variable} ${bodyFont.variable}`}>
*
* 4. Update globals.css to use the variables:
* --font-sans: var(--font-body), system-ui, sans-serif;
* --font-heading: var(--font-heading), Georgia, serif;
*/
export default function RootLayout({
children,
}: Readonly<{
children: React.ReactNode;
}>) {
// TODO: Update lang attribute based on spec.client.locale
// Examples: "de", "de-AT", "de-CH", "en", "en-US"
const locale = "de";
return (
<html lang={locale}>
{/*
Scroll Behavior:
- If spec.interaction.scrollBehavior === "smooth", add className="scroll-smooth"
- Or set scroll-behavior: smooth in globals.css on html element
Example with smooth scrolling:
<html lang={locale} className="scroll-smooth">
*/}
<body>{children}</body>
</html>
);
}

View File

@@ -1,14 +0,0 @@
import { Container } from "@/components/layout/Container";
import { Section } from "@/components/layout/Section";
export default function Page() {
return (
<main>
<Section>
<Container>
<p>Ready</p>
</Container>
</Section>
</main>
);
}

View File

@@ -1,45 +0,0 @@
# Assets
Dieses Verzeichnis enthält statische Medien.
## Struktur
```
assets/
├── images/ # Bilder (JPG, PNG, WebP, AVIF, SVG)
├── videos/ # Videos (MP4, WebM)
├── fonts/ # Schriftarten (WOFF2)
├── icons/ # Icons (SVG)
└── README.md
```
## Bildoptimierung
- **Format**: WebP oder AVIF bevorzugen
- **Größe**: Maximal 200kb pro Bild
- **Responsive**: Mehrere Größen bereitstellen
- **Alt-Texte**: Immer beschreibende Alt-Texte verwenden
## Namenskonvention
```
[beschreibung]-[größe].[format]
Beispiele:
hero-image-1920.webp
hero-image-960.webp
logo.svg
team-member-portrait.jpg
```
## Fonts
- Nur WOFF2 verwenden
- Subset auf benötigte Zeichen
- In globals.css mit @font-face einbinden
## Hinweise
- Keine unnötigen Assets hochladen
- Vor Commit optimieren
- Copyright beachten

View File

@@ -0,0 +1,58 @@
# Business Context
> **Hinweis**: Diese Datei wird vom Website Prototype Generator dynamisch befüllt.
---
## Unternehmen/Organisation
### Name
[Offizieller Name]
### Branche
[Branche/Sektor]
### Gründung
[Jahr, optional]
### Größe
[Anzahl Mitarbeiter, Standorte, etc.]
---
## Marktposition
### Kerngeschäft
[Was macht das Unternehmen?]
### Alleinstellungsmerkmale (USPs)
1. [USP 1]
2. [USP 2]
3. [USP 3]
### Wettbewerbsumfeld
[Wie positioniert sich das Unternehmen gegenüber Mitbewerbern?]
---
## Werte & Kultur
### Unternehmenswerte
[Was ist dem Unternehmen wichtig?]
### Tonalität der Kommunikation
[Formell, freundlich, technisch, nahbar, etc.]
---
## Regionale Verankerung
### Hauptstandort
[Stadt/Region]
### Service-Gebiet
[Lokal, regional, national, international]
---
*Diese Informationen helfen der KI, die richtige Tonalität und Positionierung zu wählen.*

67
briefs/CONSTRAINTS.md Normal file
View File

@@ -0,0 +1,67 @@
# Constraints
> **Hinweis**: Diese Datei wird vom Website Prototype Generator dynamisch befüllt.
---
## No-Gos
### Inhaltlich
- [Was darf auf keinen Fall erscheinen?]
- [Themen, die vermieden werden sollen]
### Visuell
- [Farben, die vermieden werden sollen]
- [Stilrichtungen, die nicht passen]
### Technisch
- [Libraries/Frameworks, die nicht verwendet werden dürfen]
---
## Rechtliche Anforderungen
### Datenschutz (DSGVO)
- [ ] Cookie-Banner erforderlich
- [ ] Datenschutzerklärung erforderlich
- [ ] Kontaktformular-Hinweise
### Impressumspflicht
- [ ] Vollständiges Impressum
### Branchenspezifisch
[Besondere rechtliche Anforderungen der Branche]
---
## Technische Einschränkungen
### Hosting
[Besondere Hosting-Anforderungen oder -Einschränkungen]
### Browserunterstützung
[Mindestanforderungen an Browser-Kompatibilität]
### Performance-Budget
[Falls definiert: Maximale Ladezeit, Bundle-Größe, etc.]
---
## Zeitliche Einschränkungen
### Deadline
[Falls relevant]
### Priorisierung
[Was muss zuerst fertig sein?]
---
## Budget-Einschränkungen
### Keine kostenpflichtigen Services
[Falls relevant: Keine Stock-Fotos, keine Premium-Fonts, etc.]
---
*Constraints sind harte Grenzen, keine Präferenzen.*

66
briefs/CONTENT_INTENT.md Normal file
View File

@@ -0,0 +1,66 @@
# Content Intent
> **Hinweis**: Diese Datei wird vom Website Prototype Generator dynamisch befüllt.
---
## Kernbotschaft
[Die eine Aussage, die Besucher mitnehmen sollen]
---
## Inhalte, die überzeugen sollen
### Vertrauensaufbau
- [Referenzen/Testimonials]
- [Zertifizierungen]
- [Zahlen/Fakten]
### Kompetenz zeigen
- [Expertise-Bereiche]
- [Case Studies/Projekte]
- [Team/Qualifikationen]
### Handlung auslösen
- [Primärer CTA]
- [Sekundärer CTA]
---
## Inhaltstypen
[Welche Arten von Content werden benötigt?]
- [ ] Texte (Fließtext, Headlines)
- [ ] Bilder (Fotos, Illustrationen)
- [ ] Icons
- [ ] Videos
- [ ] Testimonials/Zitate
- [ ] Statistiken/Zahlen
- [ ] Formulare
- [ ] Karten/Maps
- [ ] Downloads (PDFs, etc.)
---
## Ton & Stil des Contents
### Sprachstil
[Sachlich, emotional, technisch, locker, etc.]
### Ansprache
[Du/Sie, direkt/indirekt]
### Textlänge
[Kurz & knackig vs. ausführlich & informativ]
---
## Vorhandene Inhalte
[Was existiert bereits? Was muss erstellt werden?]
---
*Der Content bestimmt maßgeblich, wie die Website strukturiert wird.*

55
briefs/DESIGN_INTENT.md Normal file
View File

@@ -0,0 +1,55 @@
# Design Intent
> **Hinweis**: Diese Datei wird vom Website Prototype Generator dynamisch befüllt.
---
## Gewünschte Wirkung
[Wie soll die Website auf den Besucher wirken?]
### Atmosphäre-Wörter
- [z.B. Modern, Vertrauenswürdig, Innovativ]
- [z.B. Warm, Einladend, Professionell]
- [z.B. Minimalistisch, Klar, Hochwertig]
### Die Website soll NICHT wirken wie:
- [z.B. Kalt, Technisch, Überladen]
- [z.B. Billig, Generisch, Veraltet]
---
## Farbpräferenzen
### Vorhandene Markenfarben
[Falls vorhanden: Hex-Codes oder Beschreibungen]
### Gewünschte Farbrichtung
[Falls keine Markenfarben: Dunkel/Hell, Warm/Kühl, Bunt/Zurückhaltend]
---
## Inspiration & Referenzen
### Positiv-Beispiele
[URLs oder Beschreibungen von Websites, die gefallen]
### Was daran gefällt
[Konkrete Elemente, nicht "alles"]
---
## Was die KI entscheidet
Die folgenden Aspekte sind NICHT vorgegeben und liegen in der Verantwortung der KI:
- Konkrete Farbwerte (außer gegebene Markenfarben)
- Typografie-Auswahl
- Spacing & Layout
- Komponentenstile
- Animationen
- Bildstile
---
*Diese Datei gibt eine Richtung vor, keine Implementierung.*

31
briefs/PROJECT_BRIEF.md Normal file
View File

@@ -0,0 +1,31 @@
# Project Brief
> **Hinweis**: Diese Datei wird vom Website Prototype Generator dynamisch befüllt. Die Platzhalter zeigen die erwartete Struktur.
---
## Projektname
[Wird vom Generator eingefügt]
## Zusammenfassung
[Kurze Beschreibung des Projekts in 2-3 Sätzen: Was ist das Unternehmen/die Organisation? Was soll die Website erreichen?]
## Hauptziele der Website
1. [Primäres Ziel]
2. [Sekundäres Ziel]
3. [Tertiäres Ziel, falls vorhanden]
## Gewünschte Wirkung
[Wie soll sich ein Besucher nach dem Besuch der Website fühlen? Was soll er tun?]
## Besondere Anforderungen
[Spezifische Features, Integrationen oder Einschränkungen, die berücksichtigt werden müssen]
---
*Diese Datei ist der Ausgangspunkt für alle anderen Briefs. Sie gibt den Gesamtkontext vor.*

77
briefs/SEO_INTENT.md Normal file
View File

@@ -0,0 +1,77 @@
# SEO Intent
> **Hinweis**: Diese Datei wird vom Website Prototype Generator dynamisch befüllt.
---
## Primäre Suchintention
### Hauptkeyword
[Das wichtigste Keyword, für das gerankt werden soll]
### Suchintention dahinter
[Was sucht jemand, der dieses Keyword eingibt?]
---
## Keyword-Cluster
### Primäre Keywords
1. [Keyword 1]
2. [Keyword 2]
3. [Keyword 3]
### Sekundäre Keywords
- [Longtail-Keyword 1]
- [Longtail-Keyword 2]
- [Longtail-Keyword 3]
---
## Lokale SEO
### Zielregion
[Stadt, Region, Land]
### Lokale Begriffe
[Regionale Bezeichnungen, Ortsnamen, etc.]
### Google Business Profile
[Vorhanden? Zu optimieren?]
---
## Wettbewerbs-Keywords
### Konkurrenten
- [Konkurrent 1]
- [Konkurrent 2]
### Keywords, die Konkurrenten ranken
[Falls bekannt]
---
## Content-Strategie für SEO
### Fragen, die beantwortet werden sollen
- [Frage 1]
- [Frage 2]
- [Frage 3]
### Themencluster
[Übergeordnete Themen, die abgedeckt werden sollen]
---
## Technische SEO-Anforderungen
- [ ] Schnelle Ladezeiten
- [ ] Mobile-Optimierung
- [ ] Strukturierte Daten (Schema.org)
- [ ] Sitemap
- [ ] Robots.txt
---
*SEO ist kein Nachsatz, sondern beeinflusst die gesamte Content-Struktur.*

51
briefs/USER_CONTEXT.md Normal file
View File

@@ -0,0 +1,51 @@
# User Context
> **Hinweis**: Diese Datei wird vom Website Prototype Generator dynamisch befüllt.
---
## Primäre Zielgruppe
### Wer sind sie?
[Demografische und psychografische Merkmale]
### Wo kommen sie her?
[Wie finden sie zur Website? Google, Social Media, Empfehlung, etc.]
### Was suchen sie?
[Welche Informationen oder Lösungen erwarten sie?]
---
## Probleme & Bedürfnisse
### Hauptproblem
[Das wichtigste Problem, das die Zielgruppe hat]
### Weitere Bedürfnisse
- [Bedürfnis 1]
- [Bedürfnis 2]
- [Bedürfnis 3]
---
## Erwartungen an die Website
### Was erwarten sie zu finden?
[Konkrete Inhalte, Features, Informationen]
### Was würde sie überzeugen?
[Vertrauenssignale, Beweise, Testimonials, etc.]
### Was würde sie abschrecken?
[No-Gos aus Nutzersicht]
---
## Sekundäre Zielgruppen
[Falls vorhanden: Weitere Nutzergruppen und ihre spezifischen Bedürfnisse]
---
*Je besser das Nutzerverständnis, desto zielgerichteter kann die KI die Website gestalten.*

View File

@@ -1,21 +0,0 @@
import type { ElementType, ReactNode } from "react";
interface ContainerProps {
children: ReactNode;
className?: string;
as?: ElementType;
}
export function Container({
children,
className = "",
as: Tag = "div",
}: ContainerProps) {
return (
<Tag
className={`mx-auto w-full max-w-[var(--container-max-width)] px-[var(--container-padding-x)] ${className}`.trim()}
>
{children}
</Tag>
);
}

View File

@@ -1,21 +0,0 @@
import type { ElementType, ReactNode } from "react";
interface SectionProps {
children: ReactNode;
className?: string;
as?: ElementType;
}
export function Section({
children,
className = "",
as: Tag = "section",
}: SectionProps) {
return (
<Tag
className={`py-[var(--section-spacing-y)] ${className}`.trim()}
>
{children}
</Tag>
);
}

View File

@@ -1,2 +0,0 @@
# This file keeps the sections folder in git
# Remove this file once you add actual section components

View File

@@ -1,45 +0,0 @@
import type { ButtonHTMLAttributes, ReactNode } from "react";
type ButtonVariant = "primary" | "secondary" | "ghost";
type ButtonSize = "sm" | "md" | "lg";
interface ButtonProps extends ButtonHTMLAttributes<HTMLButtonElement> {
children: ReactNode;
variant?: ButtonVariant;
size?: ButtonSize;
}
const baseClasses =
"inline-flex items-center justify-center font-medium rounded-[var(--radius-md)] transition-all duration-[var(--duration-normal)] ease-[var(--easing-default)] focus-visible:outline-2 focus-visible:outline-offset-2 focus-visible:outline-[color:var(--color-primary)] disabled:pointer-events-none disabled:opacity-50";
const variantClasses: Record<ButtonVariant, string> = {
primary:
"bg-[var(--color-primary)] text-[color:var(--color-background)] hover:opacity-90",
secondary:
"bg-[var(--color-muted)] text-[color:var(--color-foreground)] border border-[color:var(--color-border)] hover:opacity-80",
ghost:
"bg-transparent text-[color:var(--color-foreground)] hover:bg-[var(--color-muted)]",
};
const sizeClasses: Record<ButtonSize, string> = {
sm: "px-[var(--spacing-sm)] py-[var(--spacing-xs)] text-[length:var(--font-size-sm)]",
md: "px-[var(--spacing-md)] py-[var(--spacing-sm)] text-[length:var(--font-size-base)]",
lg: "px-[var(--spacing-lg)] py-[var(--spacing-md)] text-[length:var(--font-size-lg)]",
};
export function Button({
children,
variant = "primary",
size = "md",
className = "",
...props
}: ButtonProps) {
return (
<button
className={`${baseClasses} ${variantClasses[variant]} ${sizeClasses[size]} ${className}`.trim()}
{...props}
>
{children}
</button>
);
}

View File

@@ -1,21 +0,0 @@
import type { ElementType, ReactNode } from "react";
interface CardProps {
children: ReactNode;
className?: string;
as?: ElementType;
}
export function Card({
children,
className = "",
as: Tag = "div",
}: CardProps) {
return (
<Tag
className={`rounded-[var(--radius-md)] border border-[color:var(--color-border)] shadow-[var(--shadow-sm)] p-[var(--spacing-lg)] ${className}`.trim()}
>
{children}
</Tag>
);
}

View File

@@ -1,27 +0,0 @@
# Content
Dieses Verzeichnis enthält die Inhalte der Website.
## Struktur
```
content/
├── pages/ # Seiteninhalte (MDX, JSON, etc.)
├── components/ # Komponenteninhalte
├── data/ # Strukturierte Daten
└── README.md
```
## Verwendung
Inhalte werden projektspezifisch hinzugefügt. Mögliche Formate:
- **MDX**: Für reichhaltige Textinhalte mit Komponenten
- **JSON**: Für strukturierte Daten
- **YAML**: Für Konfigurationen
## Hinweise
- Inhalte von Code trennen
- Mehrsprachigkeit berücksichtigen
- Assets in `/assets` ablegen, nicht hier

View File

@@ -1,47 +0,0 @@
# syntax=docker/dockerfile:1
# Base image
FROM node:20-alpine AS base
WORKDIR /app
# Dependencies
FROM base AS deps
RUN apk add --no-cache libc6-compat
COPY package.json package-lock.json ./
RUN npm ci
# Development
FROM base AS development
COPY --from=deps /app/node_modules ./node_modules
COPY . .
ENV NODE_ENV=development
ENV NEXT_TELEMETRY_DISABLED=1
EXPOSE 3000
CMD ["npm", "run", "dev"]
# Builder
FROM base AS builder
COPY --from=deps /app/node_modules ./node_modules
COPY . .
ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1
RUN npm run build
# Production
FROM base AS production
ENV NODE_ENV=production
ENV NEXT_TELEMETRY_DISABLED=1
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
USER nextjs
EXPOSE 3000
ENV PORT=3000
ENV HOSTNAME="0.0.0.0"
CMD ["node", "server.js"]

View File

@@ -1,28 +0,0 @@
services:
web:
build:
context: ..
dockerfile: docker/Dockerfile
target: development
ports:
- "3000:3000"
volumes:
- ..:/app
- /app/node_modules
- /app/.next
environment:
- NODE_ENV=development
- NEXT_TELEMETRY_DISABLED=1
restart: unless-stopped
# Production build (optional)
# web-prod:
# build:
# context: ..
# dockerfile: docker/Dockerfile
# target: production
# ports:
# - "3000:3000"
# environment:
# - NODE_ENV=production
# restart: unless-stopped

38
framework/FRAMEWORK.md Normal file
View File

@@ -0,0 +1,38 @@
# Framework
## Technologie-Stack
Die Website wird mit folgendem Stack entwickelt:
- **Framework**: Next.js (App Router)
- **Sprache**: TypeScript
- **Styling**: Tailwind CSS
- **Animation**: Framer Motion (optional)
- **Deployment**: Statisch exportierbar
## Ziel
Eine moderne, performante Website, die:
- Schnell lädt (optimierte Assets)
- SEO-freundlich ist
- Auf allen Geräten funktioniert
- Wartbar und erweiterbar bleibt
## Erlaubte Tools & Libraries
Die KI darf alle Tools verwenden, die zum Erreichen des Ziels sinnvoll sind, solange sie mit dem Hauptstack kompatibel bleiben. Dazu gehören beispielsweise:
- Icon-Libraries
- Bildoptimierung
- Fonts (müssen aber self hostet sein)
- Utility-Bibliotheken
## Was diese Datei NICHT enthält
- Keine konkreten Klassennamen
- Keine Layout-Vorgaben
- Keine Design Tokens
- Keine Komponenten-Definitionen
Die Implementierungsdetails sind vollständig der KI überlassen.

View File

@@ -1,33 +0,0 @@
name: CI
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [20.x]
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Setup Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- name: Install dependencies
run: npm ci
- name: Build
run: npm run build
env:
NODE_ENV: production

View File

@@ -1,4 +0,0 @@
{
"version": "1.0.0",
"entries": []
}

6
next-env.d.ts vendored
View File

@@ -1,6 +0,0 @@
/// <reference types="next" />
/// <reference types="next/image-types/global" />
/// <reference path="./.next/types/routes.d.ts" />
// NOTE: This file should not be edited
// see https://nextjs.org/docs/app/api-reference/config/typescript for more information.

View File

@@ -1,11 +0,0 @@
/** @type {import('next').NextConfig} */
const nextConfig = {
reactStrictMode: true,
poweredByHeader: false,
compress: true,
images: {
formats: ['image/avif', 'image/webp'],
},
};
module.exports = nextConfig;

1737
package-lock.json generated

File diff suppressed because it is too large Load Diff

View File

@@ -1,32 +0,0 @@
{
"name": "website-skeleton",
"version": "1.0.0",
"private": true,
"description": "Minimalist runtime skeleton for AI-generated websites",
"scripts": {
"dev": "next dev",
"build": "next build",
"start": "next start",
"lint": "next lint",
"clean": "rm -rf .next"
},
"dependencies": {
"next": "^15.1.0",
"react": "^19.0.0",
"react-dom": "^19.0.0",
"framer-motion": "^11.15.0",
"lenis": "^1.1.18",
"lucide-react": "^0.469.0"
},
"devDependencies": {
"@types/node": "^22.10.0",
"@types/react": "^19.0.0",
"@types/react-dom": "^19.0.0",
"typescript": "^5.7.0",
"tailwindcss": "^4.0.0",
"@tailwindcss/postcss": "^4.0.0"
},
"engines": {
"node": ">=20.0.0"
}
}

View File

@@ -1,7 +0,0 @@
const config = {
plugins: {
"@tailwindcss/postcss": {},
},
};
export default config;

View File

@@ -1,107 +1,83 @@
# Master Prompt
Anweisungen für die KI zur Website-Generierung.
## Anweisung an die KI
Du bist ein Senior Web Developer und Designer. Deine Aufgabe ist es, eine launch-ready Website zu erstellen.
---
## Kontext
## Schritt 1: Kontext verstehen
Du arbeitest mit einem minimalistischen Website-Skeleton. Dieses Repository enthält:
Lies alle Dateien in diesem Repository:
- Keine fertigen Layouts
- Keine UI-Komponenten
- Keine Design-Vorgaben
- `framework/FRAMEWORK.md` Technischer Stack
- `ai/SYSTEM_RULES.md` Harte Qualitätsregeln
- `ai/QUALITY_STANDARD.md` Definition von "fertig"
- `ai/AI_DECISION_LOGIC.md` Deine Entscheidungskompetenz
- `briefs/*.md` Der eigentliche Kundenauftrag
Alles muss von Grund auf neu erstellt werden.
Verstehe den Gesamtkontext, bevor du beginnst.
---
## Vor dem Start
## Schritt 2: Analyse
**Pflichtlektüre** (in dieser Reihenfolge):
Beantworte für dich selbst:
1. `/skills/SYSTEM_SKILLS.md` - Grundregeln
2. `/skills/UI_GUIDELINES.md` - Qualitätsstandards
3. `/skills/DEFINITION_OF_DONE.md` - Abnahmekriterien
4. `/spec/ProjectSpec.json` - Projektanforderungen
5. `/spec/design_tokens.json` - Design-System
- Wer ist der Kunde?
- Wer ist die Zielgruppe?
- Was soll die Website erreichen?
- Welche Stimmung soll sie vermitteln?
- Welche Inhalte sind vorhanden?
- Welche Constraints gelten?
---
## Workflow
## Schritt 3: Planung
### 1. Analyse
Entscheide selbstständig:
- ProjectSpec.json vollständig lesen und verstehen
- Design Tokens studieren
- Zielgruppe und Ziele identifizieren
- Technische Anforderungen erfassen
- Welche Seiten braucht die Website?
- Welche Sections auf jeder Seite?
- In welcher Reihenfolge?
- Welche Komponenten?
- Welches Layout?
### 2. Konzeption
- Seitenstruktur planen
- Komponenten identifizieren (keine vorgefertigten!)
- Responsive Breakpoints berücksichtigen
- Performance-Budget einplanen
### 3. Umsetzung
- Mobile-First entwickeln
- Semantisches HTML verwenden
- CSS Variables aus globals.css nutzen
- Tailwind für Utility-Klassen
- TypeScript strict mode
### 4. Qualitätssicherung
- Definition of Done prüfen
- Alle Breakpoints testen
- Accessibility validieren
- Performance messen
### 5. Dokumentation
- Änderungen in `generation_log.json` festhalten
- Entscheidungen dokumentieren
Dokumentiere deine Entscheidungen kurz, bevor du baust.
---
## Beispiel-Prompt für neue Website
## Schritt 4: Implementierung
```
Erstelle eine Website für [Kunde] basierend auf:
Baue die Website mit:
1. ProjectSpec.json wurde aktualisiert mit:
- Firmenname: [Name]
- Branche: [Branche]
- Zielgruppe: [Zielgruppe]
- Gewünschte Seiten: [Liste]
- Next.js App Router
- TypeScript
- Tailwind CSS
- Optional: Framer Motion für Animationen
2. design_tokens.json wurde aktualisiert mit:
- Primärfarbe: [Farbe]
- Schriftart: [Font]
- [weitere Anpassungen]
Bitte lies zuerst /skills und /spec vollständig.
```
Halte dich an die SYSTEM_RULES.
---
## Verbote (Wiederholung)
## Schritt 5: Selbstprüfung
- KEINE UI-Libraries
- KEINE Templates kopieren
- KEINE eigenmächtigen Design-Entscheidungen
- KEINE hardcodierten Werte
- KEIN Over-Engineering
Vor der Abgabe:
- [ ] Erfüllt die Website die QUALITY_STANDARD.md Kriterien?
- [ ] Sind alle SYSTEM_RULES eingehalten?
- [ ] Funktioniert `npm run build` ohne Fehler?
- [ ] Ist die Website responsive?
- [ ] Sind alle Inhalte aus den Briefs berücksichtigt?
---
## Ausgabe-Erwartung
## Wichtig
Nach erfolgreicher Generierung:
Du bist nicht nur Ausführer. Du bist Mitdenker.
- Lauffähige Website unter `npm run dev`
- Build erfolgreich unter `npm run build`
- Alle DoD-Kriterien erfüllt
- generation_log.json aktualisiert
Wenn etwas besser geht als beschrieben mache es besser.
Wenn etwas fehlt ergänze es sinnvoll.
Wenn etwas überflüssig ist lass es weg.
Baue keine generische Website. Baue *diese* Website.

View File

View File

@@ -1,152 +0,0 @@
# CLIENT_OVERRIDES (Project-Specific)
Kundenspezifische Ergänzungen. Diese Datei darf globale Skills nicht überschreiben.
---
## Scope
**Kunde:** TBD
**Marke:** TBD
**Branche:** TBD
**Geschäftsmodell:** TBD
**Kernleistung:** TBD
**Zielgruppe (primär):** TBD
**Zielgruppe (sekundär):** TBD
**Kundentyp:** TBD
**Region:** TBD
---
## Read Order
1. `skills/SYSTEM_SKILLS.md`
2. `skills/UI_GUIDELINES.md`
3. `skills/DEFINITION_OF_DONE.md`
4. `skills/CLIENT_OVERRIDES.md` ← diese Datei
5. `spec/project_spec.json`
---
## Non-Goals
Diese Datei definiert **NICHT**:
- Globale Arbeitsweisen (siehe SYSTEM_SKILLS.md)
- UI-Qualitätsstandards (siehe UI_GUIDELINES.md)
- Abnahmekriterien (siehe DEFINITION_OF_DONE.md)
- Konkrete Farbwerte, Layouts, Komponenten (kommen aus design_tokens.json)
---
## Brand Voice (Deutsch)
| Eigenschaft | Wert |
|-------------|------|
| Sprache | Deutsch |
| Ansprache | TBD |
| Formalität | TBD |
| Markenpersönlichkeit | TBD |
**USPs:**
- TBD
---
## Must-Haves
### Pflichtseiten
- TBD
### Pflichtinhalte
- TBD
### Pflicht-CTAs
| Label | Ziel | Priorität |
|-------|------|-----------|
| TBD | TBD | TBD |
---
## Must-Not-Haves
### Verbotene Inhalte
- TBD
### Verbotene Stilmittel
- TBD
### Verbotene Technologien
- TBD
---
## Content & SEO Notes
### SEO-Fokus-Keywords
- TBD
### GEO-Fokus
- TBD
### Content-Richtung
- TBD
---
## Legal (DACH)
### Impressum
- **Erforderlich:** Ja
- **Details:** TBD
### Datenschutzerklärung
- **Erforderlich:** Ja
- **Details:** TBD
### Zusätzliche rechtliche Hinweise
- TBD
---
## Assets & Links
### Logo
- **Verfügbar:** TBD
- **Pfad:** TBD
- **Format:** TBD
### Brand Guidelines
- **Verfügbar:** TBD
- **Pfad:** TBD
### Weitere Assets
- TBD
---
## References (Liked / Disliked)
### Gefällt (Inspiration)
| URL | Grund |
|-----|-------|
| TBD | TBD |
### Gefällt nicht (Abgrenzung)
| URL | Grund |
|-----|-------|
| TBD | TBD |
---
## Open Questions (TBD)
- TBD
- Kundenname und Kontaktperson klären
- Branche und Geschäftsmodell definieren
- Zielgruppe spezifizieren
- Tonalität festlegen (Du/Sie, formal/locker)
- Seitenstruktur und Prioritäten bestimmen
- CTAs und Conversion-Ziele definieren
- Rechtliche Daten für Impressum sammeln
- Assets (Logo, CI) bereitstellen
- Referenz-Websites sammeln

View File

@@ -1,430 +0,0 @@
# Definition of Done
Harte Abnahmekriterien. Eine Aufgabe gilt erst als abgeschlossen, wenn alle Kriterien erfüllt sind.
---
## Scope
Diese Datei definiert **verbindliche Abnahmekriterien** für:
- Build und Deployment
- Code-Qualität
- Responsive Design
- Accessibility
- SEO
- Projektspezifikation
- **9 Parameter-Kategorien (AJ)**
**Geltungsbereich:** Gilt global für jedes Projekt. Keine Aufgabe ist fertig, bis diese Checkliste erfüllt ist.
---
## Read Order
Diese Datei wird nach den anderen Skills gelesen:
1. `skills/SYSTEM_SKILLS.md`
2. `skills/UI_GUIDELINES.md`
3. `skills/DEFINITION_OF_DONE.md` (diese Datei)
4. `skills/CLIENT_OVERRIDES.md`
Die Definition of Done ist die finale Prüfinstanz vor Abschluss einer Aufgabe.
---
## Non-Goals
Diese Datei definiert **NICHT**:
- Wie das Design aussehen soll
- Welche Farben oder Layouts verwendet werden
- Konkrete UI-Vorgaben
- Wie Code strukturiert sein soll (siehe SYSTEM_SKILLS.md)
Diese Datei prüft nur, ob Qualitätsstandards eingehalten wurden.
---
## Kategorie A — Unternehmensidentität
### Pflicht
- [ ] Client-Name erscheint im Seitentitel
- [ ] Client-Name erscheint im Footer
- [ ] Client-Name erscheint im Impressum
- [ ] `lang`-Attribut entspricht dem definierten Locale (z.B. `de`, `de-AT`, `en`)
- [ ] Standort korrekt im Footer/Kontaktbereich dargestellt (falls definiert)
- [ ] Kontaktdaten korrekt dargestellt (falls definiert)
---
## Kategorie B — Zielgruppe
### Pflicht
- [ ] Content ist auf das Wissensniveau der Zielgruppe abgestimmt
- [ ] Typische Einwände werden auf Überzeugungsseiten adressiert (falls definiert)
- [ ] Hauptprobleme der Zielgruppe werden in Hero/Intro angesprochen (falls definiert)
- [ ] Sprachniveau passt zum definierten Entscheidertyp
### Bei Zielgruppen-spezifischen Inhalten
- [ ] Fachbegriffe erklärt (wenn Zielgruppe = Laien)
- [ ] Fachbegriffe verwendet (wenn Zielgruppe = Experten)
---
## Kategorie C — Kommunikation
### Pflicht
- [ ] Ansprache (du/sie) ist konsistent auf ALLEN Seiten
- [ ] Ansprache ist konsistent in ALLEN UI-Elementen (Buttons, Labels, Microcopy)
- [ ] Tonalität entspricht den definierten `baseTone`-Werten
- [ ] Schreibstil entspricht den definierten `writingStyle`-Werten
- [ ] Emotionales Gefühl spiegelt sich im Gesamtdesign wider
### Konsistenz-Check
```
[ ] Alle Buttons mit korrekter Ansprache?
[ ] Alle Formular-Labels mit korrekter Ansprache?
[ ] Alle Microcopy-Elemente mit korrekter Ansprache?
[ ] Keine Mischung von Du und Sie?
```
---
## Kategorie D — Angebot
### Pflicht
- [ ] Alle definierten Leistungen sind auf der Website dargestellt
- [ ] Jede Leistung hat Titel
- [ ] Jede Leistung hat Beschreibung
- [ ] Jede Leistung hat Nutzen-Kommunikation (falls definiert)
- [ ] Angebotstyp bestimmt das Layout:
- Dienstleistung → Services-Grid oder Liste
- Produkt → Produkt-Karten
- Beratung → Prozess-Darstellung
---
## Kategorie E — Seitenarchitektur
### Pflicht
- [ ] Alle definierten Seiten existieren als Routes unter `app/`
- [ ] Jede Seite erfüllt ihren definierten Zweck:
- `informieren`: Fakten-First, klare Struktur, CTAs dezent
- `ueberzeugen`: USPs prominent, Social Proof, Argumentation
- `konvertieren`: CTAs above-the-fold, Trust-Elemente, Einwand-Behandlung
- [ ] Seiten mit Priorität `hoch` sind am detailliertesten umgesetzt
- [ ] Navigation enthält alle Seiten in logischer Reihenfolge
- [ ] Interne Verlinkungswünsche umgesetzt (falls definiert)
### Seiten-Zweck-Check
| Seite | Purpose | Priority | Umgesetzt |
|-------|---------|----------|-----------|
| (aus Spec) | (aus Spec) | (aus Spec) | [ ] |
---
## Kategorie F — Marke & Stil
### Pflicht
- [ ] Alle Farben kommen aus Design-Tokens (`globals.css`)
- [ ] Keine hardcodierten Hex/RGB-Werte im Code
- [ ] Heading-Font entspricht `brand.fonts.heading.family`
- [ ] Body-Font entspricht `brand.fonts.body.family`
- [ ] Visueller Stil entspricht den Stil-Adjektiven
- [ ] **Keines der Stil-Verbote wurde verletzt**
### Stil-Check
```
[ ] Passt jedes UI-Element zu den Stil-Adjektiven?
[ ] Verstößt kein Element gegen die Stil-Verbote?
[ ] Logo korrekt eingebunden (falls vorhanden)?
```
---
## Kategorie G — UX & Interaktion
### Pflicht
- [ ] Interaktionsniveau entspricht dem definierten Level (`ruhig`/`moderat`/`dynamisch`)
- [ ] Animations-Level ist korrekt (`keine`/`dezent`/`praesent`)
- [ ] Scroll-Verhalten ist korrekt konfiguriert (`normal`/`smooth`)
### Level-spezifische Checks
**Bei `ruhig`:**
- [ ] Keine framer-motion Animationen vorhanden
- [ ] Kein Parallax
- [ ] Maximal 1 CTA pro Viewport
- [ ] Große Whitespace-Blöcke
**Bei `moderat`:**
- [ ] Nur dezente Fade-In Animationen
- [ ] Subtile Hover-Effekte
- [ ] framer-motion sparsam eingesetzt
**Bei `dynamisch`:**
- [ ] Scroll-Animationen vorhanden
- [ ] Micro-Interactions implementiert
- [ ] framer-motion aktiv eingesetzt
---
## Kategorie H — Conversion
### Pflicht
- [ ] Primärer CTA-Text korrekt implementiert
- [ ] Primärer CTA-Ziel korrekt verlinkt
- [ ] Sekundärer CTA-Text korrekt implementiert (falls definiert)
- [ ] Sekundärer CTA-Ziel korrekt verlinkt (falls definiert)
### Kontaktmethoden
- [ ] `formular`: Kontaktformular auf Kontaktseite vorhanden
- [ ] `telefon`: Telefonnummer im Header sichtbar
- [ ] `buchung`: Buchungstool-Embed vorhanden (oder Platzhalter)
### Vertrauenselemente
- [ ] `bewertungen`: Bewertungs-Widgets oder Zitat-Karten platziert
- [ ] `zertifikate`: Logo-Leiste mit Zertifizierungen vorhanden
- [ ] `referenzen`: Kundenlogos oder Case-Studies eingebunden
- [ ] `community`: Mitglieder-Zahlen oder Social-Feeds vorhanden
### Conversion-Seiten-Check
- [ ] Konvertierungsseiten haben prominente CTAs above-the-fold
- [ ] Trust-Section direkt unter Hero auf Conversion-Seiten
- [ ] Einwand-Entkräftung vor Kontaktformular
---
## Kategorie I — Technik & Recht
### Impressum
- [ ] Impressum-Seite unter `/impressum` vorhanden
- [ ] `companyName` korrekt
- [ ] `street` korrekt
- [ ] `postalCode` + `city` korrekt
- [ ] `country` korrekt
- [ ] `email` korrekt
- [ ] `phone` korrekt (falls definiert)
- [ ] `vatId` korrekt (falls definiert)
- [ ] `register` korrekt (falls definiert)
### Datenschutz
- [ ] Datenschutz-Seite unter `/datenschutz` vorhanden
- [ ] Cookie-Hinweis enthalten
- [ ] Hosting-Info enthalten (aus `spec.technical.hosting`)
- [ ] Analytics-Angabe enthalten (aus `spec.technical.tracking`)
### Integrationen
- [ ] Newsletter-Integration vorhanden (wenn `newsletter: true`)
- [ ] Newsletter-Signup im Footer
- [ ] Buchungstool-Embed vorhanden (wenn `bookingTool` definiert)
- [ ] Externe Integrationen als TODO-Kommentare markiert
---
## Kategorie J — KI-Kontext
### Pflicht
- [ ] `whatIsImportant` wurde bei JEDER Designentscheidung berücksichtigt
- [ ] `whatToAvoid` wurde nirgendwo verletzt
- [ ] Positive Referenzen wurden als Inspiration erkennbar einbezogen (falls definiert)
- [ ] Negative Referenzen wurden bewusst vermieden (falls definiert)
### KI-Kontext-Check
```
[ ] Was ist besonders wichtig? → Umgesetzt?
[ ] Was darf auf keinen Fall passieren? → Vermieden?
[ ] Bei Konflikten: Kat. J priorisiert?
```
---
## Build & Deployment
### Pflicht
- [ ] `npm run build` erfolgreich ohne Fehler
- [ ] Keine TypeScript-Fehler
- [ ] Keine ESLint-Fehler (Warnungen dokumentieren falls unvermeidbar)
- [ ] Keine Runtime-Errors in der Console
### Bei Fehlern
Build-Fehler müssen vor Abschluss behoben werden. Keine Ausnahmen.
---
## Code-Qualität
### Pflicht
- [ ] Keine `any` Types in TypeScript
- [ ] Keine auskommentierten Code-Blöcke
- [ ] Keine `console.log` im Production-Code
- [ ] Konsistente Namenskonventionen
- [ ] Keine ungenutzten Imports oder Variablen
- [ ] Keine Dead Code (ungenutzte Funktionen/Komponenten)
### Abhängigkeiten
- [ ] Keine ungenutzten Dependencies in `package.json`
- [ ] Keine Sicherheitslücken in Dependencies (soweit bekannt)
---
## Responsive Design
### Pflichtprüfung
| Viewport | Bereich | Status |
|----------|---------|--------|
| Mobile | 320px - 767px | [ ] geprüft |
| Tablet | 768px - 1023px | [ ] geprüft |
| Desktop | 1024px+ | [ ] geprüft |
### Kriterien
- [ ] Keine horizontalen Scrollbars auf keinem Viewport
- [ ] Keine abgeschnittenen oder überlagernden Inhalte
- [ ] Touch-Targets mindestens 44x44px auf Touch-Geräten
- [ ] Lesbare Schriftgrößen ohne Zoom
---
## Accessibility
### Pflicht
- [ ] Kontrast WCAG AA erfüllt (4.5:1 Text, 3:1 UI-Elemente)
- [ ] Tastatur-Navigation funktioniert vollständig
- [ ] Fokus-Indikatoren sind sichtbar
- [ ] Semantisches HTML verwendet (keine `<div>` statt `<button>`)
- [ ] Alt-Texte für alle informativen Bilder
- [ ] Formular-Labels vorhanden und verknüpft
### Bei Ausnahmen
Kontrast-Ausnahmen müssen dokumentiert und begründet werden. Es muss ein Plan zur Behebung existieren.
---
## SEO Mindeststandard
### Pflicht pro Seite
- [ ] Eindeutiger `<title>` vorhanden
- [ ] Meta-Description vorhanden
- [ ] Korrekte Heading-Hierarchie (nur ein `h1`, dann `h2` > `h3`)
- [ ] Open Graph Tags gesetzt
- [ ] Alt-Texte für Bilder
### Pflicht global
- [ ] `robots.txt` vorhanden
- [ ] Canonical URLs gesetzt (falls relevant)
- [ ] Keine Blocking-Resources für Crawler
---
## Performance
### Pflicht
- [ ] Bilder optimiert (WebP/AVIF, responsive srcset)
- [ ] Lazy Loading für Below-the-fold-Inhalte
- [ ] Keine unnötigen Dependencies
- [ ] Bundle-Größe im Budget (JS < 100kb gzip, CSS < 30kb gzip)
### Empfohlen
- [ ] Core Web Vitals im grünen Bereich (LCP < 2.5s, CLS < 0.1, INP < 200ms)
---
## Browser-Kompatibilität
Unterstützte Browser (letzte 2 Major-Versionen):
- [ ] Chrome
- [ ] Firefox
- [ ] Safari
- [ ] Edge
Bei bekannten Inkompatibilitäten: dokumentieren und Workaround bereitstellen.
---
## Projektspezifikation
### Pflicht
- [ ] Alle Anforderungen aus `ProjectSpec.json` umgesetzt
- [ ] Design entspricht `design_tokens.json` und `stylesheet.css`
- [ ] Keine eigenmächtigen Design-Entscheidungen
- [ ] CLIENT_OVERRIDES.md berücksichtigt (falls vorhanden)
### Dokumentation
- [ ] Änderungen in `generation_log.json` maschinell dokumentiert
---
## Schnell-Checkliste
Vor Abschluss jeder Aufgabe durchgehen:
```
[ ] 1. npm run build erfolgreich?
[ ] 2. Mobile (320px) geprüft?
[ ] 3. Tablet (768px) geprüft?
[ ] 4. Desktop (1024px+) geprüft?
[ ] 5. Kontrast WCAG AA erfüllt?
[ ] 6. Tastatur-Navigation funktioniert?
[ ] 7. SEO-Basics vorhanden (title, description, h1)?
[ ] 8. Anforderungen aus ProjectSpec erfüllt?
[ ] 9. Kein Dead Code oder ungenutzte Dependencies?
[ ] 10. generation_log.json aktualisiert?
```
### Kategorie-Schnellcheck
```
[ ] A. Unternehmensidentität korrekt?
[ ] B. Zielgruppe berücksichtigt?
[ ] C. Ansprache konsistent?
[ ] D. Alle Leistungen dargestellt?
[ ] E. Alle Seiten mit richtigem Purpose?
[ ] F. Stil-Adjektive eingehalten, Verbote vermieden?
[ ] G. Interaktionsniveau korrekt?
[ ] H. CTAs und Trust-Elemente platziert?
[ ] I. Impressum und Datenschutz vollständig?
[ ] J. KI-Kontext beachtet?
```
---
## Zusammenfassung
> Erst wenn alle Checkboxen erfüllt sind, gilt eine Aufgabe als erledigt.
> Keine Ausnahmen ohne explizite Dokumentation und Begründung.
> Build-Fehler sind Blocker. Accessibility-Verstöße sind Blocker.
> KI-Kontext-Verstöße (Kat. J `whatToAvoid`) sind Blocker.

View File

@@ -1,479 +0,0 @@
# System Skills
Verbindliche Regeln für die KI-gestützte Website-Generierung im Agentur-Kontext.
---
## Scope
Diese Datei definiert den **harten Rahmen** für:
- Arbeitsweise und Workflow
- Code-Qualität und Repo-Konventionen
- Source of Truth für Design und Anforderungen
- Verbote und Pflichten
**Geltungsbereich:** Gilt global für jedes Projekt. CLIENT_OVERRIDES.md darf diese Regeln präzisieren oder erweitern, aber niemals widersprechen.
---
## Read Order
Die KI muss Dateien in folgender Reihenfolge lesen:
1. `skills/SYSTEM_SKILLS.md` (diese Datei)
2. `skills/UI_GUIDELINES.md`
3. `skills/DEFINITION_OF_DONE.md`
4. `skills/CLIENT_OVERRIDES.md` (falls vorhanden)
5. `spec/ProjectSpec.json`
6. `spec/design_tokens.json`
7. `theme/stylesheet.css` / `theme/globals.css`
Bei Konflikten gilt: **Globale Skills > Client Overrides**
---
## Non-Goals
Diese Datei definiert **NICHT**:
- Konkrete Design-Vorgaben (Farben, Layouts, Abstände)
- UI-Templates oder vorgefertigte Komponenten
- Visuelle Entscheidungen jeglicher Art
- Landingpage-Strukturen oder Section-Vorlagen
Design entsteht ausschließlich aus den Projekt-Specs, nicht aus diesen Skills.
---
## Parameter-Interpreter-Modus
Das System arbeitet mit **9 strukturierten Parameter-Kategorien (AJ)**. Diese Kategorien sind in `CLIENT_OVERRIDES.md` und `master_prompt.md` vollständig aufbereitet.
### Die 9 Kategorien
| Kat. | Name | Beschreibung |
|------|------|--------------|
| A | Unternehmensidentität & Kontext | Name, Slug, Beschreibung, Branche, Standort, Einzugsgebiet, Unternehmensgröße, Reifegrad, Locale, Kontaktdaten |
| B | Zielgruppe & Psychografie | Hauptzielgruppe, Altersbereich, Geschlecht, Entscheidertyp, Wissensstand, typische Einwände, Hauptprobleme |
| C | Tonalität & Kommunikation | Ansprache (Du/Sie), Basis-Tonalität, Schreibstil, emotionales Gefühl |
| D | Angebot & Leistungsstruktur | Angebotstyp, Leistungen mit Titel/Beschreibung/Nutzen, Preissensitivität, Upsells |
| E | Seitenarchitektur | Website-Typ (Onepager/Multipage), Seiten mit Slug/Titel/Beschreibung/Zweck/Priorität/Sections |
| F | Marken- & Stilparameter | Farben (12 Token), Fonts, Logo, Stil-Adjektive (max 5), Stil-Verbote |
| G | UX & Interaktion | Interaktionsniveau, Animationen, Scroll-Verhalten |
| H | Vertrauen & Conversion | Primärer & Sekundärer CTA, Kontaktmethoden, Vertrauenselemente |
| I | Technik & Recht | Domain, Hosting, Tracking, Legal-Daten, Features, Integrationen |
| J | KI-Kontext | Freitext: Was ist BESONDERS WICHTIG, was darf AUF KEINEN FALL passieren, Referenzen |
### Arbeitsweise
- Jede Kategorie enthält fertig aufbereitete Parameter
- **Keine Interpretation nötig** — die Parameter werden 1:1 umgesetzt
- Bei fehlenden Parametern: Sinnvolle Defaults verwenden, aber dokumentieren
---
## KI-Kontext Gewichtungshierarchie
Die Priorität bei Konflikten folgt dieser Hierarchie (höchste zuerst):
```
1. SYSTEM_SKILLS.md
2. UI_GUIDELINES.md
3. DEFINITION_OF_DONE.md
4. KI-KONTEXT (Kategorie J)
5. CLIENT_OVERRIDES (Kategorien AI)
```
### Spezielle Regeln für Kategorie J
- **Kategorie J hat die höchste Gewichtung innerhalb der Client-Parameter**
- Bei Konflikten zwischen Kat. J und Kat. AI: **Kat. J gewinnt**
- Bei Konflikten zwischen Kat. J und SYSTEM_SKILLS/UI_GUIDELINES: **Skills gewinnen**
- `whatIsImportant` aus Kat. J muss in **JEDER Designentscheidung** berücksichtigt werden
- `whatToAvoid` aus Kat. J sind **harte Verbote** — keine Ausnahmen
### Beispiel
Wenn Kat. J sagt "Keine Animationen" und Kat. G sagt "Interaktionsniveau: dynamisch", dann gilt: **Keine Animationen**.
---
## Seiten-Zweck-System
Jede Seite in Kat. E hat einen definierten `purpose` und eine `priority`.
### Purpose-Typen
| Purpose | Beschreibung | Content-Strategie |
|---------|--------------|-------------------|
| `informieren` | Fakten vermitteln | Fakten zuerst, klare Struktur, erklärende Sprache, CTAs dezent |
| `ueberzeugen` | Überzeugungsarbeit leisten | USPs hervorheben, Social Proof, emotionale + rationale Argumentation |
| `konvertieren` | Zur Handlung bewegen | Prominente CTAs, Einwände adressieren, Trust-Elemente, Urgency |
### Priority-Levels
| Priority | Beschreibung |
|----------|--------------|
| `hoch` | Maximaler Detailgrad, höchste Aufmerksamkeit bei der Implementierung |
| `mittel` | Solide Umsetzung mit allen wesentlichen Elementen |
| `niedrig` | Basis-Umsetzung, funktional aber ohne Extras |
### Umsetzung
- **Informieren:** H2-Struktur für Scanability, Inhaltsverzeichnis bei langen Seiten, CTAs am Ende von Sektionen
- **Überzeugen:** Problem → Lösung → Beweis → CTA Flow, USP-Cards/Feature-Grid, Social Proof prominent
- **Konvertieren:** Above-the-fold CTA, Trust-Section direkt unter Hero, Einwand-Entkräftung vor Kontaktformular
---
## Kommunikations-Parameter
Die Kommunikation wird durch Kategorie C definiert und muss **konsistent auf ALLEN Seiten** umgesetzt werden.
### Ansprache (address)
| Wert | Verwendung | Beispiel |
|------|------------|----------|
| `du` | Informelle Ansprache | "Schick uns eine Nachricht", "Dein Name" |
| `sie` | Formelle Ansprache | "Senden Sie uns eine Nachricht", "Ihr Name" |
**Pflicht:** Die gewählte Ansprache gilt für:
- Alle Fließtexte
- Alle Button-Labels
- Alle Formular-Labels und Placeholders
- Alle Microcopy-Elemente
- Alle CTAs
### Tonalität (baseTone)
| Wert | Beschreibung |
|------|--------------|
| `sachlich` | Neutral, faktenbasiert, nüchtern |
| `freundlich` | Warm, einladend, zugänglich |
| `beratend` | Kompetent, hilfsbereit, lösungsorientiert |
| `motivierend` | Energetisch, inspirierend, aktivierend |
| `exklusiv` | Premium, distinguiert, hochwertig |
### Schreibstil (writingStyle)
| Wert | Beschreibung |
|------|--------------|
| `kurz_praegnant` | Kurze Sätze, auf den Punkt, keine Füllwörter |
| `erklaerend` | Ausführlicher, didaktisch, schrittweise |
| `emotional` | Gefühlsbetont, storytelling, persönlich |
| `technisch` | Fachsprachlich, präzise, detailliert |
### Emotionales Gefühl (emotionalFeeling)
Beschreibt das gewünschte Gesamtgefühl der Website (z.B. "vertrauenswürdig und modern", "dynamisch und innovativ"). Muss sich im Gesamtdesign widerspiegeln.
---
## Vertrauens- & Conversion-Elemente
Kategorie H definiert, wie Vertrauen aufgebaut und Conversions erzielt werden.
### Vertrauenselemente (trustElements)
| Element | Implementierung |
|---------|-----------------|
| `bewertungen` | Google/Trustpilot-Widgets oder Zitat-Karten mit Sternebewertung |
| `zertifikate` | Logo-Leiste mit Zertifizierungen (TÜV, ISO, etc.) |
| `referenzen` | Kundenlogos oder Case-Study-Snippets |
| `community` | Mitglieder-Zahlen, Social-Media-Feeds, Follower-Counts |
### Kontaktmethoden (contactMethods)
| Methode | Implementierung |
|---------|-----------------|
| `formular` | Kontaktformular prominent auf Kontaktseite, ggf. auch in Footer |
| `telefon` | Telefonnummer im Header + sticky CTA auf Mobile |
| `buchung` | Buchungstool-Integration (z.B. Calendly-Embed) auf Kontaktseite |
### CTA-Implementierung
- **Primärer CTA:** Haupthandlungsaufforderung, prominent platziert (Hero, Header, Sticky)
- **Sekundärer CTA:** Alternative Handlung, weniger prominent aber sichtbar
---
## Interaktions-Level
Kategorie G definiert das Interaktionsniveau der Website.
### Level-Definitionen
| Level | Beschreibung | Regeln |
|-------|--------------|--------|
| `ruhig` | Maximale visuelle Ruhe | Keine Animationen, kein Parallax, statisches Layout, **framer-motion NICHT verwenden**, maximal 1 CTA pro Viewport |
| `moderat` | Ausgewogenes Layout | Dezente Fade-In Animationen, subtile Hover-Effekte, **framer-motion sparsam einsetzen**, IntersectionObserver-basierte Reveals |
| `dynamisch` | Lebendige Interaktion | Scroll-Animationen, Parallax erlaubt, Micro-Interactions, **framer-motion aktiv eingesetzt**, Sticky CTAs |
### Animations-Einstellung (animations)
| Wert | Beschreibung |
|------|--------------|
| `keine` | Absolut keine Animationen, auch keine Hover-Transitions |
| `dezent` | Nur subtile Transitions (opacity, transform), max. 300ms |
| `praesent` | Auffälligere Animationen, Scroll-triggered, Stagger-Effekte |
### Scroll-Verhalten (scrollBehavior)
| Wert | CSS-Umsetzung |
|------|---------------|
| `normal` | `scroll-behavior: auto` |
| `smooth` | `scroll-behavior: smooth` (auf `html` Element) |
---
## Integrationen
Kategorie I definiert technische Integrationen.
### Newsletter
Wenn `newsletter: true`:
- Newsletter-Signup-Formular im Footer
- Dedizierte Section auf der Startseite (optional)
- Platzhalter für Newsletter-Provider (Mailchimp, etc.)
### Buchungstool
Wenn `bookingTool` gesetzt:
- Als iframe/embed auf der Kontaktseite einbinden
- Platzhalter-Embed wenn kein konkreter Anbieter angegeben:
```html
<!-- TODO: Buchungstool-Integration hier einfügen -->
<div class="booking-placeholder">Buchungstool wird hier eingebunden</div>
```
### Externe Integrationen
Externe Integrationen als Platzhalter-Kommentare im Code markieren:
```typescript
// TODO: Integration ${name} - ${description}
```
---
## Impressum & Datenschutz
### Impressum
Legal-Daten kommen aus `spec.technical.legal.impressum` mit folgender Struktur:
```json
{
"companyName": "Firmenname GmbH",
"street": "Musterstraße 1",
"postalCode": "12345",
"city": "Musterstadt",
"country": "Deutschland",
"email": "info@example.com",
"phone": "+49 123 456789",
"vatId": "DE123456789",
"register": "HRB 12345, Amtsgericht Musterstadt"
}
```
**Pflicht:** Die KI generiert aus diesen Daten automatisch eine korrekte Impressum-Seite gemäß DACH-Recht.
### Datenschutz
Datenschutz-Seite enthält mindestens:
- Cookie-Hinweis
- Hosting-Info (aus `spec.technical.hosting`)
- Analytics-Angabe (aus `spec.technical.tracking`)
- Kontaktdaten des Verantwortlichen
- Hinweis auf Rechte der Betroffenen
---
## Research-Insights Nutzung
Die `llmResearch`-Daten im ProjectSpec enthalten wertvolle Insights.
### Verfügbare Research-Daten
| Feld | Verwendung |
|------|------------|
| `audienceAnalysis` | Bei Content-Erstellung für Kat. B berücksichtigen |
| `uxRecommendations` | Bei Layout-Entscheidungen berücksichtigen |
| `conversionStrategy` | Bei CTA-Platzierung und Funnel-Design berücksichtigen |
| `suggestedUSPs` | Auf Startseite und Überzeugungsseiten prominent platzieren |
### Umsetzung
- USPs aus `suggestedUSPs` als Feature-Cards oder Hero-Bullet-Points
- `conversionStrategy` bestimmt den Aufbau von Conversion-Seiten
- `uxRecommendations` fließen in Layout-Entscheidungen ein
---
## Source of Truth
Das Design und die Anforderungen einer Website basieren ausschließlich auf:
| Quelle | Inhalt |
|--------|--------|
| `spec/ProjectSpec.json` | Projektanforderungen, Ziele, Inhalte |
| `spec/design_tokens.json` | Farben, Typografie, Spacing-System |
| `theme/stylesheet.css` | Projektspezifische Styles |
| `theme/globals.css` | Globale CSS-Variablen und Resets |
**Regel:** Keine Design-Entscheidung ohne Grundlage in diesen Quellen.
---
## Verbote
### Absolut verboten:
- **KEINE** Templates oder vorgefertigten Layouts
- **KEINE** Copy-Paste-Strukturen aus anderen Projekten
- **KEINE** Boilerplate-Landingpages
- **KEINE** Standard-Hero/Feature/CTA-Sections ohne Spec-Grundlage
- **KEINE** eigenmächtigen Design-Entscheidungen
- **KEINE** hardcodierten Farben, Größen oder Abstände
- **KEINE** UI-Libraries (shadcn, MUI, Chakra, Radix, etc.)
- **KEINE** CSS-Frameworks außer Tailwind (falls im Projekt konfiguriert)
- **KEINE** inline Styles (außer dynamische Werte)
- **KEINE** `!important` (außer dokumentierte Ausnahmen)
- **KEINE** Secrets im Repository (nur .env, .env.local)
### Daten und Secrets:
- Sensible Daten gehören in `.env` / `.env.local`
- `.env*` Dateien sind in `.gitignore`
- API-Keys, Passwörter, Tokens niemals committen
---
## Arbeitsprozess
Jede Aufgabe folgt diesem Ablauf:
### 1. Lesen
- `/skills` vollständig lesen
- `/spec` vollständig lesen
- Bestehenden Code verstehen
### 2. Planen
- Anforderungen analysieren
- Struktur und Komponenten konzipieren
- Abhängigkeiten identifizieren
### 3. Implementieren
- Code schreiben
- Design-Tokens verwenden
- Keine eigenmächtigen Entscheidungen
### 4. Self-Check
- `npm run build` ausführen
- Gegen Definition of Done validieren
- Responsive und Accessibility prüfen
### 5. Dokumentieren
- Änderungen in `generation_log.json` maschinell festhalten
- Keine manuellen Einträge im Log
---
## Coding-Standards
### TypeScript
- **Strict Mode** ist Pflicht
- Keine `any` Types
- Explizite Typdefinitionen für Props und State
- Keine Type-Assertions ohne Notwendigkeit
- Strict null checks beachten
```typescript
// Korrekt
interface ComponentProps {
title: string;
items: ReadonlyArray<Item>;
onSelect?: (item: Item) => void;
}
// Falsch
const props: any = { ... }
```
### React / Next.js
- Funktionale Komponenten
- Server Components wo möglich
- Client Components nur wenn nötig (`"use client"`)
- Keine unnötigen `useEffect` / `useState`
- Keine Over-Abstraktionen
### CSS
- CSS-Variablen aus `globals.css` verwenden
- Tailwind für Utility-Klassen (falls konfiguriert)
- Eigene Klassen für wiederverwendbare Patterns
- Mobile-first Breakpoints
```css
.element {
color: var(--color-foreground);
padding: var(--spacing-md);
}
```
### Allgemein
- Lesbarkeit > Cleverness
- Keine unnötigen Abstraktionen
- Keine Over-Engineering
- Konsistente Namenskonventionen
- Keine auskommentierten Code-Blöcke
- Keine `console.log` im Production-Code
---
## Pflichten
### Performance
- Core Web Vitals optimieren
- Lazy Loading für Below-the-fold-Inhalte
- Kritisches CSS inline
- JavaScript-Bundle minimieren
- Fonts optimieren (`display: swap`)
- Bildformate: WebP/AVIF bevorzugen
- Keine unnötigen Dependencies
### SEO
- Semantisches HTML (`header`, `main`, `nav`, `article`, `section`, `footer`)
- Korrekte Heading-Hierarchie (`h1` > `h2` > `h3`)
- Meta-Tags (`title`, `description`)
- Open Graph Tags
- Alt-Texte für alle Bilder
- Strukturierte Daten wo sinnvoll
### Mobile-First
- Responsive Design ist Pflicht
- Touch-Targets mindestens 44x44px
- Keine horizontalen Scrollbars
- Lesbare Schriftgrößen ohne Zoom
---
## Logging
### generation_log.json
- Nur maschinell befüllen
- Keine manuellen Einträge
- Dokumentiert: was wurde generiert, wann, welche Dateien
- Dient der Nachvollziehbarkeit
---
## Zusammenfassung
> Jede Website ist einzigartig. Design kommt aus den Specs, nicht aus dem Bauch.
> Code ist sauber, typisiert und wartbar. Build muss laufen.
> Diese Regeln sind nicht verhandelbar.

View File

@@ -1,501 +0,0 @@
# UI Guidelines
Qualitätsregeln für Benutzeroberflächen. Keine Designvorgaben.
---
## Scope
Diese Datei definiert **Qualitätsanforderungen** für:
- Accessibility (Barrierefreiheit)
- Responsive Design (Mobile-First)
- Performance-Budgets
- SEO-Grundlagen
- GEO/AI-Search-Optimierung
- Interaktionsqualität
**Geltungsbereich:** Gilt global für jedes Projekt. Definiert WIE UI gebaut wird, nicht WIE sie aussieht.
---
## Read Order
Diese Datei wird nach `SYSTEM_SKILLS.md` gelesen:
1. `skills/SYSTEM_SKILLS.md`
2. `skills/UI_GUIDELINES.md` (diese Datei)
3. `skills/DEFINITION_OF_DONE.md`
4. `skills/CLIENT_OVERRIDES.md`
5. Projekt-Specs
---
## Non-Goals
Diese Datei definiert **NICHT**:
- Welche Farben verwendet werden (kommt aus Tokens)
- Welche Schriftarten verwendet werden (kommt aus Tokens)
- Welche Layouts oder Sections erstellt werden (kommt aus ProjectSpec)
- Konkrete visuelle Gestaltung
- UI-Templates oder Komponenten-Vorlagen
**Regel:** Alle visuellen Entscheidungen kommen aus `design_tokens.json` und `stylesheet.css`.
---
## Stil-Adjektive & Stil-Verbote
Die visuellen Grundprinzipien werden durch Kategorie F definiert.
### Stil-Adjektive (styleAdjectives)
Maximal 5 Wörter, die den visuellen Charakter definieren (z.B. "modern", "sportlich", "seriös", "elegant", "minimalistisch").
**Pflicht:** Bei JEDER visuellen Entscheidung prüfen:
- Passt diese Entscheidung zu den definierten Adjektiven?
- Verstärkt sie den gewünschten Charakter?
### Stil-Verbote (styleProhibitions)
Definieren No-Gos (z.B. "verspielt", "comic", "laut", "kitschig").
**Pflicht:** Keine Designentscheidung darf gegen ein Stil-Verbot verstoßen.
### Prüfschema
Vor jeder UI-Entscheidung:
1. ✓ Passt es zu den Stil-Adjektiven?
2. ✓ Verstößt es gegen kein Stil-Verbot?
3. ✓ Ist es konsistent mit bisherigen Entscheidungen?
---
## Adaptive Layout-Regeln nach Interaktionsniveau
Das Layout passt sich dem definierten Interaktionsniveau aus Kategorie G an.
### Level: ruhig
- Maximale visuelle Ruhe
- Große Whitespace-Blöcke (min. `--spacing-2xl` zwischen Sections)
- Keine Animationen
- Maximal 1 CTA pro Viewport
- Keine Sticky-Elemente außer minimaler Header
- Klare vertikale Rhythmik
- Keine Parallax-Effekte
### Level: moderat
- Ausgewogenes Layout
- Dezente Hover-Effekte (opacity, subtle scale)
- IntersectionObserver-basierte Fade-Ins
- Moderate Whitespace (`--spacing-xl` bis `--spacing-2xl`)
- CTAs dürfen wiederholt werden, aber nicht aufdringlich
- Subtile Scroll-Progress-Indikatoren erlaubt
### Level: dynamisch
- Scroll-triggered Animationen erlaubt
- Parallax-Effekte möglich
- Interaktive Elemente (Hover-Reveals, Micro-Interactions)
- Sticky CTAs auf Mobile
- Stagger-Animationen für Listen
- Visuelle Überraschungsmomente erlaubt
---
## Conversion-optimiertes Layout
Das Layout richtet sich nach dem Seiten-Zweck aus Kategorie E.
### Seiten mit purpose: konvertieren
```
┌─────────────────────────────────────┐
│ Hero mit primärem CTA above-the-fold │
├─────────────────────────────────────┤
│ Trust-Section (direkt unter Hero) │
│ - Bewertungen, Zertifikate, Logos │
├─────────────────────────────────────┤
│ Nutzen / USPs │
├─────────────────────────────────────┤
│ Einwand-Entkräftung │
│ - FAQ oder "Häufige Fragen" │
├─────────────────────────────────────┤
│ Kontaktformular / Buchung │
│ - Mit sekundärem CTA │
└─────────────────────────────────────┘
```
- Above-the-fold CTA mit primärer Handlungsaufforderung
- Trust-Section direkt unter dem Hero
- Einwand-Entkräftung vor dem Kontaktformular
- Sticky CTA-Bar auf Mobile
### Seiten mit purpose: informieren
```
┌─────────────────────────────────────┐
│ Klare H1 + Einleitung │
├─────────────────────────────────────┤
│ Inhaltsverzeichnis (bei langen │
│ Seiten > 3 Sections) │
├─────────────────────────────────────┤
│ Content-Sections mit H2-Struktur │
│ - Scanbare Absätze │
│ - Listen und Tabellen │
├─────────────────────────────────────┤
│ CTA am Ende (nicht dominant) │
└─────────────────────────────────────┘
```
- Klare H2-Struktur für Scanability
- Inhaltsverzeichnis bei langen Seiten (>3 Sections)
- CTAs am Ende von Sektionen, nicht dominant
- Fokus auf Lesbarkeit und Navigation
### Seiten mit purpose: ueberzeugen
```
┌─────────────────────────────────────┐
│ Problem-Statement (Identifikation) │
├─────────────────────────────────────┤
│ Lösung präsentieren │
│ - USP-Cards / Feature-Grid │
├─────────────────────────────────────┤
│ Beweis (Social Proof) │
│ - Testimonials, Case Studies │
│ - Zahlen und Fakten │
├─────────────────────────────────────┤
│ CTA mit klarer Handlungsaufforderung │
└─────────────────────────────────────┘
```
- Problem → Lösung → Beweis → CTA Flow
- USP-Cards/Feature-Grid prominent
- Social Proof zwischen Content-Sections
- Emotionale + rationale Argumentation
---
## Ansprache-konsistente UI-Texte
Alle UI-Texte müssen die Ansprache aus Kategorie C widerspiegeln.
### Ansprache: du
| Element | Beispiel |
|---------|----------|
| Button | "Jetzt starten", "Schick uns eine Nachricht" |
| Formular-Label | "Dein Name", "Deine E-Mail" |
| Placeholder | "Wie können wir dir helfen?" |
| Microcopy | "Wir melden uns bei dir zurück" |
| Fehlertext | "Bitte gib deine E-Mail an" |
| Erfolgstext | "Danke! Wir haben deine Nachricht erhalten." |
### Ansprache: sie
| Element | Beispiel |
|---------|----------|
| Button | "Jetzt starten", "Senden Sie uns eine Nachricht" |
| Formular-Label | "Ihr Name", "Ihre E-Mail" |
| Placeholder | "Wie können wir Ihnen helfen?" |
| Microcopy | "Wir melden uns bei Ihnen" |
| Fehlertext | "Bitte geben Sie Ihre E-Mail an" |
| Erfolgstext | "Vielen Dank! Wir haben Ihre Nachricht erhalten." |
### Konsistenz-Regel
**Pflicht:** Die gewählte Ansprache muss auf ALLEN Seiten und in ALLEN UI-Elementen konsistent sein. Mischformen sind verboten.
---
## Responsive Breakpoints
### Konkrete Viewports
| Viewport | Bereich | Verhalten |
|----------|---------|-----------|
| Mobile | 320px 767px | Hamburger Navigation, Stack-Layout, Touch-Targets 44×44px |
| Tablet | 768px 1023px | Collapsed Navigation erlaubt, 2-Column-Grids |
| Desktop | 1024px+ | Full Navigation, bis zu 4-Column-Grids |
### Mobile (320px 767px)
- Hamburger-Navigation mit Slide-Out oder Fullscreen-Overlay
- Einspaltiges Layout (Stack)
- Touch-Targets mindestens 44×44px
- Keine Hover-Only-Interaktionen
- Sticky Header (optional, je nach Interaktionsniveau)
- Bottom-Sticky CTAs bei Conversion-Seiten
### Tablet (768px 1023px)
- Navigation kann collapsed bleiben oder aufklappen
- 2-Column-Grids möglich
- Touch und Hover coexistieren
- Seitlicher Padding erhöht
### Desktop (1024px+)
- Volle Navigation sichtbar
- Bis zu 4-Column-Grids
- Hover-Effekte aktiv
- Container-Max-Width greift
---
## Accessibility (Barrierefreiheit)
### WCAG 2.1 Level AA
Jede UI muss mindestens WCAG 2.1 Level AA erfüllen:
| Anforderung | Kriterium |
|-------------|-----------|
| Kontrast (normaler Text) | mindestens 4.5:1 |
| Kontrast (großer Text) | mindestens 3:1 |
| Kontrast (UI-Elemente) | mindestens 3:1 |
| Fokus-Indikator | sichtbar für alle interaktiven Elemente |
| Tastatur-Navigation | vollständig ohne Maus bedienbar |
| Screen Reader | alle Inhalte zugänglich |
### Semantisches HTML
```html
<!-- Korrekt -->
<button type="button">Aktion ausführen</button>
<a href="/kontakt">Zum Kontaktformular</a>
<nav aria-label="Hauptnavigation">...</nav>
<!-- Falsch -->
<div onclick="...">Aktion ausführen</div>
<span class="link">Zum Kontaktformular</span>
<div class="nav">...</div>
```
### ARIA-Attribute
- ARIA nur verwenden, wenn natives HTML nicht ausreicht
- `aria-label` für Icons ohne sichtbaren Text
- `aria-expanded`, `aria-hidden` für dynamische Inhalte
- `aria-live` für dynamische Updates (z.B. Fehlermeldungen)
- `role` nur wenn semantisches HTML keine Option ist
### Formulare
- Jedes Eingabefeld braucht ein sichtbares `<label>`
- Fehlermeldungen sind klar, hilfreich und programmatisch verknüpft
- Pflichtfelder sind gekennzeichnet (`aria-required`)
- Validierung sowohl visuell als auch für Screenreader
- Autofill-Attribute (`autocomplete`) wo sinnvoll
### Nicht nur Farbe
- Informationen nie nur durch Farbe vermitteln
- Zusätzliche Indikatoren: Icons, Text, Muster, Unterstreichungen
---
## Responsive Design
### Mobile-First Pflicht
Basis-Styles gelten für Mobile. Erweiterungen für größere Screens:
```css
/* Basis: Mobile (< 640px) */
.element {
flex-direction: column;
padding: var(--spacing-sm);
}
/* Tablet und größer */
@media (min-width: 768px) {
.element {
flex-direction: row;
padding: var(--spacing-md);
}
}
```
### Breakpoints
Breakpoints aus `design_tokens.json` verwenden:
| Token | Wert | Gerät |
|-------|------|-------|
| `sm` | 640px | Große Smartphones |
| `md` | 768px | Tablets |
| `lg` | 1024px | Kleine Laptops |
| `xl` | 1280px | Desktop |
| `2xl` | 1536px | Große Screens |
### Prüfpflicht
- Minimum: 320px (kleine Smartphones)
- Maximum: unbegrenzt (fluid bis Container-Max)
- Keine horizontalen Scrollbars
- Keine abgeschnittenen Inhalte
- Touch-Targets: mindestens 44x44px
### Fluid Typography
Schriftgrößen skalieren responsiv (wenn in Tokens definiert):
```css
font-size: clamp(1rem, 2vw + 0.5rem, 1.5rem);
```
---
## SEO Basics
### Pflicht-Elemente pro Seite
- [ ] Eindeutiger `<title>` (50-60 Zeichen)
- [ ] Meta-Description (150-160 Zeichen)
- [ ] Korrekte Heading-Hierarchie (`h1` > `h2` > `h3`, nur ein `h1` pro Seite)
- [ ] Alt-Texte für alle informativen Bilder
- [ ] Open Graph Tags (`og:title`, `og:description`, `og:image`)
- [ ] Canonical URL (bei Duplicate Content)
### Strukturierte Inhalte
- Semantische HTML-Elemente verwenden
- Strukturierte Daten (JSON-LD) wo sinnvoll:
- Organization
- LocalBusiness
- FAQ
- BreadcrumbList
- Article
### Technisches SEO
- Sprechende URLs
- `robots.txt` vorhanden
- `sitemap.xml` generiert
- Keine Duplicate Content ohne Canonical
- Keine Blocking-Resources im Critical Path
---
## GEO / AI-Search-Optimierung
### Klare Informationsarchitektur
- Prägnante, gut strukturierte Abschnitte
- Klare Überschriften, die den Inhalt beschreiben
- Faktenbasierte, zitierbare Aussagen
- Keine Marketing-Floskeln ohne Substanz
### FAQ wo sinnvoll
- FAQ-Schema für häufige Fragen
- Klare Frage-Antwort-Struktur
- Direkte, hilfreiche Antworten
### Zitierbarkeit
- Unique Content mit klarem Mehrwert
- Quellenangaben wo relevant
- Autorenschaft und Expertise zeigen (E-E-A-T)
---
## Performance Budget
### Core Web Vitals Ziele
| Metrik | Ziel | Beschreibung |
|--------|------|--------------|
| LCP | < 2.5s | Largest Contentful Paint |
| INP | < 200ms | Interaction to Next Paint |
| CLS | < 0.1 | Cumulative Layout Shift |
### Asset-Limits
| Asset-Typ | Maximum |
|-----------|---------|
| JavaScript Bundle (gzip) | < 100kb |
| CSS Bundle (gzip) | < 30kb |
| Einzelbild | < 200kb |
| Gesamte Seite | < 1.5MB |
### Optimierungspflichten
- Bilder: WebP/AVIF, responsive `srcset`, Lazy Loading
- Fonts: Subset, `display: swap`, Preload für kritische Fonts
- JavaScript: Code-Splitting, Tree-Shaking, defer/async
- CSS: Kritisches CSS inline, Rest async laden
---
## Interaktionen
### Feedback-Pflicht
- Hover-States für alle klickbaren Elemente
- Focus-States sichtbar und deutlich
- Loading-States für asynchrone Aktionen
- Erfolgs- und Fehlermeldungen klar kommunizieren
### Animationen
- Subtil und zweckmäßig (nicht dekorativ)
- `prefers-reduced-motion` respektieren
- UI-Feedback-Animationen < 300ms
- Keine automatisch startenden Videos/Animationen
```css
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
}
}
```
---
## Typografie (Qualität, nicht Design)
### Lesbarkeit
- Zeilenlänge: 45-75 Zeichen optimal
- Zeilenabstand: 1.4-1.6 für Fließtext
- Ausreichende Absatzabstände
### Hierarchie
- Klare visuelle Hierarchie durch Größen/Gewichte
- Konsistente Heading-Levels
- Logische Informationsstruktur
**Hinweis:** Konkrete Schriftarten, -größen und -farben kommen aus `design_tokens.json`.
---
## Farben (Qualität, nicht Design)
### Kontrastprüfung
Alle Farbkombinationen müssen geprüft werden:
- Tool: WebAIM Contrast Checker oder ähnlich
- Dokumentierte Ausnahmen sind möglich, aber selten
### Herkunft
- Alle Farben kommen aus `design_tokens.json` oder `stylesheet.css`
- Keine hardcodierten Hex/RGB-Werte im Code
- CSS-Variablen verwenden
---
## Zusammenfassung
> UI muss zugänglich, responsive, performant und suchmaschinenoptimiert sein.
> Diese Guidelines definieren Qualitätsstandards, nicht visuelles Design.
> Design-Entscheidungen kommen aus den Projekt-Specs.

View File

@@ -1,50 +0,0 @@
{
"$schema": "./ProjectSpec.schema.json",
"meta": {
"projectName": "",
"client": "",
"version": "1.0.0",
"createdAt": "",
"updatedAt": ""
},
"brand": {
"name": "",
"tagline": "",
"description": "",
"tone": [],
"values": []
},
"target": {
"audience": [],
"goals": [],
"competitors": []
},
"pages": [],
"features": [],
"integrations": [],
"seo": {
"primaryKeywords": [],
"secondaryKeywords": [],
"localSeo": {
"enabled": false,
"regions": []
}
},
"technical": {
"hosting": "",
"domain": "",
"analytics": [],
"thirdParty": []
},
"content": {
"languages": ["de"],
"defaultLanguage": "de",
"contentSources": []
},
"timeline": {
"kickoff": "",
"milestones": [],
"launch": ""
},
"notes": ""
}

View File

@@ -1,105 +0,0 @@
{
"$schema": "./design_tokens.schema.json",
"colors": {
"primary": "#000000",
"secondary": "#666666",
"accent": "#0066cc",
"background": "#ffffff",
"foreground": "#000000",
"muted": "#f5f5f5",
"border": "#e5e5e5",
"error": "#dc2626",
"success": "#16a34a",
"warning": "#ca8a04"
},
"typography": {
"fontFamilies": {
"sans": "system-ui, -apple-system, sans-serif",
"serif": "Georgia, serif",
"mono": "ui-monospace, monospace"
},
"fontSizes": {
"xs": "0.75rem",
"sm": "0.875rem",
"base": "1rem",
"lg": "1.125rem",
"xl": "1.25rem",
"2xl": "1.5rem",
"3xl": "1.875rem",
"4xl": "2.25rem",
"5xl": "3rem"
},
"fontWeights": {
"normal": 400,
"medium": 500,
"semibold": 600,
"bold": 700
},
"lineHeights": {
"tight": 1.25,
"normal": 1.5,
"relaxed": 1.75
}
},
"spacing": {
"xs": "0.25rem",
"sm": "0.5rem",
"md": "1rem",
"lg": "1.5rem",
"xl": "2rem",
"2xl": "3rem",
"3xl": "4rem"
},
"borderRadius": {
"none": "0",
"sm": "0.25rem",
"md": "0.5rem",
"lg": "1rem",
"full": "9999px"
},
"shadows": {
"sm": "0 1px 2px 0 rgb(0 0 0 / 0.05)",
"md": "0 4px 6px -1px rgb(0 0 0 / 0.1)",
"lg": "0 10px 15px -3px rgb(0 0 0 / 0.1)",
"xl": "0 20px 25px -5px rgb(0 0 0 / 0.1)"
},
"breakpoints": {
"sm": "640px",
"md": "768px",
"lg": "1024px",
"xl": "1280px",
"2xl": "1536px"
},
"transitions": {
"duration": {
"fast": "150ms",
"normal": "300ms",
"slow": "500ms"
},
"easing": {
"default": "cubic-bezier(0.4, 0, 0.2, 1)",
"in": "cubic-bezier(0.4, 0, 1, 1)",
"out": "cubic-bezier(0, 0, 0.2, 1)",
"inOut": "cubic-bezier(0.4, 0, 0.2, 1)"
}
},
"zIndex": {
"base": 0,
"dropdown": 100,
"sticky": 200,
"fixed": 300,
"modal": 400,
"popover": 500,
"tooltip": 600
},
"letterSpacing": {
"tight": "-0.01em",
"normal": "0em",
"wide": "0.05em"
},
"layout": {
"containerMaxWidth": "80rem",
"containerPaddingX": "clamp(1rem, 5vw, 2rem)",
"sectionSpacingY": "4rem"
}
}

View File

View File

@@ -1,135 +0,0 @@
@import "tailwindcss";
@import "./stylesheet.css";
/*
* CSS Variables - Single Source of Truth
* These variables are placeholders. Override them per project via design_tokens.json
*/
:root {
/* Colors - Placeholders */
--color-primary: #000000;
--color-secondary: #666666;
--color-accent: #0066cc;
--color-background: #ffffff;
--color-foreground: #000000;
--color-muted: #f5f5f5;
--color-border: #e5e5e5;
--color-error: #dc2626;
--color-success: #16a34a;
--color-warning: #ca8a04;
/* Typography - Placeholders */
--font-sans: system-ui, -apple-system, sans-serif;
--font-serif: Georgia, serif;
--font-mono: ui-monospace, monospace;
--font-size-xs: 0.75rem;
--font-size-sm: 0.875rem;
--font-size-base: 1rem;
--font-size-lg: 1.125rem;
--font-size-xl: 1.25rem;
--font-size-2xl: 1.5rem;
--font-size-3xl: 1.875rem;
--font-size-4xl: 2.25rem;
--font-size-5xl: 3rem;
--font-weight-normal: 400;
--font-weight-medium: 500;
--font-weight-semibold: 600;
--font-weight-bold: 700;
--line-height-tight: 1.25;
--line-height-normal: 1.5;
--line-height-relaxed: 1.75;
/* Letter Spacing - Placeholders */
--letter-spacing-tight: -0.01em;
--letter-spacing-normal: 0em;
--letter-spacing-wide: 0.05em;
/* Spacing - Placeholders */
--spacing-xs: 0.25rem;
--spacing-sm: 0.5rem;
--spacing-md: 1rem;
--spacing-lg: 1.5rem;
--spacing-xl: 2rem;
--spacing-2xl: 3rem;
--spacing-3xl: 4rem;
/* Border Radius - Placeholders */
--radius-none: 0;
--radius-sm: 0.25rem;
--radius-md: 0.5rem;
--radius-lg: 1rem;
--radius-full: 9999px;
/* Shadows - Placeholders */
--shadow-sm: 0 1px 2px 0 rgb(0 0 0 / 0.05);
--shadow-md: 0 4px 6px -1px rgb(0 0 0 / 0.1);
--shadow-lg: 0 10px 15px -3px rgb(0 0 0 / 0.1);
--shadow-xl: 0 20px 25px -5px rgb(0 0 0 / 0.1);
/* Transitions - Placeholders */
--duration-fast: 150ms;
--duration-normal: 300ms;
--duration-slow: 500ms;
--easing-default: cubic-bezier(0.4, 0, 0.2, 1);
/* Z-Index Scale */
--z-base: 0;
--z-dropdown: 100;
--z-sticky: 200;
--z-fixed: 300;
--z-modal: 400;
--z-popover: 500;
--z-tooltip: 600;
/* Layout - Placeholders */
--container-max-width: 80rem;
--container-padding-x: clamp(1rem, 5vw, 2rem);
--section-spacing-y: var(--spacing-3xl);
}
/*
* Base Resets
*/
*,
*::before,
*::after {
box-sizing: border-box;
}
html {
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
text-rendering: optimizeLegibility;
}
body {
margin: 0;
padding: 0;
font-family: var(--font-sans);
font-size: var(--font-size-base);
line-height: var(--line-height-normal);
color: var(--color-foreground);
background-color: var(--color-background);
}
img,
video {
max-width: 100%;
height: auto;
display: block;
}
a {
color: inherit;
text-decoration: none;
}
button {
font: inherit;
cursor: pointer;
}

View File

@@ -1,164 +0,0 @@
/*
* Stylesheet
*
* Typography & structural rules only.
* NO component styles. NO layout sections.
* This file is imported by globals.css.
*
* Structure:
* 1. Typography
* 2. Structural Rules
* 3. Utility Classes
* 4. Animations
*/
/* ==========================================================================
1. Typography
========================================================================== */
h1,
h2,
h3,
h4,
h5,
h6 {
font-weight: var(--font-weight-bold);
line-height: var(--line-height-tight);
letter-spacing: var(--letter-spacing-tight);
margin-top: 0;
margin-bottom: var(--spacing-md);
}
h1 {
font-size: var(--font-size-4xl);
}
h2 {
font-size: var(--font-size-3xl);
}
h3 {
font-size: var(--font-size-2xl);
}
h4 {
font-size: var(--font-size-xl);
}
h5 {
font-size: var(--font-size-lg);
}
h6 {
font-size: var(--font-size-base);
font-weight: var(--font-weight-semibold);
}
p {
margin-top: 0;
margin-bottom: var(--spacing-md);
line-height: var(--line-height-normal);
}
small {
font-size: var(--font-size-sm);
}
strong,
b {
font-weight: var(--font-weight-bold);
}
/* Prevent orphans and widows in text blocks */
p,
li,
dd {
orphans: 2;
widows: 2;
}
/* Lists */
ul,
ol {
margin-top: 0;
margin-bottom: var(--spacing-md);
padding-left: var(--spacing-lg);
}
li {
margin-bottom: var(--spacing-xs);
}
/* Blockquote */
blockquote {
margin: 0 0 var(--spacing-md);
padding-left: var(--spacing-lg);
border-left: 3px solid var(--color-border);
font-style: italic;
}
/* Code */
code {
font-family: var(--font-mono);
font-size: var(--font-size-sm);
}
pre {
margin-top: 0;
margin-bottom: var(--spacing-md);
overflow-x: auto;
}
pre code {
font-size: var(--font-size-sm);
}
/* ==========================================================================
2. Structural Rules
========================================================================== */
/* Focus styles for keyboard navigation */
:focus-visible {
outline: 2px solid var(--color-primary);
outline-offset: 2px;
}
/* Selection */
::selection {
background-color: var(--color-primary);
color: var(--color-background);
}
/* Reduced motion */
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}
/* ==========================================================================
3. Utility Classes
========================================================================== */
.visually-hidden {
position: absolute;
width: 1px;
height: 1px;
padding: 0;
margin: -1px;
overflow: hidden;
clip: rect(0, 0, 0, 0);
white-space: nowrap;
border: 0;
}
/* ==========================================================================
4. Animations
========================================================================== */
/* Animations are added per project */

View File

@@ -1,27 +0,0 @@
{
"compilerOptions": {
"target": "ES2017",
"lib": ["dom", "dom.iterable", "esnext"],
"allowJs": true,
"skipLibCheck": true,
"strict": true,
"noEmit": true,
"esModuleInterop": true,
"module": "esnext",
"moduleResolution": "bundler",
"resolveJsonModule": true,
"isolatedModules": true,
"jsx": "preserve",
"incremental": true,
"plugins": [
{
"name": "next"
}
],
"paths": {
"@/*": ["./*"]
}
},
"include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
"exclude": ["node_modules"]
}

File diff suppressed because one or more lines are too long