Kamar-Taj (Wong, Dormammu, Agamotto)

Wong – Lernleitfaden zum Tagesende (ehemals tägliches Protokoll)

Verwandle einen ganzen Tag Arbeit mit Claude Code (über alle Sitzungen und Repos hinweg) in eine einzige, datierte Markdown-Datei, geschrieben als Lehrleitfaden, damit der Benutzer die Arbeit wirklich lernen kann: den Code von Hand nachprogrammieren, verstehen, warum jede Entscheidung getroffen wurde, und erklären können, wie es funktioniert, weil er es tatsächlich verstanden hat.

Die Ausgabe ist KEIN Changelog. Es ist ein Lehrbuch für Anfänger – so einfach und gesprächig geschrieben, dass jemand ohne Software-Hintergrund es von vorne bis hinten lesen und sowohl verstehen könnte, was getan wurde als auch warum. Jeder Fachbegriff wird beim ersten Auftreten in einfacher Sprache definiert; Code bleibt technisch, wird aber in einfaches Englisch eingebettet. Tiefe und das „Warum“ sind wichtiger als die Vollständigkeit von Trivia. Siehe die vollständigen Schreibstil – ERFORDERLICH-Regeln in Schritt 4.

Schritt 0. Den Aufwandsgrad aus dem Befehl lesen

Der Benutzer kann einen Aufwandsgrad als erstes Argument übergeben: light, medium oder heavy. Wenn keiner angegeben ist, standardmäßig heavy. (Sie können auch ein Datum übergeben; ein YYYY-MM-DD-Token ist das Datum, ein light/medium/heavy-Token ist der Aufwand. Beide Reihenfolgen möglich, beide optional. Z.B. /wong medium, /wong light 2026-06-25.)

Der Aufwand steuert die Token-Nutzung – er skaliert sowohl die Größe der Zusammenfassung (über --effort beim Sammler) als auch, wie viel du beim Schreiben tust:

• light – am günstigsten. Dokumentiere nur die oberen 2–3 Arbeiten. Führe keine git show/zusätzlichen Dateilesungen aus; verlasse dich auf die Zusammenfassung + Commit-Nachrichten, und füge insgesamt höchstens ein kurzes Code-Snippet ein. Halte jeden Abschnitt kurz. Erstelle trotzdem den Git-Fähigkeiten-Abschnitt, die Slack-Zusammenfassung, das PDF und den Upload.
• medium – ausgewogen. Dokumentiere die oberen ~5 Arbeiten. Rufe echten Code (git show) nur für die 2–3 wichtigsten ab. Mittlere Tiefe.
• heavy (Standard) – die vollständige Behandlung, wie unten beschrieben: jede einzelne Arbeit, rufe echten Code für jede ab, volle Tiefe.

Trage den gewählten Aufwandsgrad durch alle Schritte.

Schritte

1. Das Rohmaterial des Tages sammeln

Führe den Sammler mit dem gewählten Aufwand aus (er liest jedes Sitzungstranskript von der Festplatte, erfasst also alle gleichzeitigen/geschlossenen Sitzungen, nicht nur diese eine):

python3 ~/.claude/skills/wong/collect_day.py --effort heavy

Ersetze heavy mit dem Level aus Schritt 0. Um einen vergangenen Tag zu protokollieren, füge das Datum hinzu: python3 ~/.claude/skills/wong/collect_day.py --effort medium 2026-06-25

Es gibt den Pfad zu einer Zusammenfassungsdatei aus (~/Daily Log/.digest-<date>.md). Lies diese Zusammenfassung vollständig. Sie enthält pro Repo: die Git-Commit-Übersicht des Tages, Statistiken zu uncommitteten Änderungen und pro Sitzung – die Eingabeaufforderungen des Benutzers, die von Claude bearbeiteten Dateien, Claudes erklärende Prosa und etwaige Ergebnisse von Unteragenten.

Lies auch das Glossar unter ~/Daily Log/.glossary.md (wenn es nicht existiert, behandle es als leer). Es listet die trivialen/grundlegenden Begriffe auf, die bereits an früheren Tagen erklärt wurden. Du wirst nichts, was bereits darin steht, NICHT erneut erklären – siehe „Triviale Begriffe nur einmal erklären“ in Schritt 4.

Wenn die Zusammenfassung sagt, dass keine Sitzungen aktiv waren, informiere den Benutzer und stoppe.

2. Unterscheidbare Features/Aufgaben identifizieren

Gruppiere die Arbeit des Tages in unterscheidbare Arbeitspakete, nicht einen Abschnitt pro Sitzung. Führe Sitzungen/Commits zusammen, die dasselbe Feature vorangebracht haben. Ein „Arbeitspaket“ ist etwas, auf das der Benutzer als eine bestimmte Arbeit zeigen könnte (z.B. „der Verto-Agent-Call-Delivery-Bugfix“, „die Predictive-Dialer-Abbruchrate-Obergrenze“). Ziele auf die wenigen Dinge, die tatsächlich wichtig waren; füge keine Trivia hinzu.

3. Den echten Code für jedes Arbeitspaket holen

Aufwandsbremse: bei light überspringe diesen Schritt vollständig (kein git show/Dateilesungen – verwende die Zusammenfassung + Commit-Nachrichten, maximal ein Snippet insgesamt). Bei medium mache dies nur für die 2–3 wichtigsten Arbeitspakete. Bei heavy für jedes Arbeitspaket.

Die Zusammenfassung listet Commit-SHAs und bearbeitete Dateien auf, aber NICHT vollständige Diffs. Für jedes Arbeitspaket, das du dokumentierst, rufe den tatsächlichen Code ab, damit die Snippets echt sind, nicht paraphrasiert:

git -C <repo> show <sha>            # vollständiger Diff für einen Commit
git -C <repo> show <sha> -- <path>  # Diff einer Datei
git -C <repo> diff -- <path>        # nicht committete Arbeit

Oder lies die aktuelle Datei in den relevanten Zeilen. Bevorzuge es, die Schlüsselzeilen (die die Idee tragen) zu zeigen, anstatt ganze Dateien auszugeben.

Konsultiere die CLAUDE.md des Repos und docs/GOTCHAS.md (falls vorhanden) auf Fallstricke, die für die Arbeit relevant sind – sie sind Gold wert für den Abschnitt „Fallstricke & Lektionen“.

4. Den Lehrleitfaden schreiben – INKREMENTELL, niemals überschreiben

Dateinamenformat. Die Datei wird in ~/Daily Log/ gespeichert und wie folgt benannt:

<YYYY-MM> - <DD> - <eine Zeile, was wir an diesem Tag gemacht haben>.md

z.B. 2026-06 - 26 - Fixed agent call delivery and started Yotel 3D landing page.md. Der Einzeiler-Teil ist eine kurze, verständliche Überschrift der Tagesarbeit (keine Bindestriche darin, da die Datumstrenner bereits „ - “ verwenden; halte es unter ~12 Wörtern). Die obere # -Überschrift der Datei muss dasselbe wie der Dateiname ohne .md sein.

Die heutige Datei finden (wichtig für die Anhänge-Logik). Da der Einzeiler variiert, suche niemals nach einer exakten <date>.md. Finde stattdessen die heutige Datei anhand ihres Datumspräfixes – liste ~/Daily Log/ auf und vergleiche die Datei, die mit <YYYY-MM> - <DD> - beginnt (z.B. ls "~/Daily Log/" und wähle die, die mit 2026-06 - 26 - beginnt). Es gibt höchstens eine pro Tag.

Diese Fähigkeit kann mehrmals an einem Tag ausgeführt werden. Bei jeder Ausführung nach der ersten musst du nur die Arbeit hinzufügen, die noch nicht dokumentiert ist – niemals überschreiben oder duplizieren, was vorhanden ist.

Vorgehen:

1. Wenn keine Datei für heute existiert (keine Datei passt zum Datumspräfix): erstelle sie mit der vollständigen Struktur unten (Tagesübersicht + ein Abschnitt pro Arbeitspaket, nummeriert ## 1., ## 2., …), benannt wie oben.
2. Wenn die heutige Datei BEREITS existiert (gefunden über das Datumspräfix): Lies sie zuerst. Erstelle eine Menge dessen, was bereits abgedeckt ist, indem du die vorhandenen ## N. <titel>-Überschriften und die Commit-SHAs / Sitzungs-IDs in jeder Referenzen-Zeile scannst. Identifiziere dann aus der heutigen Zusammenfassung Arbeitspakete, deren Commits/Sitzungen noch nicht in dieser Menge sind.
   • Halte den Einzeiler des Dateinamens für den ganzen Tag korrekt: Wenn die neu hinzugefügte Arbeit die Überschrift des Tages ändern sollte, benenne die Datei um (und aktualisiere ihre # -Überschrift entsprechend), sodass der Einzeiler immer noch alles widerspiegelt, was an diesem Tag getan wurde. Wenn die Überschrift noch passt, lasse den Namen wie er ist.
   • Wenn es nichts Neues gibt, informiere den Benutzer, dass die Datei bereits auf dem neuesten Stand ist, und stoppe (schreibe sie nicht neu).
   • Andernfalls hänge neue ## N.-Abschnitte an (setze die vorhandene Nummerierung fort) nur für die neue Arbeit, unter Verwendung derselben Vorlage pro Feature.
   • Aktualisiere den Tagesübersicht-Block direkt: erhöhe die Commit-/Sitzungszahlen und erweitere die Überschrift, um die neu hinzugefügte Arbeit zu erwähnen. Berühre nicht die vorhandenen Feature-Abschnitte.
   • Verwende Bearbeiten (gezielte Einfügungen), keine vollständige Überschreibung, damit vorherige Abschnitte – einschließlich aller von dir von Hand bearbeiteten – wörtlich erhalten bleiben.

Behandle ein „Arbeitspaket“ als bereits abgedeckt, wenn seine Commit-SHA(s) oder die Sitzungs-ID bereits in der Datei erscheinen. Vergleiche anhand dieser Bezeichner, nicht anhand der Formulierung, damit eine erneute Ausführung niemals einen fast identischen Abschnitt erzeugt.

Schreibstil – ERFORDERLICH (das ist der ganze Sinn)

Schreibe es wie ein Lehrbuchkapitel für einen kompletten Anfänger – jemand Intelligenten, der nichts über Software weiß. Der Leser sollte in der Lage sein, jeden Abschnitt von oben bis unten ohne Vorkenntnisse zu verfolgen.

• Gesprächig und einfach. Kurze Sätze. Einfache Wörter. Erkläre, als würdest du mit einem Freund sprechen, nicht einen Bericht schreiben. Vermeide Fachjargon in der Erzählung.
• Definiere jeden technischen Begriff einmal über die gesamte Serie – nicht einmal pro Tag. Wenn ein Begriff jemals zum ersten Mal auftaucht, definiere ihn in Alltagssprache in einem Blockzitat: > **Was bedeutet "X".** … (verwende Analogien aus der realen Welt). Überprüfe aber zuerst das Glossar (~/Daily Log/.glossary.md) und definiere niemals einen Begriff neu, der bereits dort aufgeführt ist. Dies ist am wichtigsten für triviale, wiederkehrende Grundlagen – was ein Repo/Commit/Branch ist, was Yotel ist, grundlegendes Git – erkläre sie einmal, dann verwende sie einfach. Ein brandneuer Begriff, der wirklich im Mittelpunkt der heutigen Arbeit steht, bekommt trotzdem sein Kästchen; eine Grundlage, die bereits behandelt wurde, nicht. Siehe „Triviale Begriffe nur einmal erklären“ unten für die Mechanik.
• Bleibe nur dort technisch, wo technische Präzision der Punkt ist – z.B. die eigentliche Codeänderung, die genaue Datei, der echte Kompromiss. Zeige den echten Code, aber bette ihn in einfache englische Erklärungen davor und danach ein, und kommentiere das Snippet in einfacher Sprache. Gib niemals einfach nur Code aus.
• Leite jeden Abschnitt mit der "Alltagsversion" ein – die einfache Geschichte, was kaputt/benötigt war und warum es wichtig ist – bevor du ins technische Detail gehst.
• Verwende eine kurze „So lesen Sie dieses Dokument“-Notiz ganz oben und eine „Das große Ganze (zuerst lesen)“-Übersicht, die die Projekte in einfachen Worten erklärt (was ist dieses Produkt, wer nutzt es, warum).
• Halte die „Wie man es erklärt“-Punkte in einfacher, selbstbewusster Ein-Satz-Form, gefolgt von der einen klugen Einsicht, die einfach zu erklären ist.
• Sei ehrlich: Trenne klar zwischen echtem ausgeliefertem Code und Einrichtung/Erkundung, und sage dies in einfachen Worten.

Passe den Ton der aktuellsten vorhandenen Datei in ~/Daily Log/ an (lies sie als Referenzbeispiel, falls eine existiert).

Triviale Begriffe nur einmal erklären (das Glossar)

Ein Leser der gesamten Serie sollte nicht sehen, „was ein Repo ist“ oder „was Yotel ist“ jeden Tag aufs Neue erklärt. Also:

1. Lies vor dem Schreiben ~/Daily Log/.glossary.md (die Liste der bereits erklärten Begriffe). Behandle alles darin als bekannt – schreibe kein > **Was bedeutet "X".**-Kästchen für jeden Begriff auf der Liste. Verwende den Begriff einfach normal.
2. Füge während des Schreibens nur ein Definitionskästchen für einen Begriff hinzu, der wirklich neu in der Serie ist (nicht im Glossar). Sei hart darin, triviale Grundlagen nicht neu zu definieren; wenn du dir bei einer Grundlage unsicher bist, nimm an, dass sie behandelt wurde, und überspringe sie.
3. Aktualisiere nach dem Schreiben/Anhängen ~/Daily Log/.glossary.md: hänge (eine pro Zeile) jeden Begriff an, den du heute zum ersten Mal definiert hast. Entferne niemals vorhandene Einträge. Wenn die Datei nicht existiert, erstelle sie.

Dies gilt vor allem für triviale, wiederkehrende Begriffe (Repo, Commit, Branch, Worktree, was das Produkt ist, grundlegendes Git). Ein komplexer Begriff, der das Herzstück der Arbeit eines Tages ist, kann an diesem Tag trotzdem erklärt werden, aber sobald er im Glossar ist, wird er später nicht noch einmal erklärt.

Vorlage pro Feature und Tagesübersichtsstruktur (passe die Überschriften an die anfängerfreundliche Stimme oben an – dies sind die Inhalte, die abgedeckt werden müssen, keine starren Bezeichnungen, die wörtlich kopiert werden müssen):

# <YYYY-MM> - <DD> - <eine Zeile, was wir an diesem Tag gemacht haben>

> **So lesen Sie dieses Dokument.** (1-2 Sätze, die einem Anfänger sagen, wie er es verwendet.)

## Das große Ganze (zuerst lesen)
Einfache Übersicht, was heute getan wurde. Definiere "Projekt/Repository", "Commit" und was das Produkt (z.B. Yotel) ist **nur, wenn sie nicht bereits im Glossar sind** – d.h. beim allerersten Protokoll. An jedem späteren Tag überspringe diese Grundlagen und den Erklärer "was ist dieses Produkt"; nenne sie einfach und mach weiter.

---

## 1. <Einfacher Titel des Arbeitspakets>   (<repo>)

### Die Alltagsversion
Die Geschichte ohne Fachjargon – was kaputt oder benötigt war und warum es für eine echte Person wichtig ist. Verwende eine Analogie.

### Was wirklich los war / Die Behebung (der technische Teil)
Jetzt das präzise Detail: die eigentliche Ursache, die eigentliche Codeänderung (gezeigt und in einfachem Englisch mit kommentierten Snippets erklärt), der genaue Dateipfad `path`. Setze ein `> **Was bedeutet "Begriff".**`-Kästchen vor jedes neue technische Wort.

### Wie du das selbst machen könntest, Schritt für Schritt
Nummerierte, konkrete Schritte, denen ein Anfänger folgen könnte.

### Wie man es erklärt (wenn du es verstanden hast)
- Eine einfache Zusammenfassung in einem Satz, was die Arbeit tut.
- Die eine kluge Einsicht, einfach erklärt.
- Der Kompromiss, den man verteidigen muss, in Alltagsbegriffen.

### Lektionen, die es wert sind, behalten zu werden
Einfache Erkenntnisse + alle relevanten Fallstricke aus CLAUDE.md / docs/GOTCHAS.md.

**Wo es zu finden ist:** Dateien, Commit-SHA(s), Sitzungs-ID(s).

---

## 2. <nächstes Arbeitspaket…>

---

## Heute verwendete Git-Fähigkeiten
(Immer der LETZTE Abschnitt des Dokuments. Erstellt aus den Blöcken "Von Claude ausgeführte Git-Befehle" in der Zusammenfassung – siehe die speziellen Anweisungen unten.)

### <Git-Operation, z.B. Änderungen committen>   `git commit`
**Was es tat** – in einfachen Worten, was dieser Befehl heute erreicht hat.
**Warum** – warum dieser Schritt zu diesem Zeitpunkt im Arbeitsablauf benötigt wurde.
**Wie du es selbst machst** – der eigentliche Befehl mit einer kurzen Notiz, was jeder Teil und jedes Flag bedeutet, damit der Leser es von Hand ausführen könnte.

### <nächste Git-Operation…>

Der Abschnitt "Heute verwendete Git-Fähigkeiten" – ERFORDERLICH (immer der letzte Abschnitt)

Beende jedes Tagesdokument mit einem ## Heute verwendete Git-Fähigkeiten-Abschnitt, erstellt aus den Blöcken "Von Claude ausgeführte Git-Befehle" in der Zusammenfassung (ein Block pro Sitzung).

So erstellst du ihn:

1. Sammle alle Git-Befehle aus jeder Sitzung in der Zusammenfassung. Ein erfasster Eintrag kann ein zusammengesetzter Befehl sein (z.B. cd repo && git add ... && git commit ...); extrahiere den/die Git-Teil(e).
2. Gruppiere sie nach Git-Operation (z.B. Committen, Branch erstellen, Worktree erstellen, Pushen, Stagen, Stashen, Wiederherstellen, Rebasing, Inspizieren mit log/diff/show/status). Ein Unterabschnitt pro unterschiedlicher Operation – liste dieselbe Operation nicht mehrmals auf. Wenn viele Befehle nur schreibgeschützte Inspektionen sind (git status, git log, git diff, git show), behandle sie zusammen in einem kurzen Unterabschnitt "Im Repo umsehen" anstatt einzeln.
3. Schreibe für jede Operation drei Dinge in der anfängerfreundlichen Stimme, die auch sonst im gesamten Dokument verwendet wird:
   • Was es tat – was dies in der heutigen tatsächlichen Arbeit erreicht hat.
   • Warum – warum dieser Schritt zu diesem Zeitpunkt benötigt wurde.
   • Wie du es selbst machst – der eigentliche Befehl, mit einer einfachen Notiz, was jeder Teil und jedes wichtige Flag bedeutet, damit der Leser ihn von Hand ausführen könnte. Setze ein > **Was bedeutet "X".**-Kästchen vor die erste Verwendung eines Befehls/Flags, das im Glossar noch nicht definiert ist.

Dormammu – Code brechen, bis es funktioniert

Verwendet aggressive, zufallsbasierte Codetransformation (Mutation) innerhalb eines temporären Git-Worktrees. Die Idee: Indem Code auf zerbrechliche Weise verändert wird, werden Fehler aufgedeckt. Dormammu wendet wiederholt Mutationen an, bis der Code entweder funktioniert oder der Entwickler aufgibt und die Lösung findet.

Agamotto – Der gnadenlose KI-Kritiker

Beschwört eine KI, die als extrem kritischer Code-Reviewer fungiert. Agamotto zerreißt Pläne, Architekturentwürfe und Code, bevor er geschrieben wird, und deckt Schwachstellen, Annahmen und verborgene Fehler auf. Er ist nicht nett – aber er ist gründlich.