KI-Projektkontext aufbauen: Warum dein Projekt nicht mehr mit jeder Session neu anfangen sollte

Warum KI den Kontext nicht behält — und warum das nicht das eigentliche Problem ist

Das Kontextfenster: eine technische Grenze, kein Fehler

KI-Sprachmodelle arbeiten mit einem Kontextfenster. Alles, was in diesem Fenster steht — die laufende Konversation, hochgeladene Dateien, System-Prompts — steht dem Modell zur Verfügung. Was außerhalb liegt, existiert nicht.

Das bedeutet: Jede neue Konversation beginnt ohne Kenntnis der vorherigen. Das Modell weiß nicht, was in der letzten Session beschlossen wurde, welche Dateien es nicht anfassen soll, oder wo das Projekt gerade steht. Das ist kein Fehler — es ist das Design dieser Systeme.

Das tiefere Problem: Entscheidungen, die im Chat versinken

Die technische Grenze des Kontextfensters ist handhabbar. Das tiefere Problem ist ein anderes: Es gibt meist keinen Ort, an dem Projektentscheidungen, der aktuelle Stand und die wichtigsten Einschränkungen festgehalten werden — außerhalb von Chats.

Die Folge ist ein typischer Ablauf: Man öffnet eine neue Session, erklärt das Projekt von vorn, referenziert Entscheidungen aus dem Gedächtnis, gibt dem Modell den aktuellen Stand durch. Das kostet Zeit — und führt zu Inkonsistenzen, wenn man Details vergisst oder den Stand ungenau beschreibt.

Was ein Projektkontext-Dokument ist

Die Idee: eine Datei, die außerhalb jedes Chats lebt

Ein Projektkontext-Dokument ist eine einfache Textdatei — meist Markdown — die das Wichtigste über ein Projekt zusammenfasst: Was wird gebaut, für wen, was ist das aktuelle Ziel, was wurde bereits entschieden, was darf nicht geändert werden, was ist der nächste sinnvolle Schritt.

Diese Datei lebt nicht in einem Chat. Sie liegt im Projektordner. Man referenziert sie zu Beginn jeder relevanten Session, lädt sie hoch oder fügt ihren Inhalt als Kontext ein. Das Modell bekommt sofort den Stand — ohne lange Erklärungen.

Worin sich ein Projektkontext von einem System-Prompt unterscheidet

Ein System-Prompt ist eine Instruktion, die dem Modell sagt, wie es sich verhalten soll: Ton, Rolle, Format. Er ist generisch und wird bei vielen Projekten gleich verwendet.

Ein Projektkontext ist projektspezifisch. Er beschreibt ein konkretes Vorhaben, seinen aktuellen Stand und seine Grenzen. Er ändert sich mit dem Projekt — ein System-Prompt typischerweise nicht. Beides kann kombiniert werden; sie lösen aber unterschiedliche Probleme.

Was ein KI-Projektkontext enthält

Die sechs Kernfelder

Ein einfacher Projektkontext für die KI-Arbeit braucht kein aufwändiges Format. Sechs Felder decken den Großteil der täglichen Arbeit ab:

Wie ein ausgefüllter Projektkontext in der Praxis aussieht, zeigt das fiktive Beispielprojekt FeedbackPing:

Was nicht hineingehört

Nicht alles, was zum Projekt gehört, gehört in den Projektkontext. Folgendes macht die Datei unübersichtlich und untergräbt ihren Zweck:

• Vollständige Codeausschnitte oder ganze Dateiinhalte — gehören in die konkrete Aufgabe, nicht in den Kontext.
• Gesprächsprotokolle aus vorigen Sessions — werden schnell unübersichtlich und veralten.
• Allgemeine Formatierungsregeln — gehören in den System-Prompt.
• Sensible Daten wie API-Keys oder Zugangsdaten — dürfen nie in eine Datei, die als Kontext übergeben wird.

Das zweite Problem — Entscheidungen dokumentieren

Warum Entscheidungen aus dem Chat-Verlauf verschwinden

Jedes Projekt baut auf Entscheidungen. Manche entstehen aus einer KI-Session heraus — nach dem Abwägen von Optionen, nach einer Einschätzung des Modells. Diese Entscheidungen verschwinden im Chat-Verlauf.

In einer späteren Session fragt man das Modell neu — oder erinnert sich ungenau. Das führt zu Inkonsistenzen: Die Datenbankstruktur sollte unveränderlich sein, aber das Modell weiß das nicht. Das Bezahlsystem ist bereits gewählt — aber nicht festgehalten. Eine Funktion wurde aus gutem Grund aus dem Scope gestrichen — aber in der nächsten Session wird sie neu vorgeschlagen.

Das Gründer-Entscheidungslog: eine Datei für das, was nicht verloren gehen darf

Die Lösung ist eine separate Datei: FOUNDER_DECISIONS.md. Sie hält jede wichtige Entscheidung fest — mit Begründung und Datum.

Ein Beispiel aus dem Beispielprojekt FeedbackPing:

DR-0001: Eine Frage statt Survey — mit optionalem Kommentarfeld
Begründung: Maximale Einfachheit für den ersten Test;
            Kommentarfeld gibt Kontext ohne Pflicht.
Stand: umgesetzt

Jede KI-Session, die eine dieser Entscheidungen betrifft, bekommt die Datei als Kontext. Das Modell kennt den Stand und fragt nicht neu nach — es arbeitet mit dem, was bereits beschlossen wurde.

Warum der modellunabhängige Ansatz wichtig ist

ChatGPT Projects und Memory: was sie können und was nicht

ChatGPT Projects und Memory sind nützliche Features. Sie ermöglichen, Chat-Verläufe und Notizen innerhalb von ChatGPT persistent zu halten. Für reine ChatGPT-Workflows kann das ausreichen.

Aber sie haben eine strukturelle Grenze: Beide funktionieren nur innerhalb von ChatGPT. Wer Claude für Implementierungsarbeit und ChatGPT für Strategiegespräche nutzt, hat zwei getrennte Kontextsilos. Claude weiß nicht, was in ChatGPT Projects steht. Eine Entscheidung aus der letzten ChatGPT-Session ist Claude unbekannt.

Ein System, das mit Claude, ChatGPT und Codex gleich funktioniert

Eine Markdown-Datei funktioniert mit jedem Tool. Sie wird in Claude hochgeladen, in ChatGPT als Text eingefügt, von Codex als Projektdatei gelesen. Das Format ist universell — keine API, kein Abo, keine Plattform.

Das ist kein Kompromiss gegenüber einem Tool-eigenen System — es ist ein Vorteil. Wer heute Claude verwendet und morgen ein anderes Modell ausprobiert, muss seinen Projektkontext nicht neu aufbauen. Die Datei bleibt. Die Entscheidungen bleiben. Der Stand bleibt.

Das AI Founder Kit: Projektkontext als Kernstück

Was das Kit enthält

Das AI Founder Kit enthält vorgefertigte Vorlagen für genau diesen Workflow: PROJECT_CONTEXT.md, FOUNDER_DECISIONS.md, START_HERE_FOR_HUMAN.md und START_HERE_FOR_AI.md. Kein Account, kein Abo — lokale Dateien im Projektordner. Die Kit-Dateien selbst sind auf Englisch, damit sie mit allen gängigen Modellen zuverlässig funktionieren.

START_HERE_FOR_HUMAN.md erklärt, in welcher Reihenfolge das Projekt einzurichten ist und was in der ersten Woche zu tun ist. START_HERE_FOR_AI.md ist die Einstiegsdatei für die KI: Sie erklärt dem Modell, wie das Projekt strukturiert ist, welche Regeln gelten und wo es weitermachen soll.

Wie Startdateien den Loop schließen

Der typische Ablauf ohne Struktur: Man öffnet eine neue Session, erklärt den Stand, macht Fehler, weil das Modell den Kontext nicht hatte.

Der Ablauf mit dem Founder Kit: Man öffnet eine neue Session, gibt START_HERE_FOR_AI.md als Kontext, das Modell kennt das Projekt und beginnt dort, wo man aufgehört hat. Das ist keine Magie — es ist Struktur. Die Datei ersetzt nicht das Denken. Sie stellt sicher, dass der Stand festgehalten ist, bevor man anfängt zu arbeiten.

Wer später mehrere KI-Tools koordinieren möchte, kann auf das Modell-Routing oder den vollständigen Workflow aufbauen, der beide Ebenen verbindet. Die vorgelagerte Frage — welches KI-Modell für welche Aufgabe sinnvoll ist — behandelt ein eigener Entscheidungsrahmen.