v0-Optimierungen für CockpitOS Full-Site-Templates

Empfehlungen basierend auf der offiziellen v0-Dokumentation (Stand: Feb 2025).

Status: Alle empfohlenen Sofort-Maßnahmen wurden implementiert (Feb 2025).

---

1. Vercel-Prompt-Framework: Drei Inputs

Die Vercel-Blog-Studie zeigt, dass spezifische Prompts zu 30–40 % schnellerer Generierung, weniger Code und besseren UX-Entscheidungen führen. Das Framework besteht aus drei Kerninputs:

Input	Bedeutung	Unser aktueller Stand
Product Surface	Komponenten, Daten, Aktionen konkret	Gut – wir haben detaillierte Props und Struktur
Context of Use	Wer nutzt es, wann, zu welcher Entscheidung?	Fehlt – nicht explizit formuliert
Constraints & Taste	Plattform, visueller Ton, Layout	Teilweise – nur in „DEIN FREIRAUM“

Empfehlung: Prompt um Abschnitt erweitern

Neuer Abschnitt direkt nach TASK einfügen:

## CONTEXT OF USE

**Zielgruppe:** Besucher von Shopping-Center-Websites (B2C, 18–55 Jahre), oft mobil unterwegs.
**Situation:** Schnelle Orientierung – Shops finden, Events, Öffnungszeiten, Parken.
**Geräte:** Mobile-first (60 %+ Traffic), Desktop/Tablet für Karten und Detailseiten.
**Erwartung:** Klare Struktur, schnelle Ladezeiten, einfache Navigation ohne Ablenkung.

## CONSTRAINTS

- Mobile-first, responsive (breakpoints: sm, md, lg, xl)
- Touch-freundlich (min. 44×44px für Tappables)
- Semantisches HTML (nav, main, section, article)
- Keine eigenen Chatbot- oder Centerplan-Implementierungen – CockpitOS injiziert sie
- Barrierefreiheit: Fokus-States, Kontrast, alt-Texte für Bilder

---

2. Error Handling & Loading States

Die v0-Doku empfiehlt explizit: „Include error handling for network failures, invalid input, and empty states.“

Aktuell: Wir haben „Fallbacks: Leere Arrays → „Keine Einträge“-State“.

Ergänzung: In TECHNISCHE PFLICHTEN einbauen:

- **Loading States:** Skeleton-Loader oder Spinner für Daten, die asynchron geladen werden (z.B. highlights, tiles)
- **Empty States:** Klare UI für leere Arrays („Keine Shops gefunden“, „Keine Events“)
- **Error States:** Fallback für fehlende Bilder (Gradient/Placeholder), kaputte Links vermeiden

---

3. Component-First / Progressive Enhancement

v0 empfiehlt für komplexe Projekte: „Large, complex applications are better built incrementally.“

Option A – Beibehalten:
Wir generieren alles in einem Durchgang. Das ist für „Full-Site-Skin“ sinnvoll, weil die Seiten konsistent sein müssen.

Option B – Hybrid:
Für Nutzer, die unsicher sind, könnten wir einen alternativen Workflow dokumentieren:

1. Schritt 1: Nur layout.tsx + sections/ (Header, Hero, Footer, Typography)
2. Schritt 2: Homepage + Index
3. Schritt 3: Übersichtsseiten (shops, aktuelles, services)
4. Schritt 4: Detail-Seiten

→ Implementiert in website-templates.md als „Schrittweise generieren (optional)“.

---

4. v0 Instructions (Custom Instructions)

v0 nutzt Instructions – wiederverwendbare Regeln, die pro Chat aktiviert werden:

Unterschied: Instructions gelten für jede Nachricht im Chat (auch Follow-ups wie „Mach die Karten größer“). Der Haupt-Prompt gehört in die Chat-Eingabe; die CockpitOS-Regeln in die Instruction – so bleiben sie bei allen Änderungen aktiv.

Empfehlung: Wir erstellen eine CockpitOS-Template-Instruction für Nutzer:

1. In v0: + → „New Instruction“
2. Titel: z.B. „CockpitOS Center Website Template“
3. Inhalt: z.B.
   • „Always use centerSlug in links, never hardcode slugs.“
   • „Do not implement chatbot or centerplan – they are global CockpitOS components.“
   • „Use next/link and next/image for all links and images.“
   • „All props come from parent – no hardcoded content.“

Diese Instruction kann in der Doku verlinkt und als „Vor dem Generieren aktivieren“ empfohlen werden.

---

5. Design System / Registry (optional, langfristig)

Die Design-Systems-Doku beschreibt ein Registry:

• Tailwind-Config, globals.css, CSS-Variablen
• shadcn/ui als Basis
• Custom Blocks für häufige Anwendungsfälle

Mögliche Erweiterung:
Ein CockpitOS-Design-Registry mit:

• Farben/Typografie aus unseren Branding-Definitionen
• Standard-Header/Footer-Patterns (ähnlich CenterNavigation, CenterFooter)
• Basis-Blocks für Shops, Events, Services

Vorteil: v0 generiert dann direkt mit unseren Design-Tokens und konsistenten Patterns.

Aufwand: Mittel – erfordert Registry-Starter-Template und Deployment.

---

6. v0 als Sources

v0 kann PDFs, TXT, Code-Dateien als Sources in Projects hinzufügen. Dadurch erhält v0 Kontext:

• Unsere template-registry.ts-Struktur
• types.ts-Schnittstellen
• Architektur-Dokumentation (z.B. full-site-template-architektur.md)

Empfehlung: In der Doku einen Hinweis hinzufügen:

„Für noch präzisere Generierungen: Füge die CockpitOS-Dokumentation oder types.ts als Source in dein v0-Projekt ein.“

---

7. Cursor + v0 Integration

v0 kann direkt in Cursor genutzt werden:

• v0 Cursor Docs
• Cursor Settings → Models → OpenAI API Key
• v0 Endpoint: https://api.v0.dev/v1
• Modelle: v0-1.5-md und v0-1.5-lg

Empfehlung: In der Doku einen kurzen Abschnitt:

„Du kannst v0 auch als Modell in Cursor nutzen – dann generierst du direkt im Projekt statt in v0.dev.“

---

8. AI Prompt Enhancement (v0-Feature)

v0 bietet „AI prompt enhancement“: Wenn du einen einfachen Prompt startest, kann v0 ihn automatisch erweitern.

Empfehlung: Nutzer dokumentieren:

„Dein Design-Prompt kann kurz sein (z.B. ‚Großer Hero, dunkles Theme, minimalistisch‘). v0 kann ihn mit ‚Enhance‘ erweitern. Kombiniere danach mit dem CockpitOS-Prompt.“

---

9. Zusammenfassung: Sofort umsetzbar

Maßnahme	Aufwand	Nutzen
Context of Use + Constraints in Prompt	1	Hoch – bessere UX/Code-Generierung
Error Handling / Loading States ergänzen	1	Hoch – robusteres Template
CockpitOS-Instruction für v0	1	Mittel – weniger Fehler (links, Chatbot)
Hinweis „Sources“ / Cursor	1	Niedrig – bessere UX für Power-User
Schrittweise Workflow	2	Mittel – optional für komplexe Templates
Design Registry	3	Hoch – langfristig, konsistente Designs

---

10. Umsetzungsstatus

Maßnahme	Status	Wo
CONTEXT OF USE + CONSTRAINTS im Prompt	Ja	website-prompt.mdx
Loading/Error States in TECHNISCHE PFLICHTEN	Ja	website-prompt.mdx
CockpitOS v0 Instruction (Copy-Paste)	Ja	website-prompt.mdx
v0 Instructions + Cursor + Schrittweise Workflow	Ja	website-templates.md
v0-Optimierungen (Instructions, Sources, Cursor)	Ja	upload.md

11. Langfristig (optional)

• Design Registry: CockpitOS-Design-Registry mit Vercel Registry Starter: Tailwind-Config, Design-Tokens, Custom Blocks (Header/Footer-Patterns). v0 generiert dann direkt mit unseren Tokens.