---
type: skill
agent_ready: true
schema_version: 1
bundle_version: "0.28.0"
name: project-session-end
description: "Schreibt am Session-Ende eines Projekts unter {projects}/<X>/ die Datei Handover.md (vollständig überschrieben) und ruft danach den session-log-Skill auf. Im Start-Modus erkennt er vorhandene Handover.md beim Projekt-Wiedereinstieg und bietet sie als Grundlage an."
tags:
  - skill
  - project-session-end
  - handover
scope: vault
bundle_skill: true
default_active:
  allgemein: true
depends_on: [session-log]
conflicts_with: []
created: 2026-05-12
updated: 2026-05-12
---

# project-session-end

Standardisiert den Übergang zwischen zwei Projekt-Sessions. Er hat zwei Modi: End-Modus (Handover.md schreiben + session-log aufrufen) und Start-Modus (vorhandene Handover.md beim Wiedereinstieg anbieten).

**Abgrenzung zu session-log:** `session-log` schreibt Raw-Material (was ist in der Session passiert) nach `{logbuch}/Z Session Logs/`. `project-session-end` schreibt den **Start-Prompt für die nächste Session** in den Projektordner. Zwei Verantwortlichkeiten, zwei Dateien, keine Duplikation. Dieser Skill **ruft** `session-log` auf, er **ersetzt** ihn nicht.

Pfade kommen aus `skill.config.yaml` (via `config_loader`). Fehlt die Datei, greift der Skill auf `bundle.json.vault_layout` und die Hard-Defaults zurück.

**Eintrittspunkt:** Claude führt die Ablauf-Schritte aus der SKILL.md aus (siehe End-Modus und Start-Modus unten). `compute_paths.py` ist ein **Hilfswerkzeug für deterministische Pfadauflösung**, nicht der Haupt-Eintrittspunkt — Claude ruft es im Ablauf auf, um die JSON-Antwort mit den aufgelösten Pfaden zu erhalten.

Aufruf des Hilfswerkzeugs:
```bash
PYTHONUTF8=1 python .skills/project-session-end/compute_paths.py --vault PATH --project "<Projektname>"
```
Gibt JSON mit aufgelösten Pfaden zurück.

## Wann einsetzen

- **End-Modus:** User signalisiert Session-Ende UND die Session gehört zu einem aktiven Projekt unter `{projects}/<X>/`.
- **Start-Modus:** User signalisiert in einer neuen Session, an einem bestimmten Projekt weiterzuarbeiten.

Wenn die Session kein Projekt berührt hat, greift nur `session-log`, nicht dieser Skill.

## End-Modus

### Trigger-Erkennung

Beide Bedingungen müssen erfüllt sein:

1. Der session-log-Trigger greift (User sagt sinngemäß "log die Session", "Schluss für heute", "Session-Ende" o.Ä.). Nicht auf exakten Wortlaut matchen — Intent erkennen.
2. Die Session gehört zu einem Projekt. Indizien: Dateien unter `{projects}/<X>/` wurden angefasst; User hat einen Projektnamen explizit genannt; User hat Phrasen wie "denk an den Handover" benutzt.

### Ablauf in acht Schritten

**Schritt 1 — Projekt erkennen**
Gehe den Gesprächsverlauf durch. Stelle fest: welcher Projektordner wurde berührt oder genannt? Mehrere Kandidaten möglich, gewichtet nach: (a) explizite Namensnennung durch den User, (b) Dateioperationen im Projektordner, (c) Phrasen wie "denk an den Handover".

**Schritt 2 — Kurz-Bestätigung**
- **Eindeutig ein Projekt:** "Erkannt: Projekt `<Projektname>`. Ich schreibe `Handover.md` und danach den Session-Log. Passt das?"
- **Mehrere Kandidaten oder unklar:** "Zu welchem Projekt gehört das, oder ist es keine Projekt-Session? Kandidaten: X, Y."
- **Kein Projekt erkennbar, User bestätigt:** Direkt zu Schritt 7 (nur session-log-Skill aufrufen, keine Handover.md schreiben).

**Schritt 3 — Alte Handover.md lesen (falls vorhanden)**
Wenn `{projects}/<X>/Handover.md` existiert, vollständig mit Read lesen. Ziel: langlebige Inhalte (Stolpersteine, verbindliche Regeln, Kritische-Punkte-Blöcke) übernehmen. Wenn die Datei nicht existiert, mit leerem Bestand starten.

**Schritt 4 — Inhaltliche Verdichtung der aktuellen Session**
Verdichte den Gesprächsverlauf auf die Template-Abschnitte (siehe unten). Langlebige Inhalte aus der alten `Handover.md` übernehmen, veraltetes (erledigte Schritte, abgeschlossene Phasen) fällt weg. Die neue Datei löst die alte vollständig ab.

**Schritt 4a — Methoden-Abschnitt spiegeln** _(hinter `features.include_method_phase_block`, Default `true`)_
Wenn im Projektsteckbrief ein `## Methode`-Block oder ein `methode:`-Frontmatter-Feld existiert: in Handover.md einen Pflicht-Abschnitt `## Aktuelle Methode und Phase` anlegen mit Name und Wikilink der aktiven Methodenkarte, aktueller Phase, nächstem Schritt gemäß Methode sowie Hinweis: "Beratungs-Triage im Hintergrund aktiv — Methodenwechsel nur bei konkretem Signal." Wenn kein `## Methode`-Block im Steckbrief vorhanden ist: diesen Abschnitt weglassen.

**Schritt 4b — Mentor-Checkpoint-Prüfung** _(hinter `features.include_mentor_checkpoints`, Default `true`)_
Lies im Projektsteckbrief den Block `## Mentor-Checkpoints` (falls vorhanden). Wenn der aktuelle Session-Abschluss einen der genannten Checkpoints trifft, füge in Handover.md an erster Stelle im "Dein Auftrag"-Block ein: `/projekt-mentor aufrufen, bevor Phase X startet.` Bei mehreren getroffenen Checkpoints alle eintragen. Wenn kein Block im Steckbrief oder kein Checkpoint getroffen: keine Ergänzung.

**Schritt 5 — Handover.md überschreiben**
Schreibe mit Write-Tool die neue `{projects}/<Projektname>/Handover.md`. Frontmatter-Regeln:
- `type: handover` (konfigurierbar über `frontmatter.type` in `skill.config.yaml`)
- `project: <Projektname>`
- `description: "Handover-Prompt für die nächste Session am Projekt <X>. Stand <YYYY-MM-DD>: <ein Satz Kurz-Zusammenfassung>."`
- `tags: handover, projekt, <projekt-slug>`
- `created`: bei bestehender Datei unverändert übernehmen, bei neuer Datei heute.
- `updated`: immer heute.

**Schritt 6 — Glossar-Check** _(hinter `features.enforce_glossary_check`, Default `true`)_
Lade `{context}/Glossar.md`, gleiche alle Eigennamen, Firmennamen, Produkt-, Projekt- und Fachbegriffe in der neuen `Handover.md` gegen die dort hinterlegten Schreibweisen ab. Korrigiere Abweichungen. Neue Begriffe proaktiv eintragen. Wenn die Glossar-Datei nicht existiert: stderr-Warnung ausgeben ("project-session-end: Glossar-Datei nicht gefunden unter <Pfad>. Setze `features.enforce_glossary_check: false` um den Check zu deaktivieren."), aber weiterarbeiten — kein Abbruch. Zum vollständigen Deaktivieren des Checks: `features.enforce_glossary_check: false` in `skill.config.yaml` setzen.

**Schritt 7 — session-log-Skill aufrufen** _(hinter `features.call_session_log`, Default `true`)_
Führe den bestehenden `session-log`-Skill aus gemäß dessen Manueller-Modus-Instruktionen. Nicht ändern, nicht umgehen. Der Session-Log landet unter `{logbuch}/Z Session Logs/YYYY-MM/DD/session-YYYY-MM-DD-HHMM-<topic>.md`.

**Schritt 8 — Rückmelden**
Genau drei Sätze:
1. Welcher Projektordner wurde angefasst und welche `Handover.md` geschrieben (Pfad + Kurz-Zusammenfassung des Auftrags für die nächste Session).
2. Welcher Session-Log-Pfad entstanden ist.
3. Session-Ende-Bestätigung.

**Schritt 8a — Startprompt-Codeblock (Pflicht)**
Direkt nach den drei Sätzen einen Codeblock mit dem Startsatz für die nächste Session ausgeben. Inhalt: was der nächste Agent zuerst lesen muss. Nur das Minimum (Handover plus ein bis zwei spezifische Dateien):

```
Wir arbeiten an Projekt <X>. Lies zuerst:
1. {projects}/<X>/Handover.md (Stand und nächster Schritt)
2. <eine bis zwei spezifische Dateien für den nächsten Schritt>
Dann übernimm Schritt: <konkrete Aufgabe in einem Satz>.
```

**Ausnahme:** Wenn das Gesamtprojekt in dieser Session sauber zu Ende gebracht wurde, entfällt der Codeblock. Stattdessen ein Satz: "Projekt `<X>` ist abgeschlossen — kein Startprompt für eine Folgesession nötig."

### Was im End-Modus explizit NICHT passiert

- Kein Anfassen des Projektsteckbriefs.
- Kein Anfassen der Daily Note (`{logbuch}/B Daily Notes/`).
- Keine Modifikation irgendeiner Datei im Projektordner außer `Handover.md`.
- Keine Löschungen, niemals.
- Kein direkter Aufruf des Reflector- oder Curator-Skills.

## Start-Modus

### Trigger-Erkennung

Greift, wenn der User in einer neuen Session sinngemäß signalisiert, an einem bestimmten Projekt weiterzuarbeiten. Beispiel-Phrasen (nicht abschließend, Intent erkennen):
- "Lass uns an Projekt X weitermachen"
- "Arbeite an Projekt X"
- "Weiter mit X"

### Ablauf in vier Schritten

**Schritt 1 — Projektname extrahieren**
Lies den User-Input. Bei mehrdeutigem Namen kurz zurückfragen: "Meinst du `<Projektname A>` oder ein anderes Projekt?"

**Schritt 2 — Handover.md prüfen**
Prüfe `{projects}/<Projektname>/Handover.md`. Drei Fälle:
- **Datei existiert:** Lies vollständig mit Read. Extrahiere `updated`-Datum und TL;DR. Fasse in zwei bis drei Sätzen zusammen und frage: "Es liegt ein Handover-Prompt vor vom `<Datum>`. Soll ich ihn als Grundlage nehmen?"
- **Datei existiert nicht:** Meldung "Keine Handover.md in `{projects}/<Projektname>/` vorhanden." Lies stattdessen den Projektsteckbrief `{projects}/<Projektname>/<Projektname>.md` als Grundlage.
- **Datei veraltet** (`updated` älter als 30 Tage): Zusätzlich Hinweis: "Der Handover ist `<X>` Tage alt, Stand könnte veraltet sein. Trotzdem als Basis nehmen?"

**Schritt 3 — Bei Zustimmung**
Folge den Anweisungen in der `Handover.md` wörtlich: Pflichtlektüre in der angegebenen Reihenfolge lesen, Healthcheck-Schritte ausführen (falls definiert), Rückfragen stellen, mit erstem Schritt im "Dein Auftrag"-Block starten.

**Schritt 4 — Bei Ablehnung**
Frage: "Wie willst du stattdessen weitermachen?" und folge der neuen Richtung. Die `Handover.md` wird **nicht** verändert.

## Template für Handover.md

### Frontmatter (Pflicht)

```yaml
---
type: handover
project: <Projektname>
description: "Handover-Prompt für die nächste Session am Projekt <X>. Stand <YYYY-MM-DD>: <ein Satz Kurz-Zusammenfassung>."
tags:
  - handover
  - projekt
  - <projekt-slug>
created: YYYY-MM-DD
updated: YYYY-MM-DD
---
```

### Body — Pflicht-Kern (Reihenfolge verbindlich)

```markdown
# Handover — <Projektname>

Dieses Dokument ist der Start-Prompt für die nächste Session. Es löst das
vorherige Handover vollständig ab. Lies diese Datei zuerst, dann arbeite die
nummerierten Schritte ab.

## TL;DR

**Stand am <YYYY-MM-DD>:** <ein bis zwei Sätze>.

**Dein Auftrag in der nächsten Session:** <ein Satz>.

**Was du nicht tust:** <ein Satz>.

## Erste Schritte beim Onboarding (Reihenfolge zwingend)

1. Diese Datei zu Ende lesen.
2. Projektsteckbrief lesen: [[{projects}/<Projektname>/<Projektname>]].
3. Pflichtlektüre (siehe unten) in der angegebenen Reihenfolge.
4. <ggf. Healthcheck-Kommandos>
5. Erst danach loslegen.

## Was bisher passiert ist

<Kurze Vorgeschichte: letzte Session(s), getroffene Entscheidungen, Phasen-Abschlüsse.>

## Aktueller Status

<Tabelle oder 2–4 Sätze: was ist fertig, was ist halb-fertig, was blockiert.>

## Dein Auftrag in dieser Session

### Hauptauftrag
<Ein Satz.>

### Vorgehen
<Nummerierte Schritte, Reihenfolge verbindlich.>

### Definition of Done
<Was muss konkret am Ende der nächsten Session stehen?>

## Pflichtlektüre

| Datei | Warum |
|---|---|
| [[...]] | ... |

## Verknüpfungen

- [[{projects}/<Projektname>/<Projektname>]] — Steckbrief
- <weitere relevante Dateien>
```

### Optionale Blöcke

Einfügen, wenn im Kontext relevant:
- **Aktuelle Methode und Phase** (Pflicht bei Projekten mit `## Methode`-Block, gesteuert über `features.include_method_phase_block`).
- **Kritische Punkte und Fallstricke:** Stolpersteine, frühere Fehler, Entscheidungen die nicht mehr aufgemacht werden.
- **Was du auf keinen Fall tust:** Rote Linien.
- **Wann du zwingend fragst:** Konkrete Punkte, an denen der Agent stoppen und nachfragen muss.
- **Healthcheck-Block:** Bash-Befehle mit erwarteten Ausgaben.
- **Verbindliche Regeln:** Wichtigste Projekt-Regeln in Kurzform.

## Formulierungsregeln

- **Zweite Person, direkte Anweisung an die KI.** Nicht "User will, dass...", sondern "Du tust...".
- **Deutsche Umlaute als echte Zeichen.** `ä ö ü Ä Ö Ü ß` — niemals `ae oe ue ss`.
- **Wikilinks** für alle Verweise auf Vault-Dateien.
- **Imperativ statt Konjunktiv.** "Lies die Datei, prüfe den Status, starte mit Task 3."
- **Strukturierte Ausgabe.** Listen, Tabellen, klare Headlines.
- **Erfolg explizit einfordern.** Der "Definition of Done"-Block sagt, woran die nächste Session erkennt, dass sie fertig ist.

## Konfiguration

Vollständige Konfigurations-Vorlage: `skill.config.example.yaml`. Feature-Flags in `skill.config.yaml`:

```yaml
features:
  include_method_phase_block: true    # Methoden-Abschnitt aus Steckbrief übernehmen
  include_mentor_checkpoints: true    # Mentor-Checkpoints aus Steckbrief prüfen
  enforce_glossary_check: true        # Glossar-Check vor jedem Handover-Write
  call_session_log: true              # session-log-Skill am Ende aufrufen
```

## Locale

Default: `de`. Weitere Locales können unter `locale_data/` ergänzt werden (für diesen Skill derzeit nicht angelegt — der Skill erzeugt keine Slug-basierten Dateinamen und braucht keine Locale-Daten).

## Abgrenzung

Dieser Skill fasst **ausschließlich** `{projects}/<X>/Handover.md` an und ruft **ausschließlich** den bestehenden `session-log`-Skill auf.

Er fasst **niemals** an:
- Daily Notes (`{logbuch}/B Daily Notes/`)
- Projektsteckbriefe (`{projects}/<X>/<X>.md`)
- Andere Projekt-Dateien außer `Handover.md`
- Den bestehenden `session-log`-Skill (wird aufgerufen, nicht modifiziert)
- Dateien anderer Projekte

Er führt **niemals** aus:
- Löschungen jeglicher Art
- `rm`, `mv` gegen bestehende Dateien ohne ausdrückliche Freigabe

## Verknüpfungen

- [[INDEX|INDEX.md]]
- [[AGENTS|AGENTS.md]]
- depends_on: session-log (wird im End-Modus aufgerufen)
