Was macht research-log?
Dokumentiert Forschung so, wie Ingenieure sie hinterher erzählen: eine Geschichte von Messungen, eine Spezifikation, die präzise genug für eine Neuimplementierung ist, ein Verifikationsnachweis mit Zahlen und eine ehrliche Liste dessen, was noch unbekannt ist – ausgeliefert als eine in sich geschlossene HTML-Datei (CSS und Bilder eingebettet, keine externen Ressourcen).
Die Kernverpflichtung: Jede Behauptung ist entweder durch eine Messung belegt, als unbelegt markiert oder als offen gelistet. Der Leitgedanke, falls nötig: Die Artefakte zu lesen, sagt dir, was jemand geschrieben hat; nur das echte System sagt dir, was es bedeutet.
Arbeitsablauf
1. Zuerst die Beweise erfassen
Sammle, bevor du etwas schreibst, aus dem Gespräch, Repository, den Logs und vom Benutzer:
- die Chronologie: Daten, was versucht wurde, was fehlschlug, was überraschte
- jede Messung mit exakten Zahlen und wie sie gewonnen wurde
- Verifikationsläufe: was wurde womit verglichen und die Fehlerwerte
- die Werkzeuge, Dateipfade und Befehle, die jemand braucht, um die Arbeit zu wiederholen
- ungelöste Fragen und reine Hypothesen
Erfinde keine Messungen, Daten oder Zahlen. Fehlt eine Zahl, frage nach oder markiere sie als OPEN. Ein Bericht mit erfundenen Daten ist schlimmer als gar kein Bericht – Lücken in der Aufzeichnung sind Teil der Aufzeichnung.
2. Die Konventionen lernen
Lies references/style-guide.md vor dem Schreiben – der Stil lebt in seinen Details (Bildunterschriften, die eine Aussage beweisen, Fehler, die in der Erzählung bleiben, exakte Zahlen, kein Marketing). Lies references/content-format.md, wenn du bereit bist, das Inhaltsmodul zu schreiben.
3. Das Grundgerüst wählen
Sechs Kernabschnitte, nummeriert, in dieser Reihenfolge. Lasse einen nur aus begründetem Grund weg; füge Fallstudienabschnitte zwischen der Spezifikation und den Werkzeugen ein, wenn es einen „Das echte Ding bauen“-Bogen gibt.
| # | Abschnitt | muss enthalten |
|---|---|---|
| 1 | Die Geschichte | Tag-für-Tag-Zeitleiste; jeder Schritt einer Messung zugeordnet; Sackgassen und Überraschungen inklusive |
| 2 | Methode | ein Erkenntnissatz + Tabelle: Testartefakt → Frage → Antwort |
| 3+ | Die Spezifikation | Byte-/Protokoll-/Format-Tabellen, präzise genug für eine Neuimplementierung, mit Konfidenz-Tags; die Mathematik als Codeblöcke |
| −2 | Werkzeuge & Anleitung | echte Befehle und Pfade, die beim wörtlichen Kopieren funktionieren |
| −1 | Verifikationsnachweis | jeder Messlauf mit quantitativen Fehlern + ein Fazit-Kasten |
| −0 | Offene Fragen | ehrliche Unbekannte, jede mit OPEN oder HYP getaggt |
4. Schreiben und bauen
Schreibe den Inhalt als ein Python-Modul, das DOC definiert (Format in references/content-format.md), behalte es im Projekt, damit das Dokument neu generiert werden kann, dann:
python3 <skill-dir>/scripts/build_doc.py content.py out.html
Öffne die Ausgabe und überprüfe die Darstellung, bevor du sie dem Benutzer zeigst.
5. Selbstprüfung
- jede faktische Behauptung trägt einen Tag oder steht im Verifikationsnachweis
- die Geschichte enthält mindestens eine Überraschung, einen Fehler oder eine Korrektur – hatte die Arbeit keine, sage das klar, anstatt Drama zu erzeugen
- Zahlen sind exakt und tragen Einheiten (0,445 s, nicht „schnell“; 64.779 Pixel, nicht „viele“)
- jede Bildunterschrift gibt an, was das Bild beweist, nicht was es zeigt
- Anleitungsbefehle wurden tatsächlich ausgeführt oder sind klar als ungetestet gekennzeichnet
- offene Fragen existieren (es gibt immer offene Fragen)
- das Fazit ist ein Satz, den jemand aus dem Gedächtnis wiederholen könnte
Die Tags
Vier Konfidenz-Tags, inline am Ende der Behauptung, die sie qualifizieren:
- HW (grün) – am echten getesteten System gemessen. Für Nicht-Geräte-Arbeit gilt dies trotzdem: gemessen in einem Live-Lauf, auf der Testplatte, in der Produktion.
- FILE (blau) – in jedem untersuchten Artefakt wahr (Dateien, Mitschritte, Logs).
- HYP (lila) – konsistent mit allen Beweisen, aber unbewiesen.
- OPEN (grau) – unbekannt; keine Beweise in die eine oder andere Richtung.
Fakten tragen Tags; Kommentare nicht. Hat die Domäne bessere Namen dafür, benenne sie einmal am oberen Ende des Dokuments um und verwende sie konsistent – behalte aber genau diese vierstufige Aufteilung bei.
Stimme
Kollege, erste Person Plural, null Marketing. Zahlen exakt mit Einheiten. Sätze kurz. Humor trocken und selten. Fehler und Korrekturen gehören in die Geschichte, nicht in eine Fußnote. Kollegen werden nach ihrer Rolle gewürdigt („Ein Kollege lieferte zwei PNG-Sequenzen…“).
Ursprung
Abgeleitet aus dem TriCaster DVE-Forschungsprotokoll (waldobjekt.org, 1.–3. Nov. 2026, verfasst mit Claude) – das Ursprungsdokument liefert sein eigenes build_doc.py; dieses Skill verallgemeinert dieses Setup.