ce:compound

Trevin Chows Notizen vom 31. März 2026 zu Compound Engineering v2.60.0 halten die Änderung fest, die ce:compound heute ausmacht: Der Skill erhielt ein eigenes Schema je Spur, Bug versus Wissen, und dazu eine Discoverability-Prüfung. Die Trennung stützt sich auf eine These, die Kieran Klaassens Thinkroom-Agentenleitfaden unverblümt formuliert: ein System, das sich nur Bugs merkt, vergisst das Wesentliche. Die Bug-Spur hält fest, was kaputtging; die Wissens-Spur hält fest, was entschieden oder entdeckt wurde.

ce:compound sitzt am Erfassungsende des Compounding Knowledge Lifecycle und wird per /ce-compound aufgerufen. Seine Ausgabeeinheit ist das Learning: eine Markdown-Datei, ein gelöstes Problem, abgelegt unter docs/solutions/<category>/, deren Frontmatter (title, tags, module, problem_type, applies_when, severity, date) für das Auffinden existiert, nicht zum Lesen.

Seine Disziplin ist das Timing. Klaassen verortet den eigentlichen Flaschenhals in der Nachbereitung, nicht im Schreiben: Postmortems verrotten in Wikis. Deshalb dokumentiert ce:compound, solange der Kontext noch frisch ist, und fächert dabei Subagenten auf (einen Context-Analyzer, einen Solution-Extractor, einen Related-Docs-Finder, der vor Duplikaten schützt), während allein der Orchestrator ein einziges Dokument schreibt.

Der Umfang dabei ist überschaubar. Klaassens Leitfaden zählt 35 Learnings, Skill-Design liegt dabei vorn. Das kanonische Beispiel ist Incident #714, der zugleich zu einem Fix, einem Learning, einem Test und einer Doktrin wurde. Nach diesem Maßstab bedeutet Compounding, dass ganze Klassen von Fehlern ausscheiden. Ob eine wachsende Anzahl von Dateien jemals aufhört, dafür als Stellvertreter zu dienen, bleibt offen.