Die Spec kommt zuerst.Und du liest sie vor dem Code.

Der Ablauf: Spec, Review, Plan, Review, Aufgaben, Bau

Statt eines großen Prompts und eines Haufens Code läuft die Arbeit über Dokumente, von denen du jedes prüfst, bevor das nächste geschrieben wird.

1. Spec: was und warum

   Was die Funktion tun muss, für wen und was sie nicht tun darf. Noch keine Dateinamen, keine Technikentscheidungen.

2. Plan: wie

   Der Ansatz: welche Teile sich ändern, in welcher Reihenfolge, mit welchen Risiken. Der Plan richtet sich nach der Spec.

3. Aufgaben: kleine Schritte

   Eine Checkliste, die der Agent abarbeiten und abhaken kann, jede Aufgabe klein genug zum Prüfen.

4. Bau

   Erst jetzt schreibt der Agent Code, gegen Dokumente, die du schon gelesen hast.

Eine kurze Spec-Vorlage

Eine Spec muss nicht lang sein. Sechs Überschriften reichen, um die meisten Missverständnisse abzufangen:

# Feature name

## Goal
## Non-goals
## Users
## Requirements
## Edge cases
## Open questions

Non-goals und Open questions werden am häufigsten übersprungen und von Agenten am meisten gebraucht. Ein Agent, dem gesagt wird, was er nicht bauen soll und was noch offen ist, fragt nach, statt zu raten.

Umsetzung in Claude Code, Codex und Cursor

Alle drei können die Dokumente schreiben, und jeder hat für den Planungsschritt einen Plan Mode: Plan Mode von Claude Code, Plan Mode von Codex und Plan Mode von Cursor.

Damit das Review automatisch kommt, schreibe eine Regel in CLAUDE.md oder AGENTS.md: Nach dem Schreiben einer Spec oder eines Plans schickt der Agent sie dir mit request_review in DotMD und wartet. Der Agent hält dann nach jedem Dokument an und wartet auf deine Kommentare oder deine Freigabe, ohne dabei Tokens zu verbrauchen. DotMD kann die Regel für dich eintragen: siehe CLAUDE.md und AGENTS.md.

Review, das mitwächst

Der Chat ist ein schlechter Ort, ein Dokument zu prüfen. Stattdessen liest du die Spec gerendert in DotMD, markierst die falsche Passage und drückst ⌥⌘M. Der Kommentar ist an seine Zeilen gebunden, der Agent weiß also genau, was du meinst. Du kannst erst alle Kommentare schreiben und sie einmal senden.

Hat der Agent sie umgesetzt, steht jede Änderung in der Datei: alter Text rot, neuer Text grün, neben dem Kommentar, auf den sie antwortet. Wähle bei jeder Accept oder Reopen. DotMD listet auch die Änderungen, um die niemand gebeten hat. Siehe Änderungen prüfen.

Für eine zweite Meinung lass zuerst einen anderen Agenten prüfen. Eine Spec von Claude Code, kommentiert von Codex, erreicht dich mit den offensichtlichen Lücken schon markiert, und du entscheidest, welche Anmerkungen der Schreiber bekommt: Agent prüft Agent.

Werkzeuge für Spec-driven Development

• Reines Markdown im Repo. Ein Ordner docs/specs und die Vorlage oben sind eine vollständige Einrichtung.
• Plan Modes. Die eigene Art jedes Agenten, vor dem Bauen zu planen.
• GitHub Spec Kit. Ein Open-Source-Toolkit, das deinem Agenten Befehle für jeden Schritt gibt und spec.md, plan.md und tasks.md für dich schreibt: GitHub Spec Kit.

Wofür du dich auch entscheidest: Die Dokumente sind Markdown-Dateien, und DotMD liest jedes davon.

Fragen zu Spec-driven Development

Weitere Fragen