Chris EichlerAI-first Product
& Marketing

KI wie ein Profi


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

DateiZweckKernfrage
IDENTITY.mdRolle & PersönlichkeitWie soll die KI handeln?
STYLE.mdTonalität & FormatierungWie soll die KI sich ausdrücken?
CONTEXT.mdProjekt-HintergrundWas muss die KI wissen?
RULES.mdHarte GrenzenWas 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.

Kernelemente:

  • Grundton: Locker-technisch? Professionell-warm? Sachlich-präzise?
  • Sprachregeln: Welche Sprache für was? Du oder Sie? Fachbegriffe erlaubt?
  • Formatierung: Markdown-Struktur, Länge, Code-Kommentare
  • Do's: Konkrete Beispiele, aktive Sprache, klare Struktur
  • Don'ts: Floskeln, Buzzwords, unnötige Einleitungen
  • 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.

CONTEXT.md — Projekt-Steckbrief, Tech-Stack, Zielgruppe

Was gehört rein?

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:

  1. CONTEXT.md zuerst — das ist das Fundament (Projekt, Tech-Stack, Glossar)
  2. IDENTITY.md als zweites — wie soll die KI innerhalb dieses Kontexts handeln?
  3. STYLE.md als drittes — wie soll sie sich ausdrücken?
  4. 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.
Als nächstesObsidian

Inspiration zu KI-first Product Management & Marketing, direkt in dein Postfach.

Kein Spam, jederzeit abbestellbar

Chris Eichler