Diese vier Template-Dateien lösen das Problem. Sie geben deiner KI ein Gedächtnis, eine Persönlichkeit und klare Grenzen. Einmal eingerichtet, funktionieren sie sessionübergreifend.
Die 4 Dateien im Überblick
Datei
Zweck
Kernfrage
IDENTITY.md
Rolle & Persönlichkeit
Wie soll die KI handeln?
STYLE.md
Tonalität & Formatierung
Wie soll die KI sich ausdrücken?
CONTEXT.md
Projekt-Hintergrund
Was muss die KI wissen?
RULES.md
Harte Grenzen
Was darf die KI niemals tun?
IDENTITY.md — Rolle, Persönlichkeit, Arbeitsweise
Was gehört rein?
Die Identity-Datei definiert, wer die KI in deinem Projekt ist. Nicht im Sinne von Rollenspiel, sondern im Sinne von: Welche Haltung soll sie einnehmen? Wie soll sie Entscheidungen treffen?
Kernelemente:
Rolle: Was ist der Job? (z.B. „Senior Frontend Developer", „Content Strategist", „Produkt-Berater")
Kernaufgaben: Die 3-5 wichtigsten Dinge, die die KI tun soll
Persönlichkeitseigenschaften: Proaktiv vs. zurückhaltend? Meinungsstark vs. neutral? Kreativ vs. analytisch?
Entscheidungsprinzipien: Wonach soll sie priorisieren? (z.B. „Speed vor Perfektion", „Revenue vor Features")
Arbeitsweise: Wann nachfragen, wann eigenständig handeln?
Warum das die Ergebnisse verbessert
Ohne Identity verhält sich die KI wie ein generischer Assistent — höflich, aber ohne Haltung. Mit Identity bekommst du konsistente, kontextbezogene Antworten, die zu deinem Projekt passen. Statt „Hier sind 5 Optionen" bekommst du „Ich empfehle Option A, weil sie zu deinem Ziel X passt."
Typische Fehler
Zu vage: „Sei hilfreich" sagt nichts. Besser: „Schlage immer genau EINEN nächsten Schritt vor."
Zu viele Eigenschaften: 3-4 starke Traits schlagen 10 generische.
Widersprüche: „Sei proaktiv" und „Frag immer erst nach" beisst sich. Sei präzise, wann welches Verhalten gilt.
STYLE.md — Tonalität, Sprache, Formatierung
Was gehört rein?
Die Style-Datei definiert, wie die KI kommuniziert. Ton, Sprache, Format — alles was bestimmt, wie sich der Output anfühlt.
Gut/Schlecht-Beispiel: Zeigt der KI konkret, was du willst
Warum das die Ergebnisse verbessert
Die KI tendiert zu einem generischen „Assistenten-Ton" — überhöflich, mit Floskeln wie „Natürlich!" und „Das ist eine tolle Frage!". Die Style-Datei eliminiert das. Besonders das Gut/Schlecht-Beispiel ist kraftvoll: Ein einziges konkretes Beispiel wirkt stärker als 10 abstrakte Regeln.
Typische Fehler
Nur Don'ts definieren, keine Do's: Die KI muss wissen, was sie STATTDESSEN tun soll.
Kein Beispiel: Abstrakte Stilregeln sind interpretierbar. Konkrete Beispiele nicht.
Sprache vergessen: Wenn du in mehreren Sprachen arbeitest, definiere klar, wann welche gilt.
Die Context-Datei gibt der KI das Domänenwissen, das sie braucht, um im richtigen Rahmen zu arbeiten.
Kernelemente:
Projekt-Steckbrief: Name, Typ, Status, Elevator Pitch
Tech-Stack: Tabelle mit Technologien pro Layer
Architektur: Ordnerstruktur, wichtige Patterns
Zielgruppe: Primär, sekundär, Anti-Zielgruppe
Aktueller Stand: Checkliste — was ist da, was fehlt
Prioritäten: Was hat gerade Vorrang und warum
Glossar: Projektspezifische Begriffe und Abkürzungen
Warum das die Ergebnisse verbessert
Ohne Context rät die KI. Sie schlägt React vor, obwohl du Vue nutzt. Sie erklärt Grundlagen, die du längst kennst. Sie ignoriert deine Architektur-Entscheidungen. Mit Context arbeitet sie innerhalb deines Projekts statt daneben.
Das Glossar ist besonders wichtig bei Projekten mit eigener Fachsprache. Wenn die KI weiss, dass „Binder" in deinem Projekt eine Spielerrolle ist und kein Ordner, vermeidest du Missverständnisse.
Typische Fehler
Zu viel auf einmal: Nur das aufnehmen, was die KI regelmässig braucht. Deep Dives in Subdateien auslagern.
Nicht aktuell halten: Veralteter Context ist schlimmer als kein Context. Prioritäten und Status regelmässig updaten.
Pfade vergessen: Bei Code-Projekten braucht die KI die Ordnerstruktur, sonst erstellt sie Dateien am falschen Ort.
RULES.md — Harte Grenzen für Code, Kommunikation und Scope
Was gehört rein?
Die Rules-Datei definiert was die KI niemals tun darf. Das sind keine Präferenzen, sondern harte Grenzen.
Kernelemente:
Absolut verboten: Daten löschen, Secrets hardcoden, auf Production pushen, Kosten verursachen
Code-Regeln: Keine any Types, keine console.log, keine unbenutzten Imports
Kommunikations-Regeln: Nicht halluzinieren, nichts verschweigen, kein Over-Engineering
Scope-Regeln: Kein Scope Creep, keine unangefragten Refactorings
Datenschutz: Keine personenbezogenen Daten in Logs, keine Credentials committen
Warum das die Ergebnisse verbessert
KI-Modelle sind von Natur aus eager to please — sie wollen helfen und neigen dazu, mehr zu tun als gefragt. Das führt zu Scope Creep, unnötigen Refactorings und manchmal gefährlichen Aktionen (z.B. Produktionsdaten ändern). Die Rules-Datei setzt klare Leitplanken.
Besonders wichtig: Die Goldene Regel am Ende — „Im Zweifel nachfragen statt falsch machen." Das ändert das Default-Verhalten der KI von „einfach machen" zu „erst absichern".
Typische Fehler
Zu restriktiv: Wenn alles verboten ist, kann die KI nicht arbeiten. Fokus auf Dinge mit echtem Schadenspotenzial.
Keine Erklärung: „Kein any" ist eine Regel. „Kein any weil TypeScript strict mode unsere erste Verteidigung gegen Bugs ist" wird besser befolgt.
Nicht projektspezifisch: Generische Regeln wie „schreib guten Code" bringen nichts. „Keine Class Components, nur funktionale mit Hooks" ist konkret.
So richtest du die Dateien ein
Schritt 1: Templates kopieren
Leg einen .claude/ Ordner in deinem Projektroot an (oder wo immer deine KI Kontext-Dateien sucht). Kopiere die vier Templates hinein.
Schritt 2: Platzhalter ausfüllen
Jede Datei enthält [PLATZHALTER] und HTML-Kommentare mit Erklärungen. Geh sie der Reihe nach durch. Füll nur aus, was du sicher weisst. Der Rest kann später ergänzt werden.
Empfohlene Reihenfolge:
CONTEXT.md zuerst — das ist das Fundament (Projekt, Tech-Stack, Glossar)
IDENTITY.md als zweites — wie soll die KI innerhalb dieses Kontexts handeln?
STYLE.md als drittes — wie soll sie sich ausdrücken?
RULES.md zuletzt — welche Grenzen braucht es?
Schritt 3: Iterieren
Die Dateien werden besser, je mehr du mit der KI arbeitest. Wenn sie etwas tut, das dich stört: Schreib eine Regel dafür. Wenn sie etwas gut macht: Dokumentiere das Pattern.
Pflege-Tipps
Wöchentlich prüfen:
Stimmen die Prioritäten in CONTEXT.md noch?
Ist der Projektstatus aktuell?
Bei jedem neuen Projekt:
CONTEXT.md komplett neu ausfüllen
IDENTITY.md anpassen (andere Rolle?)
STYLE.md und RULES.md oft wiederverwendbar — nur projektspezifische Ergänzungen
Bei Problemen:
KI redet zu viel? → STYLE.md: Längenbeschränkung + Don't hinzufügen
KI macht zu viel eigenständig? → RULES.md: Scope-Regel verschärfen
KI versteht den Kontext nicht? → CONTEXT.md: Glossar und Architektur ergänzen
KI ist zu generisch? → IDENTITY.md: Entscheidungsprinzipien konkretisieren
Nutzung mit anderen KIs (nicht nur Claude)
Die Templates funktionieren plattformübergreifend, aber es gibt Unterschiede:
Claude (Anthropic)
Liest .claude/CLAUDE.md automatisch als Projekt-Kontext
Tipp: Alle 4 Dateien in eine einzige CLAUDE.md mergen oder per @-Import referenzieren
Unterstützt mehrstufige Hierarchie: Global → Entity → Projekt
ChatGPT / GPT-4 (OpenAI)
Kein natives Dateisystem-Lesen. Kontext muss als Custom Instructions oder System Prompt eingefügt werden
Tipp: IDENTITY + STYLE in die „Custom Instructions" (persistent). CONTEXT + RULES als erste Nachricht im Chat.
Zeichenlimit beachten: Custom Instructions haben ein Limit (~1.500 Zeichen). Stark kürzen.
Cursor / Windsurf / andere Code-Editoren
Lesen .cursorrules, .windsurfrules oder ähnliche Dateien
Tipp: Inhalt der 4 Templates in die jeweilige Rules-Datei des Editors übernehmen. Format ist meistens Markdown.
Gemini (Google)
System Instructions im API-Modus, „Gems" in der Weboberfläche
Tipp: IDENTITY + STYLE als System Instruction. CONTEXT als erster Turn.
Allgemeine Hinweise für andere KIs
RULES.md ist am wichtigsten für alle Modelle. Jede KI braucht klare Grenzen.
Gut/Schlecht-Beispiele (aus STYLE.md) funktionieren universell — alle Modelle lernen besser aus Beispielen als aus abstrakten Regeln.
Kürzer = besser bei Modellen mit kleinem Kontextfenster. Im Zweifel: RULES + CONTEXT priorisieren, STYLE + IDENTITY kürzen.
Testen: Jedes Modell interpretiert Anweisungen anders. Nach dem Setup eine Test-Aufgabe stellen und prüfen, ob der Output passt.