Spec-Driven Context Resets für Coding-Agenten

Lange Coding-Agent-Chats haben einen Geruch.

Am Anfang ist der Agent scharf. Dann wächst der Verlauf. Alte Annahmen bleiben liegen. Neue Entscheidungen vermischen sich mit verworfenen Plänen. Das Modell optimiert plötzlich auf die letzten Nachrichten statt auf das eigentliche Feature.

Die übliche Reaktion ist: mehr Kontext.

Oft ist das genau falsch.

Der bessere Move ist, Kontext bewusst zu resetten, aber die wichtigen Entscheidungen in Dateien zu behalten. Das spannende Muster in sddw, einem spec-driven Workflow für Claude Code, ist nicht nur „erst Specs schreiben, dann Code“. Der Kern ist: Jeder Schritt produziert genau ein dauerhaftes Artefakt. Der nächste Schritt liest nur die relevanten Artefakte in einem frischen, fokussierten Kontextfenster.

So wird der Kontext-Reset vom Notfallknopf zur Engineering-Technik.

Die Kurzfassung

Halte nicht das komplette Feature in einem riesigen Chat am Leben.

Schiebe die Arbeit durch kleine Dateien:

Spec-driven context reset

dauerhafte Dateien ersetzen aufgeblähte Chat-Erinnerung

1. 01
   Requirements
2. 02
   Code-Analyse
3. 03
   Design
4. 04
   Task-Dateien
5. 05
   Eine Task implementieren
6. 06
   Verifikation

Nach jeder Ebene: stoppen. Datei prüfen. Chat löschen. Die nächste Session startet mit dem aktuellen Artefakt und den Projektregeln.

Der Punkt ist Scope-Kontrolle.

Ein Coding-Agent braucht nicht jeden Absatz der alten Diskussion. Er braucht den aktuellen Vertrag: was wahr sein muss, welche Dateien relevant sind und welche Evidenz die Arbeit beweist.

Warum Kontext-Resets helfen

Kontextfenster sind kein neutraler Speicher. Sie sind chaotisches Arbeitsgedächtnis.

Alte Ideen konkurrieren mit neuen Anweisungen. Halb verworfene Optionen bleiben sichtbar. Das Modell kann Details konservieren, die sterben sollten, und Entscheidungen vergessen, die überleben müssten.

Spec-Dateien schaffen eine sauberere Gedächtnisgrenze.

Was die Dateien bewahren

• Requirements bewahren Nutzerziel, Constraints und Akzeptanzkriterien.
• Code-Analyse bewahrt, was das bestehende System wirklich tut.
• Design bewahrt Architekturentscheidungen, bevor Implementierungsdruck entsteht.
• Task-Dateien bewahren eine kleine Ausführungseinheit, die eine frische Agenten-Session abschließen und verifizieren kann.

Aus demselben Grund schreiben gute Teams Tickets, Design-Dokumente, Migrationspläne und ADRs. Coding-Agenten machen den Fehler nur offensichtlicher: Wenn State nur im Chat lebt, zerfällt er.

Der praktische Workflow

Nutze vier Artefakte für jedes Feature, das zu groß für einen sauberen Agenten-Durchlauf wirkt.

.sddw/feature-name/
  requirements.md
  analysis.md
  design.md
  tasks/
    01-first-task.md
    02-second-task.md

Dann läuft die Arbeit so:

1. Lass den Agenten nur requirements.md erzeugen: User Stories, Constraints, Akzeptanzkriterien. Stop.
2. In frischem Kontext: Codebase prüfen und analysis.md schreiben. Stop.
3. In frischem Kontext: design.md schreiben — Ansatz, betroffene Module, Interfaces, Risiken, Verifikationsplan. Stop.
4. In frischem Kontext: Design in Task-Dateien zerlegen. Stop.
5. In frischem Kontext: exakt eine Task-Datei implementieren, die dort genannten Checks ausführen und Lessons oder Blocker zurückschreiben.

Der Prompt zum Stehlen:

Erstelle requirements.md, analysis.md, design.md und Task-Dateien für dieses Feature.
Stoppe nach jeder Datei.
Die nächste Session soll nur die aktuelle Datei, die Projektregeln und die minimal nötigen Source-Dateien lesen.
Jede Implementierungs-Task braucht: Ziel, erlaubte Dateien, Constraints, Verifikationsbefehle und Done-Evidenz.

Die letzte Zeile ist wichtig. Ohne Verifikation werden Specs nur hübschere Vibes.

Was das ersetzt

Mega-Chat vs. Spec-Reset

Ein riesiger Chat

• Alle Entscheidungen leben im Gesprächsverlauf.
• Der Agent sieht alte Pläne und verworfene Optionen.
• Implementierung startet, bevor Architektur geprüft wurde.
• Fortschritt ist nach Kontextverlust schwer fortsetzbar.

Spec-driven reset

• Wichtige Entscheidungen leben in versionierten Dateien.
• Jede Ebene sieht nur das Artefakt, das wirklich zählt.
• Requirements, Analyse und Design können vor Code reviewed werden.
• Ein neuer Agent kann von der aktuellen Task-Datei weitermachen.

Der Reset soll das Modell nicht einfach vergessen lassen. Er entscheidet, was überlebt.

Wo es scheitert

Dieser Workflow kann falsches Denken einfrieren. Wenn requirements.md das Feature missversteht, werden alle späteren Schritte selbstbewusst falsch. Wenn analysis.md einen wichtigen Codepfad übersieht, designt der Agent an der Realität vorbei. Wenn Task-Dateien zu groß sind, hast du wieder dasselbe Kontextproblem — nur mit mehr Markdown.

Darum müssen die Review-Punkte kurz und hart sein:

Den Reset sinnvoll nutzen

Mach

• ✓ Prüfe jede Spec-Ebene, bevor die nächste erzeugt wird.
• ✓ Halte Implementierungs-Tasks klein genug für eine fokussierte Session.
• ✓ Schreibe Verifikationsbefehle und Done-Evidenz direkt in die Task-Datei.
• ✓ Schreibe Lessons zurück, wenn die Implementierung zeigt, dass das Design falsch war.

Lass

• × Für winzige Ein-Zeilen-Fixes verwenden.
• × Generierte Specs als Wahrheit behandeln, ohne sie gegen den Code zu prüfen.
• × Task-Dateien zu vagen Todo-Listen ohne Akzeptanzkriterien machen.
• × Den kompletten Chat „zur Sicherheit“ mitschleppen.

Die Normalmenschen-Version

Das gleiche Muster funktioniert für Renovierung, Behördenkram, Reiseplanung, Hiring oder ein chaotisches Research-Projekt:

requirements → aktuelle Situation → Plan → Tasks → eine Task pro frischem Kontext

Hör auf, AI alles merken zu lassen. Lass sie die Erinnerung schreiben, die bleiben soll. Resette den Rest. Arbeite vom kleinsten nützlichen Artefakt weiter.

Das ist die leise Stärke von spec-driven context resets: nicht mehr Kontext, sondern bessere Grenzen.

Quelle

• sddw: Spec-Driven Development Workflow for Claude Code
• Hacker News Diskussion: Spec-Driven Development Workflow for Claude Code