Handoff (Übergabe)

Was macht Handoff (Übergabe)?

Beendet eine Arbeitssitzung, indem eine Übergabedatei auf die Festplatte geschrieben wird, die die nächste Sitzung liest, um genau dort weiterzumachen, wo wir aufgehört haben. Sie wird anstelle von /compact verwendet, niemals zusammen damit.

Warum nicht /compact

/compact liest den gesamten Chatverlauf, um eine Zusammenfassung zu schreiben, und ersetzt dann die Chronologie durch diese Zusammenfassung. Das Präfix ändert sich, der bereits aufgebaute Cache stirbt, und ab diesem Punkt wird er bei jedem weiteren Schritt über eine Zusammenfassung von vierzig Schritten neu aufgebaut. Es bringt keine Ersparnis, sondern erkauft Kontinuität zu einem hohen Preis.

Eine Handoff-Datei tut das Gegenteil auf drei Ebenen:

1. Kostet weniger. Die Datei umfasst einige hundert Token beim Schreiben und ebenso viele beim Lesen, und die neue Sitzung startet mit einem kleinen, sauberen Präfix.
2. Der Benutzer entscheidet, was überlebt. /compact entscheidet selbst und wirft das Wertvollste weg: die bereits ausprobierten, erfolglosen Wege. Keine automatische Zusammenfassung bewahrt sie.
3. Bleibt auf der Festplatte. Die dritte Sitzung am selben Projekt weiß, was die erste und die zweite getan haben. Ein Compact lebt und stirbt innerhalb seiner Sitzung.

Vorgehen

1. Rekonstruiere selbst, frag nicht nach dem, was du sehen kannst. Was wurde bearbeitet, was wurde getestet, was ist fehlgeschlagen und warum, welche Entscheidungen wurden getroffen, wo wurde aufgehört – all das steht im Chatverlauf. In einem Git-Repository füge git status --short und git log --oneline -5 hinzu.

2. Frage nur nach den zwei Lücken, die du nicht ableiten kannst. Das sind das Ziel (was wird gebaut und warum, nicht was heute gemacht wurde) und der gewünschte nächste Schritt (der nicht immer der offensichtliche ist). Wenn sie fehlen, frage sie in einer einzigen Frage, die bereits deine Hypothese enthält, sodass nur ein „ja“ als Antwort reicht. Alles andere wird nicht gefragt: Wenn ein Abschnitt leer ist, schreibe keine und mach weiter, erfinde keine Probleme, die es nicht gab.

3. Entscheide, wo die Datei abgelegt wird. In einem Code-Repository: docs/handoff/{YYYY-MM-DD}-{slug}.md. In einem Vault oder Notiz-Ordner (wie dieses Projekt selbst, dein-os): ein Ordner handoffs/ innerhalb des Projekts, zu dem die Arbeit gehört. Der {slug} besteht aus zwei oder drei Wörtern zur Arbeit, nicht zum Datum. Falls bereits ein Handoff mit demselben Slug existiert, nicht überschreiben: die neue Datei erhöht ein Feld seq und setzt die Vorgänger-Datei in prev, sodass die Kette rückwärts lesbar ist.

4. Schreibe die Datei mit folgendem Frontmatter – type: handoff, date, status, seq, prev, tags – und diesen Abschnitten in dieser Reihenfolge:

• Ziel: Was wird gebaut und warum, zwei oder drei Zeilen, inklusive Begründung.
• Wo wir stehen: Der aktuelle reale Stand. Was funktioniert, was ist halb fertig, was ist noch nicht begonnen.
• Was wir versucht haben, das NICHT funktioniert hat: Der wichtigste Abschnitt der Datei. Jeder verworfene Weg mit Begründung. Dient dazu, zu verhindern, dass die nächste Sitzung ihn von vorne wieder versucht.
• Probleme, auf die wir gestoßen sind, und wie wir sie gelöst haben: Nur diejenigen, die wieder auftreten würden. Symptom, Ursache, Korrektur.
• Getroffene Entscheidungen: Was wurde gewählt und was wurde verworfen, mit einer Zeile Begründung. Eine Entscheidung ohne die verworfene Alternative wird eine Woche später von Grund auf neu diskutiert.
• Bearbeitete Dateien: Pfade, mit einer Zeile, was in jeder Datei geändert wurde.
• Wohin wir gehen wollen: Der nächste Schritt, im Imperativ geschrieben. Dann der übernächste, falls bereits klar.
• Vor dem Anpacken zu wissen: Fallstricke, Befehle, die auf eine bestimmte Weise ausgeführt werden müssen, Dinge, die kaputt aussehen, es aber nicht sind. Wenn es keine gibt, keine.

5. Schließe ab, indem du die Resume-Zeile in den Chat schreibst, bereit zum Einfügen in eine neue Sitzung: Lies {Pfad} und fahre fort ab „Wohin wir gehen wollen“. Plus eine Zeile, die besagt, dass man jetzt /clear machen kann und dass der Resume nur diese eine Datei kostet.

Wann NICHT verwendet

Eine Skill, die immer verwendet wird, ist eine Skill, die wahllos verwendet wird.

• Aufgabenwechsel ohne Kontinuität → /clear, kein Handoff nötig.
• In den letzten Schritten wurde ein falscher Weg eingeschlagen → /rewind, das zu einem Punkt zurückkehrt, den der Cache bereits kennt.
• Fortsetzung erfolgt bald und ohne zwischenzeitliche Aktualisierungen → /rename plus /resume.
• Die Arbeit geht einen weiteren Tag oder eine weitere Woche weiter → diese Skill.

Diese Skill führt /clear nicht für den Benutzer aus, sondern empfiehlt es lediglich.