Was macht doubt-driven-development?
Unterzieht jede nicht-triviale Entscheidung einer frischen, konträren Prüfung, bevor sie bestehen bleibt. Verwenden Sie dies, wenn Korrektheit wichtiger ist als Geschwindigkeit, wenn Sie mit unbekanntem Code arbeiten, wenn die Einsätze hoch sind (Produktion, sicherheitsrelevante Logik, irreversible Operationen) oder immer dann, wenn ein selbstbewusstes Ergebnis billiger zu verifizieren als später zu debuggen wäre.
Wie es funktioniert
- Identifizieren Sie eine nicht-triviale Entscheidung – eine Architekturänderung, einen Datenfluss, eine Fehlerbehandlung, einen Abstraktionsgrenzfall, eine API-Wahl.
- Pausieren Sie. Bevor Sie den nächsten Schritt ausgeben, öffnen Sie eine frische Analyse.
- Überprüfen Sie mit neuem Kontext. Fragen Sie: Gibt es einen besseren Ansatz? Habe ich eine Abhängigkeit übersehen? Was passiert im Randfall X? Ist dies unter Last skalierbar? Der Prüfer kennt das vorherige Gespräch nicht – er sieht nur das Artefakt.
- Wiederholen Sie, bis die Prüfung besteht, oder kehren Sie den Kurs um.
Wann zu verwenden
| Situation | Empfehlung |
|---|---|
| Neues Projekt, geringes Risiko | Überspringen |
| Refactoring einer bestehenden Funktion | DDD anwenden |
| Sicherheitsschicht / Auth-Logik | DDD erforderlich |
| Datenbank-Migration | DDD erforderlich |
| Prototyping / Erkundung | Überspringen |
Implementierungshinweise
- Der Skill wird durch eine Datei
ddd.mdim Projektstamm gesteuert. - Der Agent kann den vollständigen Prompt aus dieser Datei lesen, um den Analyseprozess zu verstehen.
- Während der Ausführung erzeugt der Skill eine temporäre Datei
ddd-review.md, die die Fragen des Prüfers und die Antworten des Autors enthält. - Die endgültige Ausgabe wird in
ddd-log.mdprotokolliert.
Beispielablauf
# Schritt 1: Agent generiert Lösung
Ändern der Abfrage von JOIN zu einer materialisierten Ansicht…
# Schritt 2: DDD auslösen – frischer Kontext
„Überprüfung: Beitritt zu materialisierter Ansicht – erwägen Sie Cache-Invalidierung, Abfrage-Latenz und Betriebskosten.“
# Schritt 3: Agent prüft, erkennt, dass die Ansicht für 90% der Lesevorgänge zu oft aktualisiert wird
# Schritt 4: Agent kehrt zu JOIN zurück, fügt jedoch CQRS mit einem Redis-Cache hinzu
Plattformkompatibilität
Dieser Skill wurde entwickelt für:
- Claude Code (primäre Implementierung)
- Cursor (über benutzerdefinierte Regeln)
- Codex CLI (über System-Prompt-Extension)
Verwandte Skills
- addyosmani/clean-coder-conduct – Richtlinien für professionelles Coder-Verhalten
- addyosmani/code-review-prompt – Strukturierte Code-Review-Prompts