WISSEN

📚 Knowledge & Skills. Wissen, das skaliert.

Knowledge läuft bei jedem Prompt automatisch mit. Skills sind Workflows auf Abruf – per /skill-name oder Auto-Match.

Knowledge
Skills
Was ist es?
Persistente Regeln und Kontext, die Lovable bei jeder Antwort mitliest.
Wiederverwendbarer Workflow / Playbook für einen bestimmten Task.
Wann aktiv?
Immer – bei jedem Prompt automatisch im Kontext.
On-demand – per /skill-name oder automatisch, wenn die Beschreibung matcht.
Wo gepflegt?
Settings → Knowledge (Workspace) oder Projekt-Einstellungen → Knowledge.
Settings → Skills im Workspace (oder als ZIP/GitHub importieren).
Limit
Bis 10.000 Zeichen pro Knowledge-Ebene.
Kein hartes Zeichenlimit – aber kurz und fokussiert halten.
Typischer Inhalt
Coding-Standards, Tech-Stack, Design-Tokens, Tonalität, Don'ts.
Schritt-für-Schritt-Anweisung für einen wiederkehrenden Task.
Beispiel
"Wir nutzen DM Sans für Headlines und Inter für Body."
"launch-checklist" – läuft, wenn du sagst: 'Ich will releasen.'

Was ist Knowledge?

Persistente Instruktionen und Kontext, die Lovable bei jeder Antwort automatisch mitliest – Regeln, Standards, Projekt-Wissen.

  • Workspace-Knowledge: globale Regeln für alle Projekte. Settings → Knowledge.
  • Projekt-Knowledge: projektspezifischer Kontext. Projekt-Einstellungen → Knowledge.
  • Limit: 10.000 Zeichen pro Ebene.
  • Priorität: Projekt schlägt Workspace.

Best Practices

  • Workspace-Knowledge für globale Regeln (Stack, Coding-Standards, Markenstimme).
  • Projekt-Knowledge für projektspezifische Details (Zweck, Datenmodell, Architektur).
  • Projekt-Knowledge schlägt Workspace-Knowledge bei Konflikten.
  • Klar & konkret formulieren: "Aktiviere TypeScript strict. Nutze niemals any." statt "Schreibe sauberen Code".
  • Bullet-Listen statt Fließtext – Lovable folgt Regeln zuverlässiger.
  • Aktuell halten: Bei Stack-/Architektur-Änderungen sofort nachziehen.
  • Architektonische Entscheidungen dokumentieren, damit Lovable sie nicht eigenmächtig umbaut.
  • Knowledge ≠ Skill: Knowledge ist für IMMER-Regeln, Skills sind für Workflows auf Abruf.

MASTER-TEMPLATE

Projekt-Knowledge zum Kopieren

Kopiere das in Projekt-Einstellungen → Knowledge und fülle die Platzhalter aus. Kommentare in <!-- ... --> dürfen drinbleiben oder rausfliegen.

# Projekt-Knowledge

## Projekt-Überblick
<!-- Was ist die App? Für wen? Welcher Hauptnutzen? Eine Kern-Action. -->
- App-Name:
- One-Liner:
- Hauptnutzer-Aktion:

## Zielgruppe & Personas
<!-- Wer nutzt die App? 1–3 Personas mit Kontext und Anspruch. -->
- Primäre Persona:
- Sekundäre Persona:
- Tonalität gegenüber Nutzer:innen:

## Tech-Stack & Architektur
<!-- Stack: TanStack Start (React 19, Vite 7, Tailwind v4), shadcn/ui.
     Backend ist ausschließlich Supabase – Lovable Cloud wird in diesem Projekt
     bewusst NICHT verwendet. -->
- Frontend:    TanStack Start + React 19 + TypeScript (strict)
- Styling:     Tailwind v4 (CSS-first), shadcn/ui
- Backend:     Supabase (Postgres, Auth, Storage, Edge Functions) – **nicht** Lovable Cloud
- Auth:        Supabase Auth (E-Mail + ggf. Google/Apple)
- Animationen: Framer Motion (Pflicht)
- Sonstige Architektur-Regeln:

## Design-System
<!-- Tokens leben in src/styles.css. Niemals hardcoded Farben in Komponenten. -->
- Primärfarbe:
- Akzentfarbe:
- Headline-Font:
- Body-Font:
- Radius / Spacing-Skala:
- Light/Dark-Mode:

## Animations-Regeln
<!-- Pflichtregel – wörtlich an Lovable übergeben. -->
- Use React, Tailwind CSS, Framer Motion for all animations.
- Keine CSS-Keyframes, kein GSAP, kein react-spring – ausschließlich Framer Motion.
- Respektiere die User-Einstellung prefers-reduced-motion.

## Datenmodell
<!-- Wichtigste Tabellen, Beziehungen, RLS-Pattern. -->
- Tabellen & Felder:
- Beziehungen (1:n, n:m):
- Rollen & Zugriffsregeln (RLS): siehe Skill 'supabase-table-add'

## Domain-Terminologie
<!-- Begriffe aus der Fachdomäne, die Lovable benutzen soll. -->
- Begriff →  Bedeutung:

## Coding-Konventionen
- TypeScript strict an, kein 'any'.
- Semantische Design-Tokens verwenden, NIE 'bg-white' / 'text-black' / Hex-Werte.
- Komponenten klein und fokussiert halten.
- Server-only-Logik in *.server.ts oder createServerFn.
- Keine console.logs in Produktions-Code.

## Tonalität & Copy
- Sprache: Deutsch (Du-Form)
- Stil: knapp, direkt, freundlich – keine Floskeln.
- Beispiel-Prompts dürfen Englisch bleiben.

## Don'ts
- Keine eigenen Layout-Frameworks – immer Tailwind + shadcn.
- Keine Lorem-Ipsum-Platzhalter.
- Niemals Rollen im profiles-Table speichern – immer separate user_roles-Tabelle.
- Keine Supabase-Edge-Functions für App-interne Logik – Server Functions verwenden.
- Niemals Lovable Cloud aktivieren – Backend ist ausschließlich Supabase.
- Keine anderen Animations-Libraries als Framer Motion verwenden.

## Externe Referenzen
- Design-System / Brand-Guide:
- API-Doku:
- Figma / Whimsical: