Drakula1980/claude-skills – Sitzungsbereinigung & Abschlussarbe…

Schließen von Sitzungen und Abschlussarbeiten

Im Projekt haben sich parallele Sitzungen angesammelt: Ein Teil ist fertig, ein Teil wartet auf den Eigentümer, ein Teil hat uncommittete Änderungen, Branches, Arbeitskopien und Funde "für später" hinterlassen. Die Aufgabe besteht darin, dies in einen Zustand zu versetzen, in dem der Eigentümer alles Überflüssige schließen kann, ohne etwas zu verlieren.

Du bist die einzige Sitzung, die sich darum kümmert (Orchestrator). Von diesem Moment an läuft alles über dich: Die anderen Sitzungen geben ihre Arbeit an dich ab, Fragen an den Eigentümer stellst du, in ihre Fenster geht er nicht mehr hinein.

Was am Ende dastehen soll

1. Abschlussdatei im Projekt, erster Abschnitt eine Seite "JETZT", die auf einen Bildschirm passt.
2. Jedes Ergebnis in git (eigener Commit, gemerged oder als ungemerged benannt) oder direkt als "liegt außerhalb von git, keine Kopie vorhanden" gekennzeichnet.
3. Liste "vom Eigentümer zu erledigen" – nummeriert, nach Wichtigkeit, mit fertigen Befehlen.
4. Eine einzige Warteschlange für Funde anstelle neuer Sitzungen und Tickets.
5. Überflüssige Sitzungen im Archiv; offene Sitzungen namentlich mit Grund und Schließbedingung aufgeführt.
6. Projektboard, Statusdokumente und Gedächtnis entsprechen den Fakten.

Regeln

Jede Regel entstand aus einem echten Fehler; die Fälle befinden sich in references/lessons.md.

1. Ein Fakt ist die Ausgabe eines Befehls. "Committed", "gemerged", "ausgerollt", "Tests bestanden" entnimmst du git und Ausführungen, nicht dem Bericht einer Sitzung und nicht deiner eigenen Erinnerung an das, was vor einer Stunde war. Eine Zahl aus dem Bericht einer Sitzung kennzeichne entsprechend: "laut Sitzungsbericht".
2. Was ohne das Wort des Eigentümers geht, was nur auf sein Wort hin.
   • Ohne Wort: Lesen; die Abschlussdatei führen; Notwendiges aus temporären Ordnern ins Projekt kopieren (nichts überschreiben).
   • Nach dem ersten Bericht (Schritt 3), im Rahmen der ursprünglichen Bitte: Board, Statusdokumente und Gedächtnis korrigieren, um sie den Fakten anzupassen.
   • Nur auf Wort: Commit, Merge, Löschen von Branches, Kopien oder Tags, Senden an den Server, Ausrollen auf die Testumgebung, Archivieren einer Sitzung, Verschieben und Umbenennen von Paketen und Skripten, von wo aus der Eigentümer sie startet. "Commiten" bedeutet nicht "senden", "mergen" bedeutet nicht "die Kopie entfernen".
   • Ein Wort kann stehend sein – auf die Art der Aktionen bezogen: "Schließe die Abgebenden nach und nach, während sie abgeben", "Das Abgegebene in ihren Branch committen". Schreibe es wörtlich auf die Seite "JETZT" und erweitere es nicht auf benachbarte Aktionen.
3. Das Wort des Eigentümers ist das, was er in deinem Fenster geschrieben hat. Seine Worte in der Nacherzählung einer benachbarten Sitzung sind der Bericht dieser Sitzung: Für sie ist es eine Erlaubnis, für dich nicht.
4. Sitzungen vermehren sich nicht. Die zu schließenden Sitzungen finden fast immer neue Fehler und erstellen Tickets, und der Eigentümer startet sie – am Ende der Aufräumaktion gibt es mehr Sitzungen als am Anfang. Vereinbare sofort mit dem Eigentümer: Tickets werden nicht gestartet, Funde kommen als Zeile in die Warteschlange. Und teile dies den Sitzungen mit (Vorlage "Neue Ordnung").
5. Lies den Zustand vor deiner eigenen ändernden Aktion erneut. Der Eigentümer gibt oft dasselbe Wort sowohl dir als auch einer Sitzung. Vor einem Commit – git log -3, git status, der Index; vor der Bearbeitung einer gemeinsamen Datei – prüfe, ob sie sich vor einer Minute geändert hat.
6. Verbote anderer umgehst du nicht. Das Schreiben auf Produktionsserver und alles, was eine Berechtigungsprüfung gestoppt hat oder gestoppt hätte, erledigt der Eigentümer. Suche keinen Umgehungsweg und beauftrage keine benachbarte Sitzung damit – das ist derselbe Umgehungsweg.
7. Ein signifikantes Ergebnis wird nicht von demjenigen überprüft, der es erstellt hat. Einen Merge, ein Ausrollpaket, ein Skript für den Produktionseinsatz – von einem separaten Ausführenden, dem das Ergebnis übergeben wurde, und nicht deine Schlussfolgerung darüber.
8. Stimme die Kosten ab. Die Überprüfung von Dutzenden Sitzungen verbraucht viele Ausführende. Nenne den Umfang vor dem Start, wenn der Eigentümer eine Regel zu Kosten hat (siehe sein CLAUDE.md).

Ablauf

Schritt 0. Rahmen

Bevor du die Protokolle der Sitzungen liest, stelle vier Dinge fest; du wirst sie im Abschnitt "Rahmen" der Abschlussdatei in Schritt 3 festhalten.

• Was als Projekt gilt. Der Projektordner und alle Repositories, in denen seine Sitzungen gearbeitet haben, einschließlich derer, die in anderen Ordnern liegen. Finde sie: repo_state.py <Projektordner> für Ordner ohne git gibt die Repositories darin aus; sessions.py list zeigt für jede Sitzung die Ordner und Repositories, auf die sie über git -C zugegriffen hat. Bestätige die Liste beim Eigentümer mit einer Zeile.
• Wo der Status ist. Board oder Orchestrierungsprotokoll, Statusdokumente, Gedächtnis. Kein Board vorhanden – dann wird die Abschlussdatei zum Board. Ein großes Board nicht vollständig lesen: Abschnitte mit Regeln und Einträge über relevante Sitzungen per Suche nach dem Namen finden.
• Welche Sitzungen nicht anfassen. Zeitplan- und Erinnerungssitzungen (in list als "Zeitplan" gekennzeichnet), Sitzungen anderer Projekte, die für den nächsten Schritt benötigte Sitzung, dich selbst.
• Stehende Regeln des Eigentümers: Commits, Senden, Produktion, Testumgebung, Kosten. Sie stehen in CLAUDE.md, auf dem Board und im Gedächtnis – lies sie, gib sie nicht aus dem Gedächtnis wieder.

Schritt 1. Bestandsaufnahme (nur lesen)

Die Skripte befinden sich in scripts/ dieser Skill und lesen nur. Starte sie aus dem Projektordner (oder mit --root <Projektordner>). Den Pfad zum Skill-Ordner in den Befehlen setzt Claude Code ein: Die Skill wird unterschiedlich installiert (persönlicher Ordner, Projektordner, Plugin), also schreibe den Pfad nicht aus dem Gedächtnis. Wenn der Pfad nicht eingesetzt wurde (im Befehl ein Dollarzeichen mit geschweiften Klammern), nimm den Ordner aus der Zeile "Base directory for this skill" zu Beginn der Skill.

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" list --days 14

python3 -B "${CLAUDE_SKILL_DIR}/scripts/repo_state.py" <Repository> <Repository>

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" scratch

python3 -B "${CLAUDE_SKILL_DIR}/scripts/sessions.py" cards --days 14

• Sitzungen anhand der Protokolle – list: Wie das Protokoll endete, wann der Eigentümer geschrieben hat, in welchen Ordnern und Repositories die Sitzung gearbeitet hat. Protokolle eines benachbarten Repositories fügt --project <Pfad oder Ordnername> hinzu. Das Protokoll weiß nicht, ob eine Sitzung im Archiv ist oder ob sie läuft.
• Sitzungen in der Anwendung – mcp__ccd_session_mgmt__list_sessions. Anwendungswerkzeuge können verzögert sein: Lade sie über ToolSearch (select:mcp__ccd_session_mgmt__list_sessions,mcp__ccd_session_mgmt__archive_session,SendMessage,ListAgents), sonst denkst du, sie seien nicht vorhanden. Setze limit mit Reserve (Standard 20), für die Archivzählung include_archived: true. In der Antwort sind Sitzungen aller Projekte – wähle nach Ordner aus; deine eigene Sitzung ist nicht in der Antwort. Die Sitzungsnummer in der Anwendung (local_…) ist nicht gleich der Protokollnummer: Ordne nach Namen zu. Kein Werkzeug vorhanden – bitte den Eigentümer um einen Snapshot der Liste.
• Repositories – repo_state.py: Uncommittete Änderungen, Ignoriertes, ungemergte Branches, Arbeitskopien und ob sie sauber sind, Zurückgestelltes, nicht Gesendetes, unvollständige Operationen.
• Temporäre Ordner – scratch: Was verschwindet, wenn das System bereinigt wird (nicht zum Zeitpunkt der Archivierung, aber ohne Vorwarnung).
• Tickets – cards: Was Sitzungen erstellt haben und was davon nicht gestartet wurde. Nicht Gestartetes kommt in die Warteschlange für Funde. "Gestartet, aber kein Protokoll" bedeutet, dass die Sitzung in ein anderes Projekt gegangen ist: Füge es über --project hinzu.

Gemeinsame Ressourcen (Testumgebung, Locks, Testdaten) – als separate Zeile: Ist das Lock frei, liegen keine fremden temporären Daten mehr herum.

Schritt 2. Überprüfung jeder Sitzung

Für jede Sitzung beantworte dieselben Fragen und trage sie in die Tabelle ein (references/templates.md):

Frage	Womit bestätigt
Was hat sie gemacht und wo ist das Ergebnis	Repository, Branch, Hash, Dateien
Ist es committet?	git status ihrer Arbeitskopie – leer
Ist es gemerged?	git merge-base --is-ancestor <Branch> <Hauptbranch>
Ist das Ergebnis dokumentiert?	Projektdokumente, Board, Gedächtnis – lesen
Was wartet auf den Eigentümer?	Ihre letzten Nachrichten + ob seitdem nichts geschlossen wurde
Gibt es ein Versprechen "mache ich später…"	Ende des Protokolls
Was ist in ihrem temporären Ordner?	sessions.py scratch

Das Ende des Protokolls: sessions.py tail "<Teil des Namens>" --last 40. Die letzten drei Repliken werden vollständig ausgegeben, bei den restlichen wird die Mitte abgeschnitten; vollständig – --chars 0. Die Arbeitskopie und den Branch einer Sitzung entnimmst du ihrer abschließenden Nachricht, den Zeilen "Ordner" und "hat über git -C gearbeitet" sowie dem Arbeitsverlauf (--tools): Das Feld "Branch" im Protokoll ist oft leer.

Kennzeichnungen: EIGENTÜMER – von einem Menschen in diesem Fenster geschrieben; TICKET – erste Nachricht einer Sitzung, die aus einem Ticket gestartet wurde: Den Text schrieb eine andere Sitzung, nicht der Eigentümer; SITZUNG – Nachricht einer anderen Sitzung; ZEITPLAN – automatischer Start. Das Fehlen eines Worts des Eigentümers in der Ausgabe beweist nicht, dass es keines gab: Nach der Komprimierung des Protokolls werden die Worte nacherzählt.

Das Urteil ist eines von fünf:

• jetzt schließen – abgegeben; Ergebnis in git oder als "außerhalb von git, keine Kopie" gekennzeichnet; alles, was auf den Eigentümer wartet, wurde in die Liste "vom Eigentümer zu erledigen" übertragen, und die Sitzung selbst wird dafür nicht benötigt;
• nach einer Aktion schließen – nenne eine Aktion und wessen Aktion;
• offen lassen – arbeitet oder wird noch benötigt; nenne den Grund und die Schließbedingung;
• nicht anfassen – Zeitpläne und fremde Projekte;
• bereits im Archiv – überprüfe nur ihren temporären Ordner, Arbeitskopien und Uncommittetes.

Es sind mehr als zehn Sitzungen, es gibt ein Workflow-Werkzeug und die Zustimmung des Eigentümers zur parallelen Prüfung – starte ${CLAUDE_SKILL_DIR}/references/audit-workflow.js (Leser in Gruppen, separate Abgleich der Speicherorte, Zusammenfassung; Parameter sind am Anfang der Datei beschrieben, in skill übergib ${CLAUDE_SKILL_DIR}). Sonst prüfe selbst mit derselben Fragenliste.

Fallstricke dieses Schritts:

• Ein Branch ohne eigene Commits bedeutet nicht "gemerged": So sieht auch ein Branch aus, in dem die Arbeit uncommittet geblieben ist, und ein frischer Branch einer Sitzung, die gerade erst begonnen hat.
• Ein Branch existiert nicht mehr (git antwortet mit Code 128) – das ist nicht "nicht gemerged": Prüfe den Hash seiner Spitze aus dem Ende des Protokolls.
• Eine Sitzung mit dem Wort "fertig" in der Mitte des Protokolls könnte später einen Fehler in ihrer eigenen Arbeit gefunden haben. Lies das Ende, nicht das erste "fertig".
• Die Diagnose einer Sitzung ohne Kontrollversuch ist eine Annahme. Übertrage sie nicht als Grund in die Dokumente.

Schritt 3. Abschlussdatei und erster Bericht

Datei – ABSCHLUSS_Sitzungen_<JJJJ-MM-TT>.md neben dem Board (Grundgerüst in references/templates.md). Die Datei für dieses Datum existiert bereits – erstelle keine neue und überschreibe sie nicht: Lies sie, überschreibe nur den Abschnitt "JETZT", den vorherigen verschiebe in das darunter liegende Protokoll. In einem git-Projekt bleibt die Datei bis zum Wort des Eigentümers uncommittet – nenne sie im Abschnitt "Was nicht in git ist".

Erster Abschnitt – Seite "JETZT": Wozu das Ganze und welche Ordnung gilt, was getan wurde, was in git ist, welche Sitzungen geöffnet sind, welche Worte des Eigentümers eingegangen sind und was daraufhin getan wurde, was er selbst starten muss, die Fundwarteschlange. Darunter – die Tabelle und das Protokoll.

Die Seite wird nach jedem Ereignis neu geschrieben, nicht unten angehängt: Der Eigentümer liest sie, wenn er den Faden verliert. Aktualisiere bei jeder Bearbeitung die Zeit in der Überschrift, zähle die Zahlen aus den Listen neu und lies den Entscheidungsblock erneut – "läuft" und "warten" sollten nicht bleiben, nachdem die Sache erledigt ist.

Dann berichte dem Eigentümer: Wie viele Sitzungen können sofort geschlossen werden, wie viele nach einer Aktion, was nicht in git ist, was auf ihn wartet. Frage im ersten Bericht nach den stehenden Worten – sonst musst du bei jeder Sitzung fragen:

• die abgebenden Sitzungen nach und nach schließen, während sie abgeben;
• die abgegebene Arbeit in ihren Branch committen, ohne separat zu fragen;
• bestätigt er, dass die Tickets der zu schließenden Sitzungen nicht gestartet werden.

Die Form der Fragen – im Abschnitt "Gespräch mit dem Eigentümer".

Schritt 4. Abschlussarbeiten

Die Reihenfolge ist so, dass nichts verloren geht: Sichern → Committen → (Sitzung archivieren, Schritt 5) → Mergen → Entfernen.

1. Sichere Materialien aus temporären Ordnern in das Projekt: Prüfprotokolle, Vorher-Schnappschüsse, Probeläufe. Lege sie neben das Ergebnis. Wenn der Zielordner unter .gitignore steht (das zeigt repo_state.py an, Zeile "wird ignoriert") – trage ihn in "Was nicht in git ist" ein: Im Projekt gesichert bedeutet noch nicht in git gesichert.
2. Commite das Fertige – jede Arbeit in ihren eigenen Branch, nur über explizite Pfade. Überprüfe das Hinzugefügte vor dem Commit auf Schlüssel, Passwörter und persönliche Daten. Eine Datei, die Stücke mehrerer Sitzungen enthält, verteile über den Index auf die Sitzungen, ohne die Arbeitsdatei zu berühren. Überprüfe den Commit in einem separaten Klon. Rezepte – references/git-recipes.md.
3. Merge – auf das Wort des Eigentümers hin, nachdem du vor dem Mergen den Hash der vorherigen Spitze notiert hast. Führe Tests auf dem Merge-Ergebnis durch, nicht auf den Branches einzeln: Drei Branches, einzeln grün, können zusammen einen Fehlschlag ergeben.
4. Entferne Kopien und Branches – erst nach dem Abgleich: In der Geschichte des Hauptbranches sind die Commits des Branches mit seiner Arbeit vorhanden; die Kopie ist sauber; ihre ignorierten Ordner mit Protokollen sind ausgewertet; in dieser Kopie arbeitet keine offene Sitzung. git branch -d schlägt bei einem ungemergten Branch fehl, aber einen Branch ohne eigene Commits – einschließlich eines frischen Branchs einer aktiven Sitzung – löscht es stillschweigend. Entferne keine Branches und Kopien von Sitzungen eines benachbarten Projekts: Kennzeichnung "wird von jenem Projekt gelöst".
5. Rolle auf die Testumgebung aus, wenn der Eigentümer es gesagt hat – gemäß den Regeln der Testumgebung (Lock, Nachbarn, Tests der Nachbarn vorher und nachher).
6. Für die Produktion – nur vorbereiten. Ein Skript mit Plan, Einsatz und Rücknahme, unabhängig geprüft, und eine Zeile in der Liste "vom Eigentümer zu erledigen" mit dem genauen Befehl. Die vorherige Version des Pakets oder Skripts, die dort liegt, wo der Eigentümer startet, ist gefährlich: Schreibe sofort dem Eigentümer "starten Sie die vorherige Version nicht" und verschiebe sie auf sein Wort in einen Unterordner "VERALTET – nicht starten" mit einem Vermerk. Findest du einen Fehler in einem Befehl, der dem Eigentümer bereits genannt wurde, schreibe ihm in der ersten Zeile "starten Sie ihn nicht vor meiner Nachricht".
7. Korrigiere Dokumente und das Gedächtnis. Versionen, Branch-Spitzen, "nicht gemerged", "wartet" – auf Faktenbasis bringen. Ins Gedächtnis – nur Dauerhaftes (Regeln, Fallstricke, wo was liegt); den Tageszustand – in die Projektdokumente.
8. Funde – in die Warteschlange. Ein Eintrag: Was, wo, womit bestätigt, womit es droht, was zur Behebung benötigt wird.

Solange eine Sitzung noch geöffnet ist und dieselben Dateien bearbeitet, schreibe ihr "warte" und warte auf ihre Antwort: Zustellung bedeutet nicht, dass die Nachricht gelesen wurde. Nach deinem Commit – "Baum ist frei". Wenn du ein Paket überprüfst, das die Sitzung neu bauen könnte, bitte sie, es nicht anzufassen, und vergleiche die Prüfsumme vor und nach der Prüfung.

Schritt 5. Schließen von Sitzungen

Eine abgebende Sitzung wird archiviert, sobald ihre Materialien gesichert und die Arbeit in ihrem Branch committet ist – auf Mergen und das Entfernen von Kopien wartet sie nicht. Die Archivierung ist umkehrbar (unarchive_session), das Löschen nicht; verwende die Archivierung.

Vor dem Archivieren jeder Sitzung:

• ihre Arbeitskopie ist sauber, die ignorierten Ordner mit Protokollen sind ausgewertet. Laut Werkzeugbeschreibung entfernt die Archivierung standardmäßig die Arbeitskopie, die die Anwendung für die Sitzung erstellt hat; Kopien, die die Sitzung selbst über git worktree add erstellt hat, bleiben – diese entfernst du (Schritt 4, Punkt 4);
• ihr temporärer Ordner ist ausgewertet – vermerke dies in der Tabelle;
• am Ende des Protokolls gibt es keine Versprechen und keine unbeantworteten Fragen.

Archiviere über das Anwendungswerkzeug archive_session, da es den internen Zustand der Plattform aktualisiert (die Sitzung als "beendet" oder "archiviert" markiert). Wenn es kein Werkzeug gibt, erstelle eine Notiz in der Abschlussdatei unter "Zur Archivierung durch den Eigentümer".

Nach dem Archivieren:

• Entferne den Branch der Sitzung und ihre Arbeitskopie, sofern der Eigentümer dies angeordnet hat (stehendes Wort, Schritt 3).
• Aktualisiere die Seite "JETZT": Entferne die Sitzung aus "Offene Sitzungen", füge sie ggf. zu "Archivierte Sitzungen" hinzu.

Schritt 6. Abschluss

Die Abschlussdatei enthält jetzt:

• Seite "JETZT" mit dem aktuellen Stand;
• Rahmen;
• Tabelle mit den Ergebnissen der Überprüfung jeder Sitzung;
• Protokoll (Ereignisse ab Schritt 3);
• Liste "Vom Eigentümer zu erledigen";
• Fundwarteschlange.

Vor der finalen Meldung: Prüfe mit einem Lauf von Schritt 1 (Bestandsaufnahme), ob die Tabelle und die Seite den Fakten entsprechen. Insbesondere:

• Haben archivierte Sitzungen keine Arbeitskopien mehr (git ist sauber)?
• Sind alle Branches der archivierten Sitzungen gemerged oder als ungemerged gekennzeichnet?
• Ist die Fundwarteschlange leer oder enthält sie nur gültige Einträge?

Melde dem Eigentümer: "Alle Sitzungen sind geschlossen. Das Projekt ist bereit für die nächste Phase." Gib einen Link zur Abschlussdatei.

Bei Bedarf: Bereite eine Zusammenfassung für die nächste Phase vor (separate Datei, Grundgerüst in references/next-phase-template.md).

Wenn während der Bereinigung Sitzungen desselben Projekts mit einer anderen Aufgabe gestartet wurden (z. B. Fehlerbehebung, während du bereinigst), informiere den Eigentümer und frage nach Anweisungen: In diese Sitzungen mischst du dich nicht ein.

Gespräch mit dem Eigentümer

Die Eingabeaufforderung des Eigentümers für die wichtigsten Fragen:

Ich beginne mit der Bereinigung der Sitzungen. Um den Prozess zu beschleunigen, beantworte bitte drei Fragen auf einmal:

1. Soll ich die Sitzungen, die ihre Arbeit abgeben, sofort schließen, sobald sie abgeben?
2. Soll ich die Arbeit in ihren Branch committen, ohne jedes Mal zu fragen?
3. Bestätigst du, dass Tickets der zu schließenden Sitzungen nicht gestartet werden?

1, 2, 3 – für jede Frage Ja oder Nein.

Wichtiger Hinweis: Wenn der Eigentümer mit "Ja auf alles" antwortet, schreibe dies sofort auf die Seite "JETZT" als stehende Worte. Stehende Worte sind nur das, was auf die Art der Aktionen bezogen ist; du erweiterst sie nicht auf benachbarte Aktionen.

Wenn der Eigentümer verwirrt ist oder spezifizieren möchte, gib eine kurze Erklärung und bitte um eine alternative Formulierung. Wenn der Eigentümer nicht antwortet, setze die Standardcodes aus references/defaults.md ein (sofern vorhanden), oder führe die minimale Prüfung durch, ohne die endgültigen Aktionen.

Referenzen

Alle Vorlagen, Git-Rezepte, Workflows und Fallstudien befinden sich im references/-Verzeichnis dieser Skill. Die wichtigsten Dateien:

• templates.md – Vorlagen für die Abschlussdatei und andere Dokumente;
• git-recipes.md – detaillierte Git-Befehle für häufige Situationen;
• audit-workflow.js – Workflow für die parallele Prüfung vieler Sitzungen;
• lessons.md – aus echten Fehlern gezogene Lehren;
• defaults.md – Standardverhalten für den Fall, dass der Eigentümer nicht antwortet.

Beispiel für die Verwendung in Claude Code

@Drakula1980/claude-skills Bereinige die Sitzungen und führe die Abschlussarbeiten durch

Oder für den Beginn der Bereinigung:

@Drakula1980/claude-skills Führe die Bereinigung der Sitzungen durch, überprüfe Commits und Brüche