CR8-OS/retro-bot

Was macht retro-bot?

Ein Skill für leichte agile Retrospektiven zu Claude-Kollaborationssitzungen – um den Arbeitsprozess mit Claude schrittweise kontinuierlich zu verbessern.

Der Kernkreislauf: Nachdem du und Claude ein Stück Arbeit abgeschlossen habt, nehmt ihr euch ein paar Minuten Zeit, um gemeinsam drei Fragen zu beantworten:

• Was lief gut? (damit weitermachen)
• Was lief nicht gut? (Reibung, Nacharbeit, Verwirrung, verschwendete Tokens)
• Was sollten wir ändern? (konkrete Verbesserungen an Skills, Prompts oder Prozessen)

Änderungen werden sofort angewendet, und jede Retrospektive wird als Snapshot in einem dauerhaften Archiv gespeichert. Mit der Zeit entsteht so ein durchgehender Änderungsverlauf davon, wie sich dein Claude-Workflow entwickelt hat – und das summiert sich zu einem Setup, das mit jeder Sitzung spürbar schneller wird.

---

Phase 0 – Archivverzeichnis einrichten (nur beim ersten Durchlauf)

Bevor die Retrospektive beginnt, prüfe, ob ein Retro-Archivverzeichnis konfiguriert wurde. Suche in der Claude.md nach einem Block wie diesem:

## Retro-Bot
archive_dir: [Pfad]

Wenn es bereits gesetzt ist: Fahre direkt mit Phase 1 fort. Keine erneute Frage nötig.

Wenn es nicht gesetzt ist: Frage den Benutzer einmal deutlich:

„Bevor wir beginnen – wo möchtest du Retro-Snapshots speichern? Das ist eine einmalige Einrichtung. Gib mir einen Ordnerpfad (z. B. H:\Meine Ablage\Retros oder ~/Dokumente/retros) und ich werde zukünftig jede Retrospektive automatisch dort speichern.“

Sobald der Benutzer einen Pfad angibt:

1. Füge den folgenden Block zur Claude.md hinzu (erstelle die Datei, falls sie nicht existiert):

   ## Retro-Bot
   archive_dir: [der angegebene Pfad]
   

2. Erstelle das Verzeichnis, falls es nicht existiert
3. Erstelle eine leere retro-log.md in diesem Verzeichnis (siehe Phase 6 für das Format)
4. Bestätige: „Erledigt – Retro-Archiv auf [Pfad] gesetzt. Alle zukünftigen Retros werden dort gespeichert.“

Fahre dann mit Phase 1 fort.

---

Phase 1 – Sitzungskontext lesen

Lies das Sitzungsprotokoll, um zu verstehen, was tatsächlich passiert ist. Wenn deine Umgebung ein Sitzungsprotokoll oder Transkript-Tool bereitstellt, nutze es jetzt, um den vollständigen Verlauf abzurufen. (In Cowork ist dies automatisch verfügbar; in Claude Code verwende /transcript oder ein Äquivalent, falls vorhanden.) Auch ohne das vollständige Protokoll schöpfe aus dem, was du weißt: welche Skills verwendet wurden, welche Dateien erstellt wurden, welches Feedback der Benutzer während der Sitzung gegeben hat, wo Dinge wiederholt werden mussten.

Wenn der Benutzer dieses Skill unmittelbar nach einer Sitzung aufruft, hast du den Kontext bereits. Wenn er es später mit einer Beschreibung aufruft, arbeite damit.

Bitte den Benutzer zu bestätigen, auf welche Sitzung/Arbeit sich die Retrospektive beziehen soll, falls dies nicht klar ist.

---

Phase 2 – Claude eröffnet mit Beobachtungen

Gehe voran. Warte nicht, bis der Benutzer Beschwerden auflistet – teile mit, was dir aufgefallen ist. Dies modelliert gutes Retrospektivenverhalten, zeigt, dass du aufgepasst hast, und bringt oft Dinge zur Sprache, die der Benutzer nicht bewusst registriert hat, aber sofort wiedererkennt.

Formuliere Beobachtungen ehrlich und konkret:

• „Mir ist aufgefallen, dass ich die SOW zweimal neu rendern musste, weil das erste Tabellenformat nicht sauber in Word geöffnet wurde – das ist ein Skill- Konfigurationsproblem, das ich beheben kann.“
• „Du hast mir den Kundenbrief in drei separaten Nachrichten statt in einem Block gegeben – das ist erwähnenswert als Workflow-Muster, das Abläufe verlangsamt.“
• „Der Scope Builder und der SOW Builder haben konsistente Zahlen geliefert – das fühlte sich reibungslos an.“
• „Ich war mir nicht sicher, welches Exportformat du brauchst, bis du es mir zwischendurch gesagt hast – eine kurze Frage zu Beginn hätte eine Rückfrage gespart.“

Halte es bei 3–5 Beobachtungen. Sei direkt, nicht defensiv. Du bist ein Teilnehmer, kein Beobachter.

---

Phase 3 – Benutzereingabe einholen

Nach deiner Eröffnung lade den Benutzer ein, Ergänzungen, Korrekturen oder Widersprüche zu äußern:

„Das sind meine Beobachtungen. Was hast du auf deiner Liste – habe ich etwas übersehen, würdest du etwas anders formulieren, oder gibt es Dinge, die wir unbedingt festhalten sollten?“

Die Reibungspunkte des Benutzers sind oft andere als deine. Er könnte Dinge ansprechen, die verwirrend waren, Probleme mit der Ausgabequalität, die er im Moment nicht erwähnt hat, Prozessärgernisse oder Dinge, die sich großartig angefühlt haben und beibehalten werden sollten. Halte alles fest.

---

Phase 4 – Retro-Board erstellen

Sobald ihr beide beigetragen habt, präsentiere das vollständige Board. Sei konkret – allgemeine Punkte erzeugen keine nützlichen Aktionspunkte.

## ✅ Gut gelaufen
- [konkrete Sache, die reibungslos lief]
- ...

## ❌ Nicht gut gelaufen
- [konkreter Reibungspunkt, Grundursache falls bekannt]
- ...

## 🔚 Verbesserungsideen
- [konkreter Vorschlag, der mit einem „nicht gut gelaufen“-Punkt verknüpft ist]
- ...

Bitte den Benutzer um Bestätigung, bevor du fortfährst:

„Erfasst das alles? Noch etwas hinzuzufügen oder anzupassen, bevor wir überlegen, was wir umsetzen?“

---

Phase 5 – Aktionspunkte zuordnen

Bestimme für jede Verbesserungsidee den Typ und die Priorität:

Typ	Wann verwenden
🔧 Skill-Update	Problem stammt aus den Anweisungen, dem Ausgabeformat oder dem Standardverhalten eines Skills
📋 Projekt-/Sitzungs-Update	Kontext oder Anweisung, die auf ein bestimmtes Projekt, einen bestimmten Kunden oder eine bestimmte Sitzungsart beschränkt ist – nicht global
📝 Claude.md-Update	Fehlender Kontext, der überall und für alle Projekte und Sitzungen gilt
💡 Prozessnotiz	Verhaltensänderung – keine Dateibearbeitung erforderlich, nur eine andere Arbeitsweise
🆕 Neuer Skill	Lücke tritt wiederholt auf und ist groß genug, um einen eigenen Skill zu rechtfertigen

Der entscheidende Unterschied zwischen einem Projekt-/Sitzungs-Update und einem Claude.md-Update ist der Umfang. Wenn der Kontext nur bei der Arbeit an einem bestimmten Projekt, Kunden oder in einer bestimmten Sitzungsart gelten soll, gehört er auf die Projekt-/Sitzungsebene. Wenn er immer und überall für den Benutzer bei jeder Arbeit gelten soll, gehört er in die Claude.md. Eine falsche Zuordnung ist in beide Richtungen kostspielig: zu viel in der Claude.md erzeugt Rauschen und Kontextüberlappungen zwischen Kunden; zu viel in Projektdateien bedeutet, dass du bei jedem Projektwechsel den Kontext neu setzen musst.

Gib für jeden Aktionspunkt an, was sich ändert, wo, warum es wichtig ist und ob es sofort oder später umgesetzt werden soll. Bestätige vor der Umsetzung:

„Hier ist, was ich vorschlage zu ändern. Soll ich loslegen?“

Siehe references/action-item-types.md für detaillierte Anleitungen zu jedem Typ.

---

Phase 6 – Änderungen mit Versionierung anwenden

Wende jeden bestätigten Aktionspunkt mit einem Kopie-zuerst-Versionierungsmuster an – überschreibe die Quelldatei niemals direkt. Die Regel: aktuellen Stand lesen → Bearbeitungen im Speicher anwenden → in eine neue Version schreiben (z. B. SKILL-v1.1.md) → die alte Datei in archive/ behalten. Dies erzeugt einen wiederherstellbaren Verlauf ohne separates Versionierungswerkzeug.

Skill-Updates: Aktuellen Stand lesen → im Speicher anwenden → in neue Version schreiben → alte Datei archivieren → Änderungslogeintrag hinzufügen. Erhöhe die Patch-Version für kleine Korrekturen, die Minor-Version für sinnvolle Ergänzungen und die Major-Version für Architekturänderungen.

Projekt-/Sitzungs-Updates: Identifiziere die richtige Anweisungsdatei für den Umfang der Änderung – das kann eine projektbezogene CLAUDE.md im Repository- oder Ordnerstamm (Claude Code), eine Cowork-Sitzungskonfiguration, eine dauerhafte Briefing-Datei für einen wiederkehrenden Kunden oder individuelle Anweisungen für einen Sitzungstyp sein. Falls die Datei nicht existiert, erstelle sie. Wende das gleiche Kopie-zuerst-Muster wie bei jeder anderen Dateiänderung an.

Häufige Ziele:

• [Projektordner]/CLAUDE.md – wird in jeder Claude-Code-Sitzung für dieses Projekt automatisch geladen
• Eine [Kundenname]-brief.md oder [Projektname]-context.md als dauerhafte Referenzdatei
• Cowork-Sitzungskonfiguration oder System-Prompt
• Claude.ai Benutzerdefinierte Anweisungen (Kontoeinstellungen → „Was sollte Claude über dich wissen?“)

Claude.md-Updates: Aktuellen Stand lesen → neuen Kontext im richtigen Abschnitt hinzufügen → neue Version schreiben → alte Version archivieren. Falls keine Claude.md existiert, erstelle eine.

Prozessnotizen: Dokumentiere sie im Retro-Snapshot (keine separate Datei nötig).

Nach der Anwendung bestätige, was sich geändert hat:

„Erledigt – [Skill-Name] auf v1.1 aktualisiert und eine Notiz zur Claude.md über [Thema] hinzugefügt.“

---

Phase 7 – Retro-Snapshot speichern und Audit-Log aktualisieren

Diese Phase ist obligatorisch – jeder Retro-Durchlauf muss einen gespeicherten Snapshot erzeugen, unabhängig davon, wie viele Aktionspunkte angewendet wurden. Der Snapshot ist die Aufzeichnung; das Audit-Log ist der Datenstrom.

Schritt 1: Retro-Snapshot speichern

Speichere einen vollständigen Retro-Snapshot im konfigurierten archive_dir. Dateinamenformat:

[archive_dir]/JJJJ-MM-TT-[kurzbeschreibung]-retro.md

Beispiel: H:\Meine Ablage\Retros\2026-05-15-dokumentenbau-retro.md

Halte die Beschreibungen kurz (3–5 Wörter, mit Bindestrich verbunden): dashboard-bau, content-entwurf, datenanalyse-q2.

Snapshot-Vorlage

# Retro-Snapshot: [Sitzungsbeschreibung]
**Datum:** JJJJ-MM-TT
**Sitzungstyp:** [SOW-Bau / Datenanalyse / Content / Code / Sonstiges]
**Verwendete Skills:** [kommagetrennte Liste]
**Retro-Format:** [WWW / Start-Stopp-Machen / 4Ls / etc.]

---

## ✅ Gut gelaufen
- [Punkt]

## ❌ Nicht gut gelaufen
- [Punkt]

## 🔚 Besprochene Verbesserungsideen
- [Punkt]

---

## Aktionspunkte & Ergebnisse

| # | Änderung | Typ | Ziel | Status |
|---|---|---|---|---|
| 1 | [Beschreibung] | Skill-Update | [Skill] v1.0 → v1.1 | ✅ Angewendet |
| 2 | [Beschreibung] | Projekt-/Sitzungs-Update | [Projekt-CLAUDE.md / Kundenbrief / Sitzungskonfig] | ✅ Angewendet |
| 3 | [Beschreibung] | Claude.md-Update | Claude.md | ✅ Angewendet |
| 4 | [Beschreibung] | Prozessnotiz | — | 📝 Notiert |
| 5 | [Beschreibung] | Neuer Skill | [Name] | 🔜 Zurückgestellt |

---

## Prozessvereinbarungen
[Alle Verhaltensvereinbarungen, die während dieser Retrospektive getroffen wurden –
Dinge, die beide Parteien beim nächsten Mal anders machen wollen, die aber nicht zu
einer Dateiänderung führen]

## Offene Fragen / Backlog
[Für später notierte Punkte, Dinge, die wiederkommen, oder Folgemaßnahmen aus dieser
Retrospektive]

## Notizen
[Zusätzlicher Kontext, der bewahrenswert ist]

Schritt 2: Audit-Log aktualisieren

Füge nach dem Speichern des Snapshots eine Zeile an die Datei retro-log.md im Archivverzeichnis an. Diese Datei ist der laufende Datenstrom – eine einzige, auf einen Blick erfassbare Aufzeichnung aller jemals durchgeführten Retrospektiven.

retro-log.md-Format (beim ersten Durchlauf mit diesem Header erstellen):

# Retro-Log

Laufende Aufzeichnung aller Retro-Bot-Sitzungen.

| Datum | Sitzung | Angew. | Notiert | Zurückg. | Snapshot |
|---|---|---|---|---|---|

Hänge jede neue Retrospektive als eine Zeile an:

| 2026-05-15 | Dokumentenbau – umfangreiches Angebot | 2 | 1 | 0 | [Link](2026-05-15-angebotsdokument-retro.md) |

• Angew. : Anzahl der Aktionspunkte mit Status ✅ Angewendet
• Notiert: Anzahl der Prozessnotizen (📝 Notiert)
• Zurückg. : Anzahl der als 🔜 Zurückgestellt markierten Punkte

Nach dem Speichern beider Dateien bestätige:

„Retro-Snapshot gespeichert unter [archive_dir]/[Dateiname] und Audit-Log aktualisiert. Du hast jetzt [N] Retros in der Aufzeichnung.“

---

Ton und Geist

• Claude geht voran – teile deine Beobachtungen, bevor du nach denen des Benutzers fragst.
• Sei konkret – „Die .docx-Tabelle wurde nicht richtig dargestellt, weil die Spaltenbreiten fest codiert waren“ ist nützlicher als „Das Dateiformat war falsch.“
• Kleine Änderungen summieren sich – eine 3-zeilige Korrektur, die 10 Minuten pro Sitzung spart, addiert sich schnell.
• Nicht alles muss behoben werden – zwei gut gewählte Änderungen sind besser als acht halbherzige.
• Halte es kurz – Ziel: 10–15 Minuten. Wenn es länger dauert, löst du Probleme in der Retrospektive, anstatt sie zu identifizieren. Hebe das Lösen für Phase 6 auf.

---

Referenzdateien

• references/retro-formats.md – Alternative Formate: 4Ls, Start/Stop/Machen, Wütend/Traurig/Froh, Segelboot. Lies dies, wenn der Benutzer ein anderes Format wünscht oder wenn Abwechslung der Sitzung besser dient als das Standard-WWW.
• references/action-item-types.md – Detaillierte Anleitung zu Skill-Update vs. Claude.md vs. Prozessnotiz vs. neuem Skill. Lies dies, wenn der Typ eines Aktionspunkts nicht eindeutig ist.

---

Änderungslog

Version	Datum	Änderung
v1.0	2026-05-26	Erste Version – vollständiger Retro-Workflow, 6-Phasen-Struktur, Kopie-zuerst-Versionierung, Retro-Berichtsvorlage
v1.1	2026-05-26	Phase 0 zur Einrichtung des Archivverzeichnisses hinzugefügt (einmalige Konfiguration, in Claude.md gespeichert), obligatorisches Speichern von Retro-Snapshots, laufendes Audit-Log (retro-log.md) mit Nachverfolgung der Ergebnisse pro Retro
v1.2	2026-05-26	Projekt-/Sitzungs-Update als eigenen Aktionspunkttyp hinzugefügt – umfasst Projekt-CLAUDE.md, Cowork-Sitzungskonfiguration, Kundenbrief-Dateien und Claude.ai Benutzerdefinierte Anweisungen; Umfangsunterscheidung von der benutzerebenen Claude.md klargestellt
v1.3	2026-05-29	Migration zur Plugin-Struktur (skills/retro-bot/SKILL.md), .claude-plugin/plugin.json für Claude-Code-Kompatibilität hinzugefügt