claude-code-workflow/global-skills/handoff/SKILL.md

name, description, disable-model-invocation, argument-hint, allowed-tools

name	description	disable-model-invocation	argument-hint	allowed-tools
handoff	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.	true	<optional: kurzer slug für den log-dateinamen>	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.