initial: claude code workflow bundle (plan-start, status, handoff, adr)
This commit is contained in:
Kristian
@@ -0,0 +1,120 @@
|
||||
---
|
||||
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`.
|
||||
Reference in New Issue
Block a user