doubt-driven-development

Wenn Sie im Begriff sind, unter Unsicherheit eine architektonische Entscheidung zu treffen

Wenn Sie im Begriff sind, nicht-trivialen Code zu committen

Wenn Sie im Begriff sind, eine nicht offensichtliche Behauptung aufzustellen („das ist sicher“, „das ist skalierbar“, „das entspricht der Spezifikation“)

Wenn Sie an Code arbeiten, den Sie nicht vollständig verstehen

Wann man es NICHT verwenden sollte:

• Mechanische Vorgänge (Umbenennen, Formatieren, Verschieben von Dateien)
• Befolgung einer klaren, eindeutigen Anweisung des Benutzers
• Vorhandenen Code lesen oder zusammenfassen
• Einzeilige Änderungen, deren Richtigkeit offensichtlich ist
• Reine Tool-Operationen (Tests ausführen, Dateien auflisten)
• Der Benutzer hat ausdrücklich Geschwindigkeit vor Überprüfung gefordert

Wenn man jeden Tastenanschlag anzweifelt, bringt man nichts auf den Markt. Diese Fertigkeit gilt nur für nicht-triviale Entscheidungen, wie sie oben definiert wurden.

Ladeeinschränkungen

Diese Fähigkeit ist für den Koordinator der Hauptsitzung konzipiert, wobei Schritt 3 (ZWEIFEL, siehe unten) einen Prüfer mit neuem Kontext hervorbringen kann.

• Fügen Sie diese Fähigkeit NICHT zu den Fähigkeiten einer Persona hinzu : frontmatter. Eine Persona, die Schritt 3 befolgt, würde eine weitere Persona erstellen – das Orchestrierungs-Anti-Muster, das in references/orchestration-patterns.md ausdrücklich verboten ist („Personas rufen keine anderen Personas auf“).
• Sollten Sie diese Fähigkeit aus dem Kontext eines Unteragenten heraus anwenden (wo der Claude-Code das Erzeugen verschachtelter Unteragenten verhindert): Der bevorzugte Weg ist, dem Nutzer deutlich zu machen, dass „doubt-driven“ nicht verschachtelt ausgeführt werden kann, und die Hauptsitzung damit umgehen zu lassen. Nur als letzter Ausweg gibt es einen eingeschränkten Fallback mit Selbstbefragung – schreibe ARTIFACT + CONTRACT als neue Selbstabfrage um, wobei du eine klare mentale Trennung von deiner vorherigen Argumentation vornimmst, und gehe die Schritte 1–5 durch. Dies ist keine Überprüfung in einem neuen Kontext (Sie nehmen Ihren eigenen Kontext mit), kennzeichnen Sie das Ergebnis daher als „eingeschränkt“ und bevorzugen Sie eine Eskalation, sobald der Nutzer erreichbar ist.

Der Prozess

Kopieren Sie diese Checkliste, wenn Sie die Fertigkeit anwenden:

Zweifel-Zyklus:
- [ ] Schritt 1: BEHAUPTUNG — Behauptung formuliert + Begründung, warum sie wichtig ist
- [ ] Schritt 2: EXTRAKT — Artefakt + Vertrag isoliert, Argumentation entfernt
- [ ] Schritt 3: ZWEIFEL — Prüfer mit „Fresh-Context“ und kontradiktorischer Eingabeaufforderung hinzugezogen
- [ ] Schritt 4: ABGLEICH – alle Ergebnisse anhand des Artefakttextes klassifiziert
- [ ] Schritt 5: BEENDEN – Stoppbedingung erfüllt (triviale Ergebnisse, 3 Zyklen oder Übersteuerung durch den Nutzer)

Schritt 1: CLAIM — Aufzeigen, was gilt

Beschreiben Sie die Entscheidung in zwei oder drei Zeilen:

BEHAUPTUNG: „Die neue Caching-Schicht ist unter der
        in der Spezifikation beschriebenen leseintensiven Arbeitslast threadsicher.“
WARUM DAS WICHTIG IST: Ein Race-Condition führt hier zur Beschädigung von Benutzerdaten und ist
                  im QA schwer zu erkennen.

Wenn Sie die Aussage nicht so prägnant formulieren können, handelt es sich um eine Vermutung, nicht um eine Entscheidung. Bringen Sie sie zur Sprache, bevor Sie sie genauer unter die Lupe nehmen.

Schritt 2: EXTRAHIEREN – Kleinste überprüfbare Einheit

Ein Prüfer, der den Kontext noch nicht kennt, benötigt das Artefakt und den Vertrag, nicht den Entstehungsprozess.

• Code: der Diff oder die Funktion – nicht die gesamte Datei
• Entscheidung: Der Vorschlag in 3–5 Sätzen plus die Einschränkungen, die er erfüllen muss
• Behauptung: die Behauptung sowie die Beweise, die sie angeblich stützen (im Unterschied zum CLAIM-Block aus Schritt 1, bei dem es sich um die zu prüfende Hypothese des Orchestrators handelt)

Reduzieren Sie Ihre Argumentation auf das Wesentliche. Wenn Sie Schlussfolgerungen vorlegen, erhalten Sie im Gegenzug eine Bestätigung Ihrer Schlussfolgerungen. Die Einheit muss so klein sein, dass ein Prüfer sie beim ersten Lesen im Blick behalten kann – handelt es sich um einen Pull-Request mit 500 Zeilen, zerlegen Sie ihn zunächst.

Schritt 3: ZWEIFEL – Beziehen Sie den Prüfer mit einem unvoreingenommenen Blick ein

Die Aufforderung an den Prüfer muss kontrovers sein. Die Formulierung bestimmt die Antwort.

Kritische Überprüfung. Finde heraus, was an diesem Artefakt falsch ist.
Gehe davon aus, dass der Autor zu selbstsicher ist. Achte auf:
- Unausgesprochene Annahmen
- Nicht behandelte Randfälle
- Versteckte Kopplungen oder gemeinsam genutzte Zustände
- Möglichkeiten, wie der Vertrag verletzt werden könnte
- Bestehende Konventionen, gegen die dies verstoßen könnte
- Fehlermodi bei unerwarteten Eingaben

Validieren Sie NICHT. Fassen Sie NICHT zusammen. Finden Sie Probleme oder geben Sie
ausdrücklich an, dass Sie nach gründlicher Prüfung keine finden können.

ARTEFAKT: 
VERTRAG: 

Geben Sie NUR das ARTEFAKT + den VERTRAG weiter. Geben Sie die BEHAUPTUNG NICHT weiter. Wenn Sie dem Prüfer Ihre Schlussfolgerung mitteilen, beeinflussen Sie ihn in Richtung Zustimmung. Der Prüfer muss unabhängig feststellen, ob das Artefakt den Vertrag erfüllt.

In Claude Code beginnen die rollenbasierten Prüfer in „agents/“ konzeptionell mit einem isolierten Kontext und können hier verwendet werden – siehe „agents/“ für die Liste und die domänenbezogene Zuordnung.

Die obige adversarische Eingabe hat Vorrang vor der Standardantwortform der Persona. Personas wie „code-reviewer“ sind so programmiert, dass sie ausgewogene Urteile mit sowohl Stärken als auch Schwächen liefern; bei Zweifel ist eine Ausgabe erforderlich, die ausschließlich Probleme aufzeigt. Fügen Sie die adversarische Eingabeaufforderung wörtlich in den Aufruf ein, damit sie die Standardeinstellung der Persona überschreibt. Wenn die Antwortform einer Persona nicht sauber überschrieben werden kann, greifen Sie auf einen generischen Unteragenten mit der adversarischen Eingabeaufforderung zurück.

Modellübergreifende Eskalation

Ein auf ein einzelnes Modell beschränkter Prüfer hat dieselben blinden Flecken wie der ursprüngliche Autor – ein „kälteres“ Modell mit einer anderen Architektur deckt diese auf. „Doubt-driven“ ist bei nicht-trivialen Entscheidungen bereits standardmäßig aktiviert; daher ist das Angebot einer modellübergreifenden Eskalation in diesem Rahmen Teil des Mehrwerts der Skill und keine optionale Reibstelle.

Interaktive Sitzungen: immer anbieten. Niemals stillschweigend überspringen.

Schritt 1: Fragen Sie den Nutzer

Nach der Überprüfung des Einzelmodells in Schritt 3 oben, aber vor „RECONCILE“, halten Sie inne und fragen Sie:

„Die Überprüfung eines einzelnen Modells ist abgeschlossen. Möchten Sie eine modellübergreifende Zweitmeinung einholen? Optionen: Gemini CLI, Codex CLI, manuelle externe Überprüfung (Sie fügen den Text an anderer Stelle ein) oder überspringen.“

Diese Frage ist in jedem interaktiven Zweifelzyklus obligatorisch – selbst bei Artefakten, bei denen es um wenig zu gehen scheint. Der Nutzer – nicht der Agent – entscheidet, ob sich der Aufwand lohnt. Die Aufgabe des Agenten besteht darin, die Wahlmöglichkeit aufzuzeigen.

Schritt 2: Wenn der Nutzer eine CLI wählt – überprüfen, dann ausführen

1. Überprüfen Sie, ob das Tool im PATH enthalten ist (welches „gemini“, welcher „codex“).
2. Testen Sie, ob es funktioniert (gemini --version oder gleichwertig), bevor Sie die vollständige Eingabeaufforderung weitergeben – eine veraltete oder defekte Binärdatei könnte den Test bestehen, bei echter Eingabe jedoch fehlschlagen.
3. Bestätigen Sie den genauen Aufruf mit dem Benutzer, einschließlich erforderlicher Flags, Authentifizierung und Umgebungsvariablen (z. B. API-Schlüssel). Implementierungen variieren; gehen Sie niemals von einer bestimmten Vorgehensweise aus.
4. Übergeben Sie ausschließlich ARTIFACT + CONTRACT + die adversarische Eingabeaufforderung. Kein Sitzungskontext, kein CLAIM.
5. Achte auf Shell-Escaping. Wenn das Artefakt Anführungszeichen, $(...) oder Backticks enthält, verwende lieber stdin (echo … | gemini) oder ein Heredoc anstelle von inline -p "…". Im Zweifelsfall bitte den Benutzer, den Aufruf zu bestätigen, bevor du ihn ausführst.
6. Übergeben Sie die Ausgabe an Schritt 4 (RECONCILE).

Interpolieren Sie das Artefakt niemals in ein durch Shell-Anführungszeichen umschlossenes Argument. Code-, Markdown- und Review-Eingabeaufforderungen enthalten regelmäßig Backticks, $(...) und Anführungszeichen, die entweder die Eingabeaufforderung abschneiden oder eingebettete Shell-Befehle ausführen. Schreiben Sie die vollständige Eingabeaufforderung in eine Datei und leiten Sie sie über stdin weiter.

Beispielformen (überprüfen Sie die Flags anhand Ihres installierten Tools – die Syntax unterscheidet sich je nach Implementierung und Version):

# Schreibe zunächst die adversarische Eingabeaufforderung + ARTIFACT + CONTRACT in eine temporäre Datei.
# Leite sie dann über stdin weiter, damit Shell-Metazeichen im Artefakt inaktiv bleiben.

# Codex (die schreibgeschützte Sandbox verhindert, dass die CLI in Ihren Arbeitsbereich schreibt):
codex exec --sandbox read-only -C  - < /tmp/doubt-prompt.md

# Gemini („--approval-mode plan“ ist schreibgeschützt; „-p ""“ löst den nicht-interaktiven
# Modus aus und die Eingabeaufforderung wird aus der Standard-Eingabe gelesen):
gemini --approval-mode plan -p "" < /tmp/doubt-prompt.md

Eine schreibgeschützte Sandbox ist das entscheidende Detail: Ein „Doubt“-Artefakt kann selbst Anweisungen enthalten (absichtliche oder versehentliche Eingabe einer Eingabeaufforderung), die die modellübergreifende CLI andernfalls in Ihrem Arbeitsbereich ausführen würde.

Schritt 3: Falls die CLI nicht verfügbar ist oder fehlschlägt

Machen Sie den Fehler explizit sichtbar. Bieten Sie folgende Optionen an: manuelle Ausführung, Versuch mit einem anderen Tool oder Überspringen. Weichen Sie nicht stillschweigend auf den Einzelmodell-Modus aus – der Benutzer sollte wissen, dass der modellübergreifende Modus nicht ausgeführt wurde.

Schritt 4: Wenn der Benutzer den Schritt überspringt

Bestätigen Sie das Überspringen in der Ausgabe („Weiter mit den Ergebnissen für ein einzelnes Modell“) und fahren Sie mit RECONCILE fort. Das Überspringen ist in Ordnung; stillschweigendes Überspringen hingegen nicht.

Nicht-interaktive Kontexte (CI, /loop, autonomous-loop, geplante Läufe):

• „Cross-Model“ wird übersprungen, und das Überspringen muss in der Ausgabe angekündigt werden: „Cross-Model übersprungen: nicht-interaktiver Kontext.“
• Rufen Sie niemals eine externe CLI ohne ausdrückliche Benutzerautorisierung auf – dies ist eine tragende Sicherheitseigenschaft.

„Cross-Model“ verursacht zusätzliche Kosten, Latenz und eine geringere Ausfallsicherheit der Tools. Der Agent stellt die Wahl in jedem Zyklus zur Verfügung; der Benutzer entscheidet, ob dieses Artefakt dies rechtfertigt.

Schritt 4: ABSTIMMUNG – Ergebnisse zurückführen

Das Ergebnis des Prüfers sind Daten, kein Urteil. Sie sind weiterhin der Koordinator. Lesen Sie den Text des Artefakts vor der Klassifizierung noch einmal im Lichte jedes einzelnen Befunds durch – das blinde Absegnen des Prüfers ist derselbe Fehler wie das Ignorieren seiner Ergebnisse.

Klassifizieren Sie jeden Befund in dieser Prioritätsreihenfolge (die erste passende Klasse gewinnt):

1. Falsche Auslegung des Vertrags – Der Prüfer hat etwas speziell deshalb markiert, weil der von dir bereitgestellte VERTRAG unklar oder unvollständig war. Korrigiere zuerst den Vertrag und klassifiziere im nächsten Zyklus erneut.
2. Gültig + umsetzbar – echtes Problem, das eine Änderung am Artefakt erfordert. Nehmen Sie die Änderung vor und wiederholen Sie den Zyklus.
3. Gültiger Kompromiss – Das Problem ist real, aber die Kosten für die Behebung übersteigen die Kosten für die Akzeptanz. Dokumentieren Sie den Kompromiss explizit, damit der Nutzer ihn sieht.
4. Störsignal – Der Prüfer hat etwas markiert, das im Kontext, der ihm fehlte, eigentlich korrekt ist. Notieren Sie dies, fahren Sie fort und fragen Sie sich: Hätte die Aufnahme dieses Kontexts in den Vertrag die fälschliche Markierung verhindert?

Ein neuer Prüfer kann sich irren, weil ihm der Kontext fehlt. Schieben Sie die Entscheidung nicht auf, nur weil er „neu“ ist.

Schritt 5: STOP – Begrenzte Schleife, keine Rekursion

Halten Sie an, wenn:

• die nächste Iteration nur noch triviale oder bereits berücksichtigte Ergebnisse liefert oder
• 3 Zyklen abgeschlossen sind (an den Nutzer weiterleiten, nicht alleine einen vierten durchziehen), oder
• der Nutzer ausdrücklich sagt: „Veröffentliche es!“

Wenn der Prüfer nach drei Durchläufen immer noch wesentliche Probleme aufzeigt, ist das Artefakt möglicherweise noch nicht fertig. Weisen Sie den Nutzer darauf hin – drei ungelöste Durchläufe sind eine Information über das Artefakt, kein Grund, die Schleife endlos fortzusetzen.

Falls 3 Durchläufe „offensichtlich unzureichend“ sind, weil das Artefakt zu umfangreich ist: Das Artefakt ist zu groß – kehre zu Schritt 2 zurück und zerlege es. Hebe die Begrenzung nicht auf.

Häufige Rechtfertigungsargumente

Warnsignale

• Das Starten eines Reviewers mit neuem Kontext für eine einzeilige Umbenennung oder Formatierungsänderung
• Die Ausgabe des Prüfers als verbindlich betrachten, ohne den Text des Artefakts erneut zu lesen
• Mehr als drei Durchläufe, ohne den Nutzer einzubeziehen
• Den Prüfer mit der Frage „Ist das in Ordnung?“ anstelle von „Finde Fehler“ auffordern
• Unter Zeitdruck bei einer Entscheidung mit hohen Risiken Zweifel außer Acht lassen
• Erneutes Starten eines „Fresh-Context“-Reviews bei einem unveränderten Artefakt (Sie erhalten dieselben Ergebnisse; Sie verzögern nur den Prozess)
• Zweifelstheater (überprüfbares Signal): Über zwei oder mehr Zyklen hinweg, in denen der Prüfer wesentliche Befunde aufgedeckt hat, wurde kein einziger Befund als umsetzbar eingestuft. Du validierst, statt zu zweifeln. Hör auf und eskalieren.
• Erst nach dem Commit zweifeln – das ist /review, keine zweifelgetriebene Entwicklung
• Festkodierung eines externen CLI-Aufrufs, ohne beim Nutzer zu bestätigen, dass das Tool existiert, konfiguriert ist und genau diese Syntax akzeptiert
• Das stillschweigende Überspringen von „Cross-Model“ in einem interaktiven Zweifelzyklus. Auch wenn es nicht empfohlen wird, muss das Angebot sichtbar sein. Überspringen ist in Ordnung; stillschweigendes Überspringen ist es nicht.
• Stilles Zurückgreifen auf eine Ausweichlösung, wenn eine externe CLI einen Fehler ausgibt oder fehlt – den Fehler sichtbar machen und den Nutzer die Weiterleitung vornehmen lassen
• Den Vertrag aus der Eingabe des Prüfers entfernen
• Weiterleitung der BEHAUPTUNG an den Prüfer (Tendenz zur Zustimmung)

Interaktion mit anderen Skills

• code-review-and-quality / /review: komplementär. /review ist eine nachträgliche PR-Beurteilung; „doubt-driven“ erfolgt während des Prozesses bei jeder einzelnen Entscheidung. Verwenden Sie beides.
• source-driven-development: SDD überprüft Fakten über Frameworks anhand offizieller Dokumentationen. „Doubt-driven“ überprüft Ihre Argumentation bezüglich des Artefakts. SDD prüft, ob die API existiert; „Doubt-driven“ prüft, ob Sie sie gemäß der Vereinbarung korrekt verwendet haben.
• test-driven-development: Der RED-Schritt bei TDD ist konkretisierter Zweifel – ein fehlgeschlagener Test ist ein Versuch der Widerlegung. Wenn TDD angewendet wird, ist dieser fehlgeschlagene Test der Zweifelsschritt für Verhaltensaussagen.
• Debugging und Fehlerbehebung: Wenn der Prüfer einen echten Fehlermodus aufdeckt, greifen Sie auf die Debugging-Kompetenz zurück, um den Fehler zu lokalisieren und zu beheben.
• Regeln zur Repo-Orchestrierung (references/orchestration-patterns.md): Diese Kompetenz orchestriert von der Hauptsitzung aus. Wenn eine Persona eine andere Persona aufruft, handelt es sich um das Anti-Muster B – siehe „Ladeeinschränkungen“ oben.

Verifizierung

Nach der Anwendung der zweifelgetriebenen Entwicklung:

• Jede nicht-triviale Entscheidung (gemäß der obigen Definition) wurde explizit als CLAIM benannt, bevor sie in Kraft trat
• Mindestens eine Überprüfung im neuen Kontext pro nicht-trivialem Artefakt (ein fehlgeschlagener Test, der im RED-Schritt von TDD erzeugt wurde, erfüllt diese Anforderung für Verhaltensaussagen gemäß „Interaktion mit anderen Fähigkeiten“)
• Der Prüfer erhielt ARTEFAKT + VERTRAG – NICHT den ANSPRUCH, NICHT Ihre Begründung
• Die Aufforderung an den Prüfer war kontradiktorisch („Finde Probleme“), nicht validierend („Ist es gut?“)
• Die Ergebnisse wurden anhand des Artefakttextes klassifiziert (nicht einfach abgenickt), wobei folgende Prioritäten galten: Fehlinterpretation des Vertrags / umsetzbar / Kompromiss / Rauschen
• Eine Stoppbedingung wurde erfüllt (triviale Ergebnisse, 3 Zyklen oder Überschreiben durch den Benutzer)
• Im interaktiven Modus wurde dem Nutzer explizit eine modellübergreifende Überprüfung angeboten (unabhängig von der Bedeutung des Artefakts) und die Antwort wurde in der Ausgabe bestätigt
• Im nicht-interaktiven Modus wurde die modellübergreifende Überprüfung übersprungen und das Überspringen angekündigt
• Jedem externen CLI-Aufruf gingen eine PATH-Prüfung, ein Test auf funktionierende Binärdateien, eine Syntaxbestätigung mit dem Benutzer und eine ausdrückliche Autorisierung zur Ausführung voraus