---
name: handoff
description: Schreibt am Ende einer Arbeitssession einen Session-Log nach docs/sessions/YYYY-MM-DD-<slug>.md und aktualisiert docs/90-status.md. Erzwingt eine kurze Reflexion des Nutzers (drei Fragen), bevor geschrieben wird — bewusst NICHT autonom aus dem Sitzungskontext ableiten.
disable-model-invocation: true
argument-hint: "<optional: kurzer slug für den log-dateinamen>"
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
---

# handoff — Sessionende

## Warum es diesen Skill überhaupt gibt

Die Disziplin des ganzen Workflows liegt nicht in den anderen Skills, sondern
in diesem hier. Wer `handoff` am Sessionende überspringt, hat nach drei
Sessions wieder das alte Problem: Kontext verdunstet, „wo war ich stehen-
geblieben?" ist Rateraten.

Und: `handoff` fragt **explizit nach**, statt autonom zusammenzufassen. Das ist
gegen die LLM-Intuition („kann ich doch selbst"), aber genau der Punkt.
Automatisch generierte Session-Logs sind nach drei Wochen formal korrekt und
inhaltlich beliebig. Die fünf Sekunden Reflexion pro Session sind die
Investition, die das System überhaupt tragbar macht.

## Wann der Skill läuft

Auf expliziten Aufruf am Ende einer Session. Vorher prüfen: existiert
`docs/90-status.md`? Wenn nicht → melden „Kein initialisiertes Projekt", abbrechen.

## Was der Skill tut

### Schritt 1 — Drei Fragen an den Nutzer

Nacheinander, nicht als Liste. Auf jede Antwort kurz warten, nicht selbst
vorschlagen. Die Fragen sind bewusst stumpf und weit, damit der Nutzer
reflektiert:

1. **„Was hast du in dieser Session konkret erledigt?"**
   (Faktisch. Nicht „wir haben über X gesprochen", sondern „Datei Y angelegt,
   Test Z bestanden, Entscheidung A getroffen".)

2. **„Was hast du angefangen und nicht beendet?"**
   (Die Dinge, die sonst vergessen werden. Halbe Edits, offene Branches,
   angetestete Hypothesen ohne Ergebnis.)

3. **„Was sind die nächsten 1–3 konkreten Schritte, wenn du das Projekt
   wieder aufnimmst?"**
   (Klein, prüfbar. Nicht „Feature X bauen", sondern „Funktion `parse_header`
   um Content-Type erweitern, dann Test dafür schreiben".)

Zusätzlich darf der Skill **nur wenn nötig** nachfragen:

- Gab es eine größere Entscheidung, die einen ADR verdient? (Falls ja: den
  Nutzer an `adr <titel>` erinnern — **nicht** selbst anlegen.)
- Ist der aktuelle Fokus in `docs/10-plan.md` noch korrekt? (Wenn nein: Notiz
  machen, dass der Nutzer das beim nächsten Mal anpassen sollte. Nicht selbst
  editieren.)

### Schritt 2 — Slug und Dateiname bauen

- Datum: `date +%F` → `YYYY-MM-DD`.
- Slug: aus `$ARGUMENTS`, sonst aus der Antwort auf Frage 1 automatisch
  ableiten (2–4 Wörter, lowercase, Bindestriche, keine Sonderzeichen).
- Dateiname: `docs/sessions/YYYY-MM-DD-<slug>.md`.
- Kollision vermeiden: wenn die Datei existiert, suffix `-2`, `-3`, … anhängen.

### Schritt 3 — Session-Log schreiben

Nach dem Template `templates/session-log.md.tmpl` (liegt im Skill-Ordner).
Platzhalter füllen:

| Platzhalter | Quelle |
|---|---|
| `{{SESSION_DATE}}` | aktuelles Datum `YYYY-MM-DD` |
| `{{SESSION_SLUG}}` | der Slug von oben |
| `{{WHAT_DONE}}` | Antwort auf Frage 1, als Bulletpoints |
| `{{WHAT_OPEN}}` | Antwort auf Frage 2, als Bulletpoints |
| `{{NEXT_STEPS}}` | Antwort auf Frage 3, als nummerierte Liste |
| `{{DURATION}}` | optional, wenn der Nutzer ihn nennt, sonst weglassen |

### Schritt 4 — `docs/90-status.md` aktualisieren

Keine komplette Neuschreibung. Gezielt:

- Zeitstempel „Letzte Aktualisierung" auf heute setzen.
- Abschnitt **„Aktueller Stand"** ersetzen durch eine Destillation aus Frage 1
  + Frage 2 (2–4 Sätze).
- Abschnitt **„Nächste Schritte"** ersetzen durch die Antwort auf Frage 3.
- Abschnitt **„Offene Entscheidungen / Blocker"**: nur anfassen, wenn der
  Nutzer im Gespräch explizit eine Entscheidung oder einen Blocker erwähnt
  hat. Sonst unverändert lassen.
- Abschnitt **„Zuletzt geändert durch"**: auf
  `handoff — <slug> am <datum>` setzen.

### Schritt 5 — Kurze Bestätigung

Dem Nutzer in 2–3 Zeilen zurückmelden: welche Datei wurde geschrieben, was
wurde in `90-status.md` aktualisiert. Keine Zusammenfassung der Zusammenfassung
— der Nutzer weiß, was er gerade gesagt hat.

Optional, wenn relevant: Hinweis auf einen anzulegenden ADR, falls in Schritt 1
eine Architektur-Entscheidung genannt wurde.

## Harte Regeln

- **Nicht automatisch zusammenfassen** ohne die drei Fragen zu stellen. Auch
  dann nicht, wenn der Sitzungsverlauf scheinbar alles klar macht. Die Fragen
  sind Pflicht.
- **Nichts in `30-decisions/` schreiben.** Dafür gibt's `adr`. Der Nutzer wird
  daran erinnert, aber er entscheidet.
- **Nie `git commit`.** Der Nutzer entscheidet, ob und wann.
- **Niemals einen bestehenden Session-Log überschreiben.** Bei Kollision
  Suffix anhängen.

## Template

Siehe `./templates/session-log.md.tmpl`.