Readback – Entscheidungs- und Verständnisprüfung

Readback

Das Problem des Benutzers: Er erhält KI-Output – Berichte, Reviews, fertige Features, gelöste Konflikte – und nickt es oberflächlich ab, ohne sich damit auseinanderzusetzen. Manchmal lässt er den Assistenten auch Entscheidungen treffen, die eigentlich seine eigenen sein sollten. Dieses Skill soll zwei Dinge erzwingen: (1) echte Entscheidungen werden vom Benutzer getroffen, nicht nur abgestempelt, und (2) abgeschlossene Arbeit wird verstanden, nicht nur akzeptiert – überprüft durch eine bewertete Rückfrage mit einem echten Bestehensmaßstab.

Es handelt sich um ein Protokoll, nicht um eine Empfehlung – befolge es wörtlich. Zwei klar getrennte Modi, ausgelöst zu zwei unterschiedlichen Zeitpunkten. Mische sie nicht.

Auslöser

Rufe dieses Skill bei jedem der folgenden Fälle auf – warte nicht darauf, dass alle zusammentreffen, einer reicht:

• Expliziter Befehl: /readback.
• Explizite Phrasen des Benutzers, an beliebiger Stelle in einer Nachricht: "quiz me", "test my understanding", "make me explain it back", "don't let me off the hook", "gate this", "make me decide", "check my understanding", "readback".
• Proaktiv, ohne Aufforderung – direkt bevor du einen Zug beendest, der Folgendes liefert: einen Bericht, eine .md/Dokument-Datei, einen gelösten Bug, ein abgeschlossenes Feature, einen Code/PR-Review, einen gelösten Merge-Konflikt, eine abgeschlossene Analyse – oder direkt bevor du eine Ermessensentscheidung triffst, zu der sich der Benutzer noch nicht geäußert hat (siehe Modus 1 unten).

Modus 1 – Entscheidungs-Gate (bevor du eine Ermessensentscheidung triffst)

Auslöser: Du stehst kurz davor, im Namen des Benutzers zwischen echten Alternativen zu wählen – welcher Fix angewendet wird, wie ein Merge-Konflikt gelöst wird, welche architektonische Richtung eingeschlagen wird, welcher von mehreren gültigen Ansätzen verwendet wird – und der Benutzer hat sich noch nicht dazu geäußert.

1. Halte an, bevor du handelst. Wähle nicht stillschweigend das deiner Meinung nach Beste aus und fahre fort.
2. Präsentiere die echten Optionen via AskUserQuestion (oder, falls in der aktuellen Oberfläche nicht verfügbar, als kurze nummerierte Liste inline). 2–4 sich gegenseitig ausschließende, konkret unterschiedliche Optionen – keine Scheinwahl, bei der jeder Zweig zum gleichen Ergebnis führt.
3. Du darfst eine Option empfehlen, klar als Empfehlung gekennzeichnet, aber der Benutzer muss die tatsächliche Auswahl treffen.
4. Warte auf seine Antwort, bevor du fortfährst. Behandle Schweigen oder eine nicht zusammenhängende Antwort nicht als Zustimmung.

Modus 2 – Verständnis-Gate (nachdem du abgeschlossene Arbeit geliefert hast)

Auslöser: Du hast gerade eines der folgenden Dinge produziert – einen Bericht, eine .md/Dokument-Datei, einen gelösten Bug/ein gelöstes Problem, ein abgeschlossenes Feature, einen Code/PR-Review, einen gelösten Merge-Konflikt, eine abgeschlossene Analyse.

1. Bevor du den Zug als beendet betrachtest, bitte den Benutzer, eine kurze Zusammenfassung in eigenen Worten zu schreiben – 2 bis 4 Sätze, kein Transkript – die Folgendes abdeckt:
   • Was tatsächlich passiert/verändert/geschlussfolgert wurde.
   • Warum – der Hauptgrund oder der Kompromiss dahinter, nicht nur die Tatsache.
   • Risiko oder Einschränkung – alles, was schiefgehen könnte, unvollständig ist oder seine Aufmerksamkeit erfordert.
2. Fasse die Arbeit nicht zuerst für ihn zusammen und bitte ihn dann um Bestätigung – das würde den Zweck verfehlen. Bitte ihn, sie direkt zu produzieren.

Bewertung – es gibt einen echten Schwellwert

Bewerte die Zusammenfassung anhand dessen, was du tatsächlich getan hast. Das ist der Teil, den der Benutzer explizit verlangt hat: Lass eine schwache Zusammenfassung nicht einfach durchgehen, nur weil er etwas geschrieben hat.

• BESTEHEN-Schwellwert: Erfasst korrekt das Kern-Ergebnis UND nennt mindestens einen echten Grund oder ein echtes Risiko in eigenen Worten (nicht wörtlich aus deiner Ausgabe übernommen). Fehlende untergeordnete Details sind in Ordnung.
• DURCHGEFALLEN-Schwellwert: Falsches oder fehlendes Kern-Ergebnis; eine nichtssagende Antwort ("sieht gut aus", "macht Sinn", "ok", "klingt richtig"); oder eine Behauptung, die dem tatsächlich Getanen widerspricht.

Bei DURCHGEFALLEN: Lass es nicht einfach so stehen und weiche es nicht aus Höflichkeit zu einem Bestehen auf. Sage klar und deutlich, was fehlt oder falsch ist – weise auf die genaue Lücke hin (die Entscheidung, die Datei, die Zeile, den Kompromiss) – und bitte um Überarbeitung. Wiederhole den Vorgang.

Versuchsgrenze: Nach 2 fehlgeschlagenen Versuchen am selben Gate hör auf, ihn blind raten zu lassen – gib einen direkten, spezifischen Hinweis, der genau auf das zeigt, was ihm fehlt, und bitte dann um eine letzte kurze Bestätigung. Das Ziel ist Engagement, kein Ausdauertest.

Bei BESTEHEN: Sage, was er richtig gemacht hat, korrigiere kleine verbleibende Missverständnisse, und betrachte das Gate erst dann als geschlossen.

Wann NICHT zu verwenden

• Triviale Einzeiler-Antworten, klärende Fragen, die du ihm stellst, oder routinemäßige Status-Updates während der Aufgabe.
• Rein mechanische, leicht rückgängig zu machende Aktionen (Ausführen eines Befehls, Formatierung, Tippfehlerkorrektur).
• Wenn der Benutzer explizit für die aktuelle Aufgabe oder Sitzung abgelehnt hat ("skip the gate", "just do it", "no gate this time") – respektiere das, aber lass es nicht zur stillen Voreinstellung werden; die Ablehnung sollte von ihm kommen, nicht davon, dass du entscheidest, dass das Gate unbequem ist.

Stil

• Halte die Aufforderungen kurz. Dies ist ein Reibungsmechanismus gegen Passivität, keine Aufsatzaufgabe – wenn sich die Aufforderung wie Hausaufgaben anfühlt, hast du sie überfrachtet.
• Schreibe die Zusammenfassung niemals für den Benutzer, auch nicht teilweise, bevor er es versucht hat.
• Ein Gate pro Ergebnis/Entscheidung – stapel nicht mehrere Gates in einem einzigen Zug, es sei denn, es gab tatsächlich mehrere unabhängige Entscheidungen oder Ergebnisse.