Wrap-up (Abschluss-Skill)
Der Benutzer wird diesen Chat archivieren. Alles, was nur im Gespräch lebt, geht verloren: was entschieden wurde, was sich auf der Festplatte geändert hat, was die nächste Sitzung aufnehmen sollte. Mehrere installierte Skills speichern jeweils einen Teil davon. Die Aufgabe dieses Skills ist es, sie zu finden, in der richtigen Reihenfolge auszuführen und nach einer Bestätigung zu stoppen.
Die Menge der Skills ist nicht festgelegt: Plugins kommen und gehen, der Benutzer schreibt neue Skills. Namen niemals fest codieren; sie jedes Mal aus dem entdecken, was installiert ist, und dann mit den Kategorien in references/close-out-catalogue.md abgleichen. Der Katalog sagt, was jede Kategorie ist, in welcher Reihenfolge und zu welchem Kostenpunkt; diese Datei sagt, wie jede in jeder Umgebung ausgeführt wird. Wenn die beiden uneins zu sein scheinen, für was und die Reihenfolge dem Katalog folgen, für wie dieser Datei, und die Uneinigkeit im Bericht nennen, damit der Benutzer den Katalog reparieren kann.
0. Wissen, wo man ist, und wie alt die Sitzung ist
Das meiste, was folgt, ändert sich mit der Umgebung und dem Alter der Sitzung, also beides zuerst klären und in einer Zeile oben im Plan nennen. Drei Umgebungen:
- Claude Code auf dem Rechner des Benutzers. Eine Shell auf diesem Rechner, Skills in
~/.claude/skills, Hooks, die laufen (einschließlich, wo einer eingerichtet ist, einSessionEnd-Hook, der jede Sitzung protokolliert; die lokale Karte odersettings.jsonsagt, ob einer vorhanden ist), Repositories und Vault auf der Festplatte. Alles unten gilt wie geschrieben. - claude.ai oder eine Cloud-Sitzung mit einer Geräte-Shell. Der Chat läuft in einem Linux-Container, aber ein Shell-Tool für den Computer des Benutzers ist aufgelistet, also laufen Befehle dort, in den Ordnern, die der Benutzer verbunden hat. Der Vault und jedes Skript, das in einem verbundenen Ordner gespeichert ist, sind erreichbar. Die eigenen Dateien dieses Skills (der Katalog,
scripts/) leben im Container, nicht auf diesem Rechner. Hooks laufen nicht. Memory geht über die Memory-Tools, und ein Hintergrunddurchlauf speichert dauerhafte Fakten nach jedem Durchgang. - claude.ai oder eine Cloud-Sitzung ohne diese Shell. Dateien auf dem Computer des Benutzers sind nur über die Tools erreichbar, die eine Datei in den Container einspielen und zurückschreiben, und nur, solange die Desktop-App verbunden ist. Andernfalls ist nichts auf ihrer Festplatte erreichbar. Hooks und Memory wie oben.
Signale: die Plattform und das Arbeitsverzeichnis, welche Tools aufgelistet sind (Geräte-Shell, Geräte-Datei-Tools, Memory-Tools), was der System-Prompt über Memory und über ein Projekt sagt. Wenn Sie es nicht sagen können, sagen Sie es und fragen Sie, denn eine falsche Annahme schreibt an die falsche Stelle.
Dann das Alter. Ein Abschluss wird normalerweise am Ende der Arbeit verlangt, aber ein Chat kann tagelang offen sein und später geschlossen werden, nachdem andere Sitzungen an denselben Dateien, Notizen und Skills gearbeitet haben. Die Sitzung ist stale, wenn sich etwas, das sie berührt hat, nach ihrer letzten tatsächlichen Arbeit geändert hat: vergleichen Sie das Datum dieser Arbeit (die Zeitstempel des Gesprächs oder datierte Notizen) mit den Änderungszeiten der Dateien und Speichereinträge, die sie berührt hat, einem späteren Commit, einem später datierten Speichereintrag oder einem Skill, den sie verwendet hat und der in der Auflistung jetzt umbenannt oder nicht mehr angezeigt wird. Eine solche Änderung reicht aus. Das Alter allein ist ein Grund hinzusehen, kein Urteil: ein eine Woche alter Chat, auf den niemand aufgebaut hat, ist nicht stale. Sagen Sie es in der oberen Zeile mit der Lücke ("zuletzt aktiv am 4. Nov.; Dateien, die es berührt hat, haben sich seitdem geändert").
In einer stalem Sitzung sind die Festplatte und die Speicher neuer als das Gespräch, also gewinnen sie:
- Bevor Sie einen Schreibvorgang planen, lesen Sie die aktuelle Version jeder Datei und jedes Speichereintrags, die der Schritt berühren würde, und planen Sie gegen das, was jetzt da ist, nicht gegen das, woran sich das Gespräch erinnert.
- Eine Entscheidung, die die Sitzung getroffen hat und die eine spätere Sitzung bereits aufgezeichnet hat, ist erledigt: darauf hinweisen, nicht noch einmal schreiben. Eine, die eine spätere Sitzung geändert oder rückgängig gemacht hat, ist nicht von diesem Abschluss wiederherzustellen: als ersetzt benennen und fallenlassen. Wenn die spätere Aufzeichnung nur einen Teil der Entscheidung abdeckt oder unklar ist, wie viel sie abdeckt, nur den Teil fallenlassen, den sie klar abdeckt, und den Rest als möglicherweise ersetzt benennen; welche Richtung es nimmt, hängt von der einzelnen Frage ab.
- Pfade, Namen und Skills, die die Sitzung verwendet hat, können sich verschoben haben oder umbenannt worden sein. Jeden vor der Verwendung erneut auflösen. Eine neue Form zählt nur, wenn etwas seitdem Geschriebenes sie angibt (Memory, eine Notiz, ein Commit, die eigene Beschreibung eines Skills, die sagt, wie er früher hieß); diese Form verwenden und sagen. Wenn nichts sie angibt, die alte als nicht mehr auflösbar benennen, anstatt zu raten, und nicht in einen Speicher schreiben, als ob sie aktuell wäre.
- Was übrig bleibt, um vorzuschlagen, ist das, was die Sitzung entschieden hat und nichts seitdem aufgezeichnet, geändert oder widersprochen hat. Das kann sehr wenig sein; ein staler Abschluss, der eine Zeile oder gar nichts schreibt, ist ein korrekter Abschluss.
Derselbe Chat kann bereits einen früheren Abschluss enthalten, der ausgeführt wurde, bevor der Benutzer weitergearbeitet hat. Dann baut dieser Abschluss darauf auf, anstatt neu zu beginnen: nehmen Sie seinen Plan und markieren Sie jeden Schritt als erledigt (sein Bericht sagt das und die Festplatte stimmt zu), ersetzt oder noch ausstehend, und überprüfen Sie nur, was danach passiert ist. Ein Plan, den der frühere Abschluss vorgeschlagen hat, den der Benutzer nie beantwortet hat, wurde nicht genehmigt: seine ausstehenden Schritte in diesen Plan übernehmen, erneut gegen die Festplatte und die obigen Regeln geprüft, anstatt sie auszuführen oder stillschweigend fallen zu lassen, und in der oberen Zeile sagen, dass ein früherer Abschluss existiert.
1. Entdecken
Bevor Sie etwas entdecken, überprüfen Sie die dauerhaften Anweisungen der Umgebung (in Claude Code die CLAUDE.md-Dateien und Auto-Memory, was hier als dauerhaft gilt; in claude.ai die Projektanweisungen, die Benutzereinstellungen und das Memory sowie einen Abschnitt "Lokale Karte für diese Installation", den eine verpackte Kopie dieser SKILL.md tragen kann) auf eine lokale Karte dieser Routine: ein kurzer Abschnitt, der benennt, welcher installierte Skill jede Kategorie abdeckt, die Speicher, was ausgemustert ist, gemessene Kosten. Wenn eine existiert, ersetzt sie die Entdeckung; überprüfen Sie, ob jeder genannte Skill noch installiert ist (und einen benannten Befehl oder Pfad mit einem billigen, schreibgeschützten Blick, wo einer praktisch ist), und behandeln Sie das, was sie als ausgemustert bezeichnet, als erledigt. Eine partielle Karte (Speicher oder Ausmusterungen genannt, aber kein Skill pro Kategorie) informiert die Entdeckung, anstatt sie zu ersetzen: befolgen, was sie nennt, den Rest entdecken, und das Angebot in Abschnitt 5 wird, diesen Abschnitt zu vervollständigen, anstatt einen zweiten hinzuzufügen. Wenn keine existiert, wie folgt entdecken und am Ende anbieten, eine zu schreiben (Abschnitt 5). In Claude Code die CLAUDE.md-Dateien von der Festplatte lesen, nicht nur aus dem Kontext: eine eingefügte Kopie kann älter sein als eine Bearbeitung, und eine stale schickt Sie in die vollständige Entdeckung und ein Angebot, eine zweite Karte über eine zu schreiben, die bereits existiert.
Die Kandidatenliste ist die available skills-Auflistung, die bereits im Kontext ist (Name + Beschreibung). Sie deckt lokale Skills, Plugin-Skills und gstack gleichermaßen ab; es gibt keine bessere Quelle. Zwei Eigenheiten der Auflistung: ein Skill, der sowohl mit als auch ohne Plugin-Präfix angezeigt wird, gleiche Beschreibung, ist ein Skill, also im Plan mit dem nackten Namen bezeichnen, aber mit dem genauen Namen ausführen, den die Auflistung zeigt; und die Auflistung kann während des Laufs wachsen, wenn ein Befehl einen Ordner berührt, der seine eigenen Skills trägt, deren späte Ankünfte den Plan nur ändern, wenn sie zu einer Kategorie passen.
Lesen Sie references/close-out-catalogue.md. Wählen Sie für jede darin definierte Kategorie den/die installierten Skills aus, deren Beschreibung zu ihrem Zweck passt. Bekannte Mitglieder sind Hinweise, nicht die Antwort: Ein installierter Skill, der dort nicht aufgeführt ist, qualifiziert, wenn seine Beschreibung passt; ein aufgeführter, der nicht mehr installiert ist, wird übersprungen. Achten Sie auf die Beinahe-Treffer, die der Katalog kennzeichnet. Wenn die Auflistung einen Skill nur mit Namen zeigt (beide Umgebungen tun dies für einige), auf den Namen und die "Erkennen durch"-Wörter des Katalogs abgleichen und im Plan als "(keine Beschreibung)" markieren, damit der Benutzer weiß, dass der Abgleich schwächer ist.
Eine Kategorie ohne installierten Skill kommt in den Plan als "überspringen, nicht installiert"; keine Ersatzlösung improvisieren, es sei denn, die Umgebung hat ihren eigenen Mechanismus für diese Aufgabe (Abschnitt 2). Einige Kategorien sind keine Skills (in Claude Code wird Auto-Memory mit dem Write-Tool geschrieben und eine Graph-Aktualisierung ist ein Befehl); sie sind Schritte im selben Plan, nur wo die Umgebung sie hat.
Dann überprüfen, was in dieser Sitzung tatsächlich zu tun ist:
- Graphen. In Claude Code auf dem Rechner führen Sie
python scripts/find_graphs.py <workspace-root>aus (Pfad relativ zum Verzeichnis dieses Skills; jedes Python funktioniert). Die Arbeitsbereichswurzel ist der Arbeitsordner der Sitzung oder der breitere Ordner, den die Projektanweisungen als jeden Repository haltend beschreiben, wenn sie das tun. Das Skript listet jedesgraphify-out/auf, dessen Projektordner höchstens fünf Ebenen darunter sitzt, und ob Dateien sich seit seinem Manifest geändert haben: eine Zeile pro Graph, CURRENT, STALE mit geänderten und gelöschten Zählungen, oder UNKNOWN (kein Manifest oder graphify nicht importierbar), oder eine einzelne Zeile, die sagt, dass keiner gefunden wurde. Die Zählungen sagen nicht, ob die Änderungen Notizen sind, ~85k jede zur Neugewinnung, oder Code, der kein LLM benötigt; sagen Sie, welches, basierend darauf, was die Sitzung berührt hat. CURRENT ist kein Schritt, selbst wenn Sie sich erinnern, eine grafierte Datei bearbeitet zu haben: Das Manifest weiß, ob der Graph danach neu erstellt wurde. Ohne Python auf dem Rechner sind die Graphen ungeprüft; sagen Sie das. Überall sonst kann das Skript den Arbeitsbereich nicht sehen (es läuft im Container, die Graphen sind auf der Festplatte des Benutzers): melden Sie jeden Graphen als ungeprüft, was nicht "nichts zu aktualisieren" ist. - Die Sitzung. Entscheidungen, Korrekturen, neue Fakten über den Benutzer oder das Projekt, erstellte oder verschobene Dateien? Das entscheidet, ob Memory- und Lernschritte etwas zu schreiben haben. Eine Sitzung, die reines Lesen war, braucht möglicherweise nichts außer einer Kontextspeicherung.
- Git.
git statusin jedem Repository, das die Sitzung berührt hat. Nicht festgeschriebene Arbeit ist nicht von diesem Skill zu committen; sie kommt in die Zeile "bleibt beim Benutzer" des Plans. Wenn die Geschichte der Sitzung und git sich widersprechen (Dateien in der Sitzung geändert, ein sauberer Baum), nennen Sie die Diskrepanz, anstatt sie stillschweigend zu bereinigen. - Behauptete Schreibvorgänge. Listen Sie, was die Sitzung gesagt hat, dass sie geschrieben, erstellt, installiert oder geändert hat (Dateien, Notizen, Commits, Einstellungen, installierte Pakete), und überprüfen Sie jedes mit einem schreibgeschützten Blick: Es existiert, und sein Inhalt ist der, den die Sitzung geschrieben hat (eine markante Zeile oder die Größe, nicht nur die Existenz, da ein fehlgeschlagenes Überschreiben die alte Datei hinterlässt). Ein Tool, das Erfolg gemeldet hat, ist kein Beweis. Wenn der Inhalt abweicht, entscheidet die Änderungszeit: Nach der letzten Arbeit der Sitzung geändert bedeutet, dass eine spätere Sitzung es geändert hat (Abschnitt 0, stale); nicht danach geändert bedeutet, dass der Schreibvorgang nie gelandet ist. Eine Datei, die existieren sollte und nicht existiert, ist auch nie gelandet, es sei denn, ein späterer Commit oder eine Notiz zeichnet ihre Entfernung auf. Ein Schreibvorgang, der nie gelandet ist, oder Arbeit, die die Sitzung halb erledigt hinterlassen hat (an einigen Stellen installiert und an anderen nicht, ein Schritt, den sie versprochen und nicht ausgeführt hat), kommt in die Zeile "kaputt hinterlassen" des Plans (Abschnitt 3). Eine Sitzung, die keine Schreibvorgänge behauptet hat, überspringt dies.
- Arbeit in Arbeit, die ein anderer Skill über mehrere Sitzungen verteilt (Katalog, "Arbeit in Arbeit"). Kein eigener Schritt: Es geht in die Übergabenotiz und die Kontextspeicherung.
- Wo Zustand bereits lebt. Die Projektanweisungen können die Speicher nennen, die der Benutzer als Quelle behandelt: einen Vault, eine Projektdatenbank, ein Feld, das die nächste Aktion enthält. Lesen Sie die Anweisungen, bevor Sie einen Schreibvorgang planen (die Speicher selbst werden von den Schritten gelesen, die sie schreiben); sie entscheiden, wie die Kategorien 3 und 5 laufen. Wenn zwei genannte Speicher dieselbe Tatsache enthalten könnten (eine Entscheidungsnotiz und eine Projektnotiz, sagen wir), nennt der Plan, auf welchen der Schreibvorgang abzielt; wenn die Anweisungen es nicht klären, klären Sie es in der einzelnen Frage, niemals stillschweigend.
2. Was sich mit der Umgebung ändert
In Claude Code führen Sie jede Kategorie aus, wie der Katalog beschreibt; von dem, was folgt, binden nur die Regeln, die das sagen, auch dort. In den anderen beiden Fällen von Abschnitt 0 passen Sie wie folgt an.
1 Memory: prüfen, nicht schreiben. Der Hintergrunddurchlauf speichert bereits dauerhafte Fakten nach jedem Durchgang. Lesen Sie die Memory-Datei(en), die er wahrscheinlich verwendet hat (die Auflistung zeigt die Pfade), und sagen Sie im Plan, ob die Entscheidungen dieser Sitzung dort sind. Der Durchlauf läuft nach jedem Durchgang, also ist das, was im abschließenden Durchgang selbst entschieden wurde, noch nicht da und wird danach gespeichert; das ist normal, keine Lücke. Die Plattform erlaubt nur einen Memory-Schreibvorgang auf explizite Anforderung des Benutzers. Wenn also etwas fehlt, was sie gesagt haben, nennen Sie es im Plan und lassen Sie sie "speichern" sagen; dieser Satz ist die Anforderung. Innerhalb eines Projekts gehen Schreibvorgänge in den eigenen Unterbaum des Projekts, in der Form, die die Memory-Anweisungen verlangen.
1b Übergabenotiz, 2 Learnings: überspringen, wenn nicht installiert. Es gibt keinen Ersatz; ein Projektdokument, eine neue Notiz oder eine Chat-Zusammenfassung wird nicht zu einem (siehe die Eine-Stelle-Regel).
3 Vault-Sync: hängt von der Erreichbarkeit ab. Mit einer Geräte-Shell und dem verbundenen Vault-Ordner führen Sie den Sync-Skill aus, wenn er installiert ist; wenn er etwas braucht, das diese Umgebung nicht hat, wird er das sagen, und dann den Sync von Hand durchführen. Ohne eine Shell, und nur solange der Computer verbunden ist, machen Sie es von Hand mit den Datei-Tools. In beiden Fällen zuerst die eigene Konventionsnotiz des Vaults lesen (einspielen, wenn es keine Shell gibt), und jede vorgeschlagene Änderung in den Plan setzen als was bleibt, was sich ändert und was verschwindet, damit die einzelne Bestätigung die Schreibvorgänge abdeckt. Das Sitzungsprotokoll, das ein Hook schreibt, existiert hier nicht; sagen Sie das.
4 Graph: ungeprüft, wie Abschnitt 1 sagt. Nicht "nichts zu tun".
5 Kontext speichern: schreiben, wo das Projekt es sagt. Dies gilt auch in Claude Code: Ein Ort, den die Projektanweisungen nennen, gewinnt über einen generischen Snapshot-Skill, und ohne einen ist der installierte Snapshot-Skill der Schritt. Wenn die Projektanweisungen einen Ort nennen, an dem "wo ich aufgehört habe" lebt (ein Feld in einer Projektdatenbank, zum Beispiel), ist dieser Ort die Kontextspeicherung. Wenn ein installierter Skill diesen Ort besitzt (eine tägliche Abschlussroutine), ist dieser Skill der Schritt; wenn er bereits in dieser Sitzung gelaufen ist, überspringen. Andernfalls schreiben Sie dort selbst. Der Plan trägt den genauen Text, der für diesen Ort vorgeschlagen wird, damit die eine Antwort ihn abdeckt; diese Regel gilt, wenn Sie den Ort selbst schreiben, während ein Skill, der den Schreibvorgang besitzt, seinen eigenen Inhalt verfasst, in Claude Code oder überall. Wenn kein Projekteintrag abdeckt, woran die Sitzung gearbeitet hat, sagen Sie das und schlagen Sie vor...