Wenn Claude seinen Namen vergisst, wird es dumm.

## Kontext-Kanarienvogel
Beginne jede einzelne Antwort mit deinem Namen in eckigen Klammern, also "[Claude]", ohne Ausnahme, auch bei kurzen Antworten.

---
name: session-uebergabe
description: "Schreibt am Ende einer Arbeits-Session ein prägnantes Handoff-Dokument, damit die nächste Claude-Session sofort den vollen Kontext hat (was gemacht wurde, aktueller Stand, nächste Schritte, offene Punkte, wichtige Pfade). Trigger DE: 'session handoff', 'übergabe', 'handoff', 'handoff schreiben', 'fass die session zusammen', 'session zusammenfassen', 'wo waren wir', 'kontext für nächste session', 'session dokumentieren'. Trigger EN: 'session handoff', 'write handoff', 'summarize the session', 'where were we', 'context for next session', 'document the session'."
---

# Session-Übergabe

Dein Job: am Ende einer Arbeits-Session ein kurzes, dichtes Handoff-Dokument schreiben. Ziel ist, dass eine komplett frische Claude-Session (oder du selbst morgen) in 30 Sekunden wieder voll im Bild ist: Was wurde gemacht, wo stehen wir, was kommt als Nächstes, was ist offen, welche Dateien sind wichtig.

Das ist ein READ-ONLY plus EIN-FILE-WRITE Skill. Du liest Kontext und schreibst genau eine Markdown-Datei. Du veränderst nichts am Projekt, fasst nichts an, löschst nichts.

## Grundprinzip

Ein Handoff ist kein Roman. Es ist eine Landekarte für die nächste Session. Schreib so, dass jemand der NICHTS von dieser Session weiß sofort weiterarbeiten kann. Konkret statt vage: nicht "Bug gefixt", sondern "Login-Bug in `auth/login.ts` Zeile 42 gefixt, Token wurde doppelt gesetzt".

## Ablauf

### 1. Kontext sammeln (READ-ONLY)

Bevor du schreibst, sammel was du brauchst. Nutz dazu was vorhanden ist:

- **Den Gesprächsverlauf dieser Session** ist deine Hauptquelle. Geh durch was tatsächlich passiert ist: welche Aufgabe, welche Entscheidungen, welche Dateien, welche Sackgassen.
- **Glob/Read** für relevante Dateien, falls du Pfade oder den letzten Stand verifizieren willst. Nur lesen, nie raten. Wenn du einen Pfad nennst, soll er stimmen.
- Falls Git im Spiel war und du es aus dem Verlauf kennst: nenn Branch, letzten Commit-Gedanken, ob etwas uncommitted ist. Erfinde keine Hashes.

Wenn etwas unklar ist (z.B. was wirklich der nächste Schritt sein soll), frag den User kurz nach, statt zu raten. Eine gezielte Rückfrage ist besser als ein falsches Handoff.

### 2. Session-Typ erkennen und Sektionen wählen

Erzwing nicht jede Sektion. Wähl die die passen. Typische Typen:

- **Bug-Fix / Debug**: Was war der Bug, Root-Cause, Fix, was noch nicht getestet.
- **Feature-Build**: Was gebaut, was fehlt noch, wie testen.
- **Setup / Konfiguration**: Was eingerichtet, welche Schritte noch offen, welche Credentials/Platzhalter.
- **Planung / Research**: Erkenntnisse, Entscheidungen, offene Fragen, nächste Recherche.
- **Content / Schreiben**: Was produziert, Stand der Drafts, was noch fehlt.

Eine kurze 30-Minuten-Session braucht 5 Zeilen. Eine große braucht mehr. Pass die Länge an die Realität an, nicht an ein Template.

### 3. Handoff schreiben

Schreib mit **Write** genau eine Datei. Sprache: die des Users (default Deutsch). Tech-Begriffe (Claude Code, MCP, Branch, Commit) englisch lassen.

**Speicherort** (in dieser Reihenfolge probieren, das erste was passt):
1. Wenn das Projekt einen `.planning/`-Ordner hat, dort hinein.
2. Sonst ein `handoffs/`-Ordner im Projekt-Root (lege ihn an, falls nötig).
3. Sonst ins aktuelle Arbeitsverzeichnis.

Wenn der User einen anderen Ort will (z.B. seinen Obsidian-Vault unter `{{VAULT_PFAD}}`), schreib dahin. Ersetze `{{VAULT_PFAD}}` durch deinen echten Vault-Pfad, falls du den nutzt.

**Dateiname**: `HANDOFF-<YYYY-MM-DD>-<kurzes-thema>.md`, z.B. `HANDOFF-2026-06-07-login-bug.md`. Datum aus dem System-Datum, nicht raten. Bei mehreren Handoffs am selben Tag eine `-2` anhängen statt eine bestehende Datei zu überschreiben.

### 4. Bestätigen

Sag dem User in 1-2 Sätzen wo die Datei liegt und nenn den absoluten Pfad. Fertig.

## Template

Nimm das als Gerüst, lass weg was nicht passt:

```markdown
# Handoff: <Thema> - <YYYY-MM-DD>

## TL;DR
<2-3 Sätze: Worum ging es, wo stehen wir jetzt. Das Wichtigste zuerst.>

## Was gemacht wurde
- <konkrete Änderung mit Datei/Ort, z.B. "X in `pfad/datei.ts` angepasst">
- <Entscheidung die getroffen wurde und warum>

## Aktueller Stand
<Funktioniert es? Getestet oder nicht? Deployed oder lokal? Branch sauber oder uncommitted?>

## Nächste Schritte
1. <konkret, umsetzbar, in Reihenfolge>
2. <...>

## Offene Punkte / Risiken
- <was blockiert, was unsicher ist, worauf man aufpassen muss>

## Wichtige Pfade & Befehle
- `pfad/zur/datei` - wofür
- `befehl zum starten/testen` - was er tut

## Kontext-Notizen (optional)
<Sackgassen die wir schon ausgeschlossen haben, damit die nächste Session sie nicht nochmal probiert. Wichtige Annahmen.>
```

## Wichtige Regeln

- **Ehrlich über den Stand.** Wenn etwas nicht getestet ist, schreib "nicht getestet". Behaupte nie dass etwas funktioniert ohne Beleg. Ein falsches "läuft" kostet die nächste Session Stunden.
- **Konkret statt vage.** Immer Datei, Ort, Zeile, Befehl nennen wo möglich. Pfade absolut oder eindeutig relativ zum Projekt-Root.
- **Keine Geheimnisse ins Handoff.** Keine API-Keys, Tokens, Passwörter, privaten Mail-Adressen im Klartext. Stattdessen Platzhalter wie `{{API_KEY in .env}}` oder den Hinweis wo es liegt.
- **Nächste Schritte müssen actionable sein.** "Weitermachen" ist kein Schritt. "In `auth/login.ts` den doppelten setToken-Call entfernen und Login-Flow durchtesten" ist einer.
- **Nicht raten.** Lieber eine Rückfrage als erfundene Hashes, Pfade oder Stati.
- **Nur eine Datei schreiben, sonst nichts anfassen.** Dieser Skill verändert das Projekt nicht.