Debrief

Was macht Debrief?

Ein Debrief ist das Instrument eines übergeordneten Meta-Ziels: eines Prozesses, der unsere Prozesse verbessert. Es betrachtet, wie die Person und der Agent zusammengearbeitet haben, mit Belegen, und wandelt die Erkenntnisse in drei Arten von Ergebnissen um: Lehren für den Agenten (Anweisungen, Skills, Workflows, Hooks), Lehren für die Person (wie sie den Agenten besser führen kann) und Änderungen an der Projekteinrichtung. Es ist ehrlich in beide Richtungen und erfindet keine Kritik: eine gut verlaufene Sitzung bekommt einen kurzen Bericht.

Struktur und Regeln wurden in Anlehnung an zwei MIT-lizenzierte Skills übernommen, mit Dank: debrief von Wavez (die vier Prüfgruppen, „jede Erkenntnis zitiert einen Moment“, nichts wird ohne Zustimmung angewendet) und retrospective von florianbuetow (Berichte werden als Historie geführt, frühere Empfehlungen werden geprüft und wiederkehrende Probleme eskaliert, Ursache und Vorschlag pro Erkenntnis). Der Coaching-Abschnitt, die Fünf-Warum-Gewohnheit und das Nutzungsskript sind eigene Bestandteile dieses Skills.

Eingaben

1. Das Gespräch. Die primäre Quelle: Tool-Aufrufe, Fragen und wann sie gestellt wurden, Korrekturen und Bestätigungen durch den Benutzer, Unteragenten-Berichte, Fehler und Wiederholungen. Wenn die Sitzung kompaktiert wurde, geben Sie dies im Bericht an und behandeln Sie die Zusammenfassung als Beleg mit geringerer Aussagekraft; erfinden Sie keine Momente für den nicht einsehbaren Teil.

2. Die Zahlen. Führen Sie das beigefügte Skript für die Nutzung der Sitzung aus: Durchläufe, Tool-Aufrufe nach Namen, Unteragenten und Workflows mit ihren Tokens, verwendete Modelle, Ausgabetokens pro Modell, Zeitspanne, Kompaktierungen. Es liest das Sitzungstranskript unter ~/.claude/projects/<projekt-slug>/ und das Verzeichnis subagents/ daneben. Der Benutzer kann nach einer anderen Sitzung fragen; übergeben Sie dann deren ID.

   python3 ${CLAUDE_PLUGIN_ROOT}/scripts/usage.py            # die aktuelle Sitzung (neuestes Transkript dieses Projekts)
   python3 ${CLAUDE_PLUGIN_ROOT}/scripts/usage.py <sitzungs-id>
   

3. Die Projektunterlagen. Die Anweisungsdateien (CLAUDE.md, AGENTS.md), das Backlog und das Entscheidungsprotokoll, falls das Projekt sie führt, und die Feedback-Erinnerungen des Agenten für dieses Projekt (~/.claude/projects/<projekt-slug>/memory/), sodass ein wiederholter Fehler als Wiederholung erkannt wird.

4. Frühere Debriefs. Die letzten drei Berichte im Berichtsverzeichnis (siehe unten). Notieren Sie zu jeder darin enthaltenen Empfehlung, ob sie umgesetzt wurde, wiederkehrt oder unbekannt ist; ein wiederkehrendes Problem wird in der Schwere eskaliert.

Passen Sie den Aufwand an den Umfang an: eine kurze, saubere Sitzung erhält eine schnelle Durchsicht; eine mehrwöchige Sitzung erhält die volle Behandlung und die fünf Warum zu den größeren Mustern.

Worauf zu achten ist

Arbeiten Sie diese vier Gruppen durch. Zitieren Sie zu jeder Erkenntnis den Moment (was gesagt oder getan wurde, ungefähr wann), erklären Sie, warum es wichtig war, und fragen Sie „warum“ über den Einzelfall hinaus, bis Sie eine Prozessursache oder ein Prinzip erreichen, oder bis die Antwort außerhalb der Kontrolle des Projekts liegt. Halten Sie Beobachtungen und Vorschläge getrennt: eine Beobachtung kann richtig sein, während der vorgeschlagene Lösungsansatz falsch ist.

1. Effizienz. Redundante oder wiederholte Tool-Aufrufe, händisch geschriebene Logik, die ein Skript oder Skill hätte übernehmen sollen, zusätzliche Build- oder Testzyklen, Arbeit, die hätte gebündelt werden können, übersehene oder sich auszahlende Unteragenten, Nacharbeit nach Kompaktierung, Hintergrundarbeit, die mit der Sitzung verloren ging.
2. Zusammenarbeit. Zu früh, zu spät oder gar nicht gestellte Fragen; nicht befolgte Standardanweisungen; wörtlich genommene Beispiele, wo eine Regel gemeint war; Ausführlichkeit; ob der Agent mitgeteilt hat, welche Interpretation einer mehrdeutigen Anfrage er gewählt hat; ob blockierende Fragen tatsächlich blockiert haben.
3. Korrektheit und Disziplin. Behauptungen ohne Belege; erst spät entdeckte Einschränkungen; destruktive oder irreversible Aktionen ohne Bestätigung; übersehene Projektkonventionen; die Fragen „welches Szenario erfordert dies“ und „was hätte dies abgefangen“ wurden übersprungen.
4. Übertragbares. Präferenzen und Entscheidungen, die es wert sind, als Erinnerung oder Projektdokumente gespeichert zu werden; Vorschläge, die ein Skill, ein Workflow, ein Hook, eine feste Regel oder ein Backlog-Eintrag sind; Tools, die die Arbeit erleichtert hätten; Schritte, die beim nächsten Mal automatisiert werden könnten. Zwei handschriftliche Wiederholungen signalisieren ein fehlendes wiederverwendbares Asset.

Dann die beiden Teile, die dieses Skill persönlich machen:

• Coaching für die Person. Wie hätte die Person, die die Prompts schreibt, effektiver sein können? Welche ihrer Handlungen haben am meisten geholfen (benennen Sie sie, damit sie wiederholt werden) und welche haben gekostet (vager Umfang, fehlende Beschriftung eines Beispiels, eine zurückgehaltene Entscheidung, die der Agent brauchte, eine ausgelassene Überprüfung)? Schreiben Sie es der Person direkt, so wie ein Kollege in einer Supervisor-Gruppe: spezifisch, evidenzbasiert, ohne Schmeichelei und ohne Beschönigung.
• Modelle und Aufwand. Aus den Zahlen: Waren das Modell und der Aufwand der Arbeit angemessen? Wohin sind die Tokens geflossen (Hauptschleife, Unteragenten, Workflows), und hätte ein günstigeres Modell oder ein geringerer Aufwand für Teile davon ausgereicht? Wo hat sich ein hoher Aufwand ausgezahlt?

Bericht

Schreiben Sie den Bericht in das Berichtsverzeichnis und zeigen Sie eine kurze Zusammenfassung in der Antwort. Das Verzeichnis ist docs/debriefs/ im aktuellen Repository, wenn das Repository ein docs/-Verzeichnis hat, sonst ~/.claude/debriefs/<projekt-slug>/; der Benutzer kann ein anderes nennen. Dateiname YYYY-MM-DD.md, mit einem Suffix -2, falls bereits eine existiert.

Kurz und dicht: Die lesende Person hat die Sitzung miterlebt, daher erinnert der Bericht eher, als dass er erzählt. Die Nuance liegt in den Belegen und der Ursache, nicht in der Prosa darum herum. Verwenden Sie diese Vorlage:

# Debrief <Datum>: <Worum es in der Phase ging>

Abdeckung: <Was das Debrief einsehen konnte; Kompaktierung vermerkt>. Frühere Debriefs: <Daten oder keine>.

## In fünf Zeilen
- <Was die Phase erreicht hat>
- <Was sie zum Funktionieren gebracht hat>
- <Was gekostet hat>
- <Das Coaching in einer Zeile>
- <Wie viele Vorschläge, und derjenige, der nicht klein ist>

## Zahlen
<Ein Absatz aus dem Skript: Zeitspanne, Durchläufe, Tool-Aufrufe mit den wichtigsten, Ausgabetokens nach Modell, Unteragenten, Kompaktierungen>

## Was gut lief
- **<Zwei-Wort-Label>.** <Der Moment> → <Was es gebracht hat>.

## Was gekostet hat
- 🔴 / 🟡 / 🟢 **<Label>.** <Der Moment, eine Zeile>.
  Ursache: <Die Prozessursache nach dem Fragen nach dem Warum>. <Behoben, oder was noch bleibt.>

## Coaching für <die Person>
Weitermachen: <Die Handlungen, die geholfen haben, als Liste in einer Zeile>.
1. **<Gewohnheit>.** <Beleg> und <was stattdessen zu tun ist>, ein oder zwei Sätze.

## Modelle und Aufwand
<Ein Absatz: angemessen oder nicht, und die Zahlen, die das belegen>

## Vorschläge
| # | Vorschlag | Zielort | Aufwand | Entscheidung |
|---|---|---|---|
Zielorte: AGENTS.md- oder CLAUDE.md-Regel, Erinnerung, Skill, Workflow, Hook, Backlog, der gemeinsame Leitfaden, ein zu übernehmendes Tool.

## Frühere Empfehlungen
| Von | Empfehlung | Status (umgesetzt / wiederkehrend / unbekannt) |

Schwere: 🔴 hat echte Arbeit gekostet oder drohte Schaden anzurichten; 🟡 hat Zeit oder Aufmerksamkeit gekostet; 🟢 eine kleine Gewohnheit.

Regeln

• Nur ein Bericht. Es wird nichts in Anweisungsdateien, Erinnerungen oder das Backlog geschrieben, bis der Benutzer einen Vorschlag genehmigt; wenden Sie dann genau diesen einen an.
• Jede Erkenntnis zitiert einen Moment. Wenn Sie auf keinen zeigen können, lassen Sie die Erkenntnis weg.
• Nicht aufblähen: drei echte Erkenntnisse schlagen zehn aufgeblähte, und „diese Phase ist gut verlaufen“ ist ein gültiges Ergebnis.
• Das Coaching dient dem Nutzen der Person, daher muss es offen sein; es ist standardmäßig auch privat, also halten Sie es aus allem heraus, was die Person nicht teilen wollte.
• Klare, handlungsorientierte Sprache: Schreiben Sie jeden Punkt so, dass eine Person oder ein Agent, der nicht in der Sitzung war, danach handeln könnte. Bezeichnen Sie eine Praxis als Verhalten (was jemand tut und was es bewirkt: „das Ergebnis spezifizieren, nicht die Lösung“), niemals mit einem Spitznamen, den die Sitzung geprägt hat („die zurückgehaltene Lösung“, „Skeptiker“, „nach Augenmaß“); wenn die Abkürzung das Erkennen erleichtert, setzen Sie sie in Klammern hinter die vollständige Form. Der Test: Könnte ein Kollege die Zeile in seinen eigenen Leitfaden kopieren und befolgen?
• Kürze: ein Label in Fettschrift, dann eine Zeile Beleg, dann die Ursache. Wenn eine Erkenntnis einen Absatz braucht, sind es zwei Erkenntnisse oder sie ist noch nicht verstanden. Streben Sie einen Bildschirm pro Abschnitt an.
• Lehren versus Reibung: Eine Lehre ist etwas, das Sie einem anderen Agenten in einem anderen Projekt sagen würden; was nur für diese Sitzung gilt, ist Reibung und geht in die Erkenntnisse ein, nicht in Vorschläge für feste Regeln.