Kristian
121 lines
4.8 KiB
Markdown
121 lines
4.8 KiB
Markdown
---
|
||
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`.
|